NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grünes Fundament mit Schriftzug Legacy, Prüfsiegel und Rakete Werkzeugkasten mit Schild Quality Gates und grünem Prüfsiegel Grüne Treppe mit Fahne Modernisierung über altem Steinstapel

Legacy Modernisierung für PHP und Symfony Projekte

Jede Änderung am Bestand kostet zu viel Zeit.

Wir sichern euer System zuerst ab: Pipeline, statische Analyse, Tests für die kritischen Pfade. Danach räumen wir gemeinsam auf, in kleinen Schritten, die jederzeit live gehen können. Euer Team übernimmt die Werkzeuge und arbeitet danach allein weiter.

Wenn keiner mehr den Deploy Button drücken will

Jedes Projekt wird alt. Kritisch wird es an dem Tag, an dem niemand mehr sagen kann, was eine Änderung auslöst.

Dann wird nicht mehr geschätzt, sondern geraten. Deploys wandern auf den späten Nachmittag oder ganz nach hinten. Features werden um alte Stellen herumgebaut, statt sie anzufassen. Und wer das System wirklich kennt, hat es im Kopf und nicht im Repository.

Da kommen wir rein. Nicht als einzelner Berater, sondern als NCA Team, das mit euren Leuten im Projekt arbeitet. Zuerst die Absicherung: Pipeline, statische Analyse auf dem bestehenden Code, Tests für die Pfade, an denen Geld hängt. Erst danach wird umgebaut, in kleinen Schritten, die einzeln live gehen können.

Kostenloses Kennenlernen, ehrliche Aufwandsschätzung, minutengenaue Abrechnung. Keine Pakete, keine Mindestlaufzeit.

NCA Senior PHP Consultants für Legacy Projekte

Euer System bleibt lieferfähig, während wir es absichern

Modernisierung heißt bei uns nicht Stillstand. Der Bestand läuft weiter, eure Nutzer merken nichts, und euer Team liefert währenddessen Features aus. Wir arbeiten in kleinen Schritten, die einzeln prüfbar sind und einzeln zurückgenommen werden können.

Die Reihenfolge ist dabei nicht verhandelbar. Erst kommen die Quality Gates: statische Analyse mit PHPStan, Tests mit PHPUnit und E2E Tests mit Cypress in der Pipeline. Erst danach wird umgebaut. Wer die Reihenfolge dreht, refactored blind.

Grüne Brücke aus Prüfschritten zwischen altem und neuem Gebäude

Die vier Phasen im Überblick

Phase Was passiert Ergebnis
Bestandsaufnahme Repository, Deployment und Abhängigkeiten ansehen. Statische Analyse läuft auf dem unveränderten Code und zeigt, wo es wirklich brennt. Ihr wisst, was ihr habt, statt es zu vermuten
Quality Gates Pipeline aufsetzen, statische Analyse auf ein haltbares Level bringen, Tests für die kritischen Pfade schreiben. Nichts wird umgebaut. Jede Änderung wird ab hier automatisch geprüft
Aufräumen Rector übernimmt den mechanischen Teil mit Dry Run. Strukturelle Entscheidungen treffen Menschen, in kleinen Schritten, jeder für sich deploybar. Der Code wird lesbar, ohne dass ein Release stoppt
Übergabe Euer Team arbeitet mit den Gates und den KI Werkzeugen selbst. Wir begleiten nur noch dünn über Architektur und Code Review. Ihr braucht uns nicht mehr für den Alltag

Was ihr davon habt

Ihr könnt wieder liefern, ohne bei jedem Release die Luft anzuhalten. Jede Änderung läuft durch automatische Prüfungen, bevor sie live geht. Versionssprünge und Sicherheitsupdates werden Routine statt Projekt. Das Wissen über euer System steht danach in Tests und Analyse statt in zwei Köpfen, neue Entwickler kommen damit deutlich schneller rein. Euer Code bleibt in eurem Repository und in eurem Stack, es zieht nichts auf eine fremde Plattform um. Euer Team lernt von Anfang an mit und arbeitet danach allein weiter. Abgerechnet wird nur die Zeit, die wirklich anfällt.

Wie wir arbeiten

  • Manuell mit KI Unterstützung

    Schlechter Code wird nicht dadurch gut, dass man einen Agenten darauf loslässt. Die KI erklärt fremde Stellen, schlägt Testfälle vor und übernimmt die Fleißarbeit. Was umgebaut wird, entscheiden Menschen, die das Geschäft dahinter verstanden haben.

  • Deterministisch, wo es geht

    Für den mechanischen Teil nehmen wir Rector. Immer erst im Dry Run, dann Regel für Regel. Was ein Werkzeug reproduzierbar erledigen kann, macht kein Mensch und kein Sprachmodell.

  • Gemeinsam am Screen

    Wir arbeiten mit eurem Team, nicht neben ihm. Pairing an echten Tickets aus eurem Backlog. So bleibt das Wissen bei euch, statt in unserem Abschlussbericht zu landen.

  • Kleine Schritte, jederzeit lieferfähig

    Jeder Umbau ist ein eigener Merge Request, der durch dieselben Gates läuft wie ein Feature. Wenn etwas nicht passt, wird ein Schritt zurückgenommen und nicht ein Quartal.

Was wir in eurem Projekt einrichten

Am Ende der Absicherung steht kein Bericht, sondern laufende Technik in eurem Repository:

  • Pipeline: Build, Tests und Analyse laufen bei jedem Merge Request, Live und Stage sauber getrennt.
  • Statische Analyse: PHPStan auf einem Level, das euer Team halten kann, mit Baseline für den Altbestand. Ab hier kommt nichts Neues dazu.
  • Tests: PHPUnit für die kritischen Pfade, Characterization Tests für die Stellen, deren Verhalten niemand mehr erklären kann, Cypress für die Wege, die eure Kunden wirklich gehen.
  • Rector: Konfiguriert für den mechanischen Teil, immer zuerst im Dry Run.
  • Review: Feste Regeln, was gemergt werden darf, damit die Gates nicht nach vier Wochen wieder umgangen werden.

Jede Woche gemeinsam am Screen

Kein Workshop Tag, kein Schulungsraum. Wir arbeiten an euren echten Tickets, im Wechsel aus Pairing und eigenständiger Arbeit:

  • Review: Die Merge Requests der Woche durchgehen, klären was sauber lief und wo es hakt.
  • Live Coding: Ein echtes Problem gemeinsam lösen, Pair Programming auf Augenhöhe.
  • Planung: Welches Modul als Nächstes abgesichert und aufgeräumt wird.

Dazu richten wir euch die KI Werkzeuge ein und legen die Regeln dafür fest. Die KI erklärt fremde Module, schlägt Testfälle vor und übernimmt die Fleißarbeit. Was umgebaut wird, entscheiden eure Entwickler, abgesichert durch die Gates.

Coding aus der Cloud, Datenverarbeitung aus dem eigenen Netzwerk

Die großen Coding Modelle laufen nicht auf eurer Hardware. Eine eigene Maschine dafür kostet ein Vermögen und wäre in einem Jahr veraltet. Also kommt die Rechenleistung aus der Cloud, während die Daten dort bleiben, wo sie hingehören.
Praktisch heißt das: Modelle, die nicht in eurer Infrastruktur laufen, arbeiten gegen eine lokale Entwicklungsumgebung mit Testdaten. Nie gegen echte Kundendaten. Wo Inferenz mit echten Daten nötig ist, gibt es europäische Anbieter mit Zero Data Retention, etwa TensorX oder unseren Infrastrukturpartner Conversis aus Duisburg.
Kleinere Modelle laufen bei uns lokal über Ollama, etwa Qwen3 Coder oder Llama. Für Code Review, Testgenerierung und das Erklären fremder Module reicht das oft völlig aus und verlässt euer Netz nie.

Legacy Modernisierung mit NCA: Hilfe direkt aus der Praxis

Never Code Alone kommt aus über zwanzig Jahren PHP und Symfony. Testing und Refactoring sind nicht das Thema, das wir uns für Legacy Projekte zurechtgelegt haben, sondern das, womit wir angefangen haben. Wir organisieren Meetups und Konferenzen dazu, arbeiten mit Cypress als Ambassador und bauen unseren eigenen Stack nach denselben Regeln, die wir bei euch anlegen.
Passend dazu: PHP Update für den Versionssprung, PHP Refactoring für technische Schulden im Detail, Symfony Frontend Refactoring wenn das JavaScript im Weg steht, CI CD Pipeline mit Docker und Staging als technische Grundlage und Vibe Coding Consulting, wenn euer Team KI Werkzeuge im Alltag einsetzen soll.

Aufwand und Zusammenarbeit

Am Anfang steht ein kostenloses Kennenlernen. Wir sehen uns an, was ihr habt, und schätzen den Aufwand ehrlich ein. Kein Festpreis, kein Paket, keine Mindestlaufzeit. Abgerechnet wird minutengenau, ihr zahlt für die Arbeit, die tatsächlich stattfindet.
Realistisch sind fünfzehn bis dreißig Tage bis zum ersten belastbaren Ergebnis: Pipeline läuft, die ersten Gates greifen, Review und Tests sind Teil des Alltags. Wenn Versionsverwaltung, erste Tests und eine Pipeline schon da sind, geht es schneller. Danach reichen wenige Tage im Monat, damit Regeln und Gates mit dem Projekt mitwachsen.
Wir arbeiten remote oder bei euch vor Ort, in eurem Repository und in eurem Prozess. Ziel ist nicht die längste Zusammenarbeit, sondern der Punkt, an dem euer Team das ohne uns weiterführt.

Legacy code isn't a problem — it's the code that made your business money.

Tomas Votruba, Maintainer von Rector und Autor von The Power of Automated Refactoring – GitHub Profil

Häufige Fragen zur Legacy Modernisierung

Die Fragen, die in fast jedem Erstgespräch zu bestehenden PHP und Symfony Projekten kommen.

Was kostet Legacy Modernisierung 2026?

Das hängt vom Zustand eures Projekts ab, deshalb nennen wir keine Pauschale. Am Anfang steht ein kostenloses Kennenlernen, danach schätzen wir den Aufwand ein. Abgerechnet wird minutengenau, ohne Festpreis, ohne Paket und ohne Mindestlaufzeit. Ihr zahlt die Arbeit, die tatsächlich stattfindet.

Wie lange dauert Legacy Modernisierung 2026 bis zum ersten Ergebnis?

Realistisch sind fünfzehn bis dreißig Tage, bis Pipeline und erste Quality Gates im Alltag laufen. Sind Versionsverwaltung, erste Tests und eine Pipeline schon vorhanden, geht es schneller. Danach reichen wenige Tage im Monat, damit Regeln und Gates mit dem Projekt mitwachsen.

Muss unser System für die Modernisierung 2026 offline gehen?

Nein. Der Bestand läuft weiter und euer Team liefert währenddessen Features aus. Wir arbeiten in kleinen Schritten, die einzeln durch die Pipeline gehen und einzeln zurückgenommen werden können. Ein Umbau, der ein Release blockiert, ist zu groß geschnitten.

Kann KI unser Legacy 2026 nicht einfach automatisch aufräumen?

Nein, und das ist der teuerste Irrtum in diesem Feld. Ohne Tests und Pipeline fehlt jede Kontrolle darüber, ob ein Vorschlag das Verhalten verändert. KI erklärt Code, schreibt Testfälle und übernimmt Fleißarbeit. Über Struktur entscheiden Menschen, abgesichert durch Gates.

Lohnt sich Modernisierung 2026 oder bauen wir besser neu?

Neu bauen heißt, Geschäftslogik nachzubauen, die über Jahre entstanden ist, inklusive aller Sonderfälle, die niemand dokumentiert hat. Das dauert länger als geplant und liefert in der Zwischenzeit nichts. Modernisierung im Bestand hält euch lieferfähig und erhält das Wissen, das im Code steckt.

Was passiert, wenn niemand mehr weiß, wie Teile des Systems funktionieren?

Genau dafür gibt es Characterization Tests. Sie beschreiben nicht die Absicht, sondern das tatsächliche Verhalten, inklusive der Eigenarten, auf die sich der Betrieb verlässt. Damit wird aus verlorenem Wissen wieder prüfbares Verhalten, und der Umbau bekommt ein Netz.

Bekommen wir Vendor Lock in, wenn wir mit euch arbeiten?

Nein. Wir arbeiten in eurem Repository, in eurem Stack, mit Werkzeugen aus dem Open Source Umfeld wie PHPStan, PHPUnit, Rector und Cypress. Es gibt keine Plattform, auf die eure Anwendung umzieht, und keine Lizenz, die euch bindet. Ziel ist der Punkt, an dem ihr uns nicht mehr braucht.

Wie stellt ihr sicher, dass beim Refactoring nichts kaputtgeht?

Durch die Reihenfolge. Erst laufen statische Analyse und Tests auf dem unveränderten Code, dann wird umgebaut. Für den mechanischen Teil nutzen wir Rector immer zuerst im Dry Run. Jede Änderung ist ein eigener Merge Request und läuft durch dieselben Gates wie ein Feature.

Was ist mit unseren Daten, wenn KI Werkzeuge im Spiel sind?

Große Coding Modelle laufen nicht in eurer Infrastruktur, deshalb arbeiten sie bei uns gegen lokale Entwicklungsumgebungen mit Testdaten. Nie gegen echte Kundendaten. Wo Inferenz mit echten Daten nötig ist, gibt es europäische Anbieter mit Zero Data Retention. Kleinere Modelle laufen lokal über Ollama.

Unser Projekt läuft noch auf einer alten PHP Version. Ist das ein Problem?

Das ist der Normalfall in Legacy Projekten und kein Hindernis. Der Versionssprung ist ein eigener Arbeitsstrang, den wir mit Rector Schritt für Schritt gehen, abgesichert durch die Tests. Details dazu stehen auf unserer Seite zum PHP Update.

Arbeitet ihr mit unserem Team oder statt unseres Teams?

Mit eurem Team. Wir pairen an echten Tickets aus eurem Backlog, damit das Wissen bei euch bleibt und nicht in einem Abschlussbericht landet. Am Ende sollen eure Entwickler die Gates und die Werkzeuge selbst bedienen. Danach begleiten wir nur noch über Architektur und Code Review.

Wir haben gar keine Tests. Wo fangen wir an?

Nicht bei hundert Prozent Abdeckung, das wäre der falsche Anspruch. Wir starten mit den Pfaden, an denen Geld verdient wird oder Ausfälle wehtun, und sichern die zuerst ab. Parallel läuft statische Analyse auf einem Level, das euer Team halten kann, mit einer Baseline für den Rest.

Quality Gates für euren Bestand

Erst die Absicherung, dann der Umbau. Wie Pipeline, statische Analyse und Tests im Alltag zusammenspielen, zeigen diese beiden Seiten.