Was Refactoring oder Rewrite bei Legacy PHP bedeutet

Bei Legacy PHP entscheidet ihr zwischen drei Wegen: Refactoring baut den bestehenden Code in kleinen Schritten um, ohne sein Verhalten zu ändern. Ein Rewrite ersetzt die Anwendung komplett durch neuen Code, meist mit einem Stichtag für die Umstellung.

Dazwischen liegt der Weg, den wir am häufigsten empfehlen: ein paralleles neues Projekt, das Route für Route übernimmt, während das Altsystem weiterläuft. Welcher Weg passt, hängt nicht am Alter des Codes. Es hängt an Tests, Architektur, Teamwissen und daran, wie lange das Geschäft auf neue Features warten kann. Diese Seite zeigt euch die Kriterien, mit denen ihr die Entscheidung begründet statt sie aus dem Bauch zu treffen.

Never Code Alone arbeitet seit über 20 Jahren an gewachsenen PHP Anwendungen. Unser eigener Stack läuft auf Symfony und Sulu CMS. PHPUnit, PHPStan, Psalm und Rector prüfen jeden Commit, Cypress testet die Oberfläche. Wir kennen deshalb beide Seiten der Frage: den Code, der seit Jahren Geld verdient, und den Wunsch, endlich sauber anzufangen. Unsere Haltung ist klar. Wir holen Teams aus dem Legacy heraus, mit einem neuen Projekt neben dem alten und mit Tests als Netz darunter.

Im PHP Consulting bewerten wir euren Bestand und schätzen den Aufwand ehrlich. Beim PHP Refactoring bauen wir zuerst die Quality Gates auf, beim PHP Update bringen wir euch auf eine unterstützte Version. Wie die Ablösung in Scheiben funktioniert, zeigt das Strangler Fig Pattern, wie ihr unbekanntes Verhalten festhaltet, erklären die Characterization Tests. Teams, die gemeinsam lernen wollen, starten im NCA RuhrRefactoring Workshop.

Jede gewachsene PHP Anwendung erzählt eine Geschichte. Am Anfang stand ein kleines Team mit einem klaren Ziel. Dann kamen Kunden, Sonderwünsche, Notfälle und Deadlines. Heute läuft der Code, aber jede Änderung fühlt sich an wie ein Schritt auf dünnem Eis.

In dieser Lage hört man im Team schnell den Satz: Wir schreiben das neu. Der Wunsch ist verständlich. Neuer Code fühlt sich sauber an, alter Code fremd. Dabei steckt im alten Code oft das wertvollste Wissen der Firma. Jede seltsame Bedingung kann ein Bugfix sein, den jemand vor Jahren mühsam gefunden hat.

Auf der anderen Seite steht die Geschäftsführung. Sie will wissen, was es kostet, wie lange es dauert und ob danach alles besser ist. Ohne Zahlen aus dem Code bleibt diese Diskussion ein Streit über Gefühle.

Drei Fehler sehen wir dabei immer wieder:

• Die Entscheidung fällt nach Stimmung. Wer zuletzt einen schlimmen Bug hatte, will neu bauen. Wer zuletzt ein Feature schnell liefern konnte, will alles lassen.
• Der Aufwand für den Neubau wird unterschätzt. Niemand kennt alle Sonderfälle, die das alte System heute schon abdeckt.
• Der Betrieb des Altsystems wird vergessen. Während das neue System entsteht, braucht das alte weiter Updates, Bugfixes und Features.

Refactoring im Bestand passt, wenn die Grundstruktur trägt. Das Team räumt Klasse für Klasse auf, Tests sichern jeden Schritt ab. Der Code bleibt im selben Repository und in derselben Architektur.

Der klassische Rewrite startet ein neues System auf der grünen Wiese. Am Ende steht ein Stichtag, an dem alle Nutzer umziehen. Bis dahin liefert das neue System nichts an echte Nutzer.

Das parallele neue Projekt verbindet beides. Ein neues Symfony Projekt entsteht neben dem alten. Ein Gateway leitet einzelne Routen um, der Rest bleibt vorerst beim Altsystem. Jede Scheibe geht live, sobald sie fertig ist, und lässt sich mit einem Handgriff zurückdrehen. Die Tabelle zeigt die Unterschiede auf einen Blick.

Bevor jemand Neubau sagt, sollten fünf Fragen beantwortet sein. Jede davon lässt sich mit Werkzeugen messen, nicht nur schätzen.

1. Wie gut ist das Verhalten abgesichert? Gibt es Tests für die Wege, an denen Geld hängt? Wenn nicht, sind Characterization Tests der erste Schritt, egal welchen Weg ihr wählt.
2. Wo liegen die heißen Stellen? Churn PHP zeigt Dateien, die oft geändert werden und gleichzeitig komplex sind. Dort tut der Code am meisten weh.
3. Wie stark ist die Kopplung? PHP Metrics und Deptrac machen sichtbar, ob sich Teile herauslösen lassen oder alles an allem hängt.
4. Läuft die Plattform noch auf einer unterstützten Version? Ein PHPStan Bodyscan und PHPCompatibility zeigen, wie weit der Weg auf aktuelles PHP ist.
5. Wer kennt den Code noch? Fehlt das Wissen im Team, wird jeder Umbau langsamer. Dann zählen Tests als Dokumentation doppelt.

Die Antworten ergeben ein Bild, das auch Nichtentwickler verstehen. Viele heiße Stellen, starke Kopplung und eine alte Plattform sprechen für ein paralleles neues Projekt. Eine tragfähige Struktur mit einzelnen schwachen Modulen spricht für Refactoring im Bestand.

Ein Rewrite ist nicht immer falsch. Bei kleinen Anwendungen mit überschaubarer Fachlichkeit kann er schneller sein als jeder Umbau. Auch wenn sich das Geschäftsmodell grundlegend geändert hat, passt der alte Code oft nicht mehr zur neuen Aufgabe.

Wichtig ist, dass auch ein Neubau vom alten System lernt. Die Tests, die das heutige Verhalten festhalten, werden zur Spezifikation für das neue System. So geht kein Sonderfall verloren, nur weil niemand mehr an ihn gedacht hat.

Gute Zeichen für einen echten Neubau:

• Die Anwendung ist klein und die Fachlichkeit ist vollständig bekannt
• Das Geschäftsmodell hat sich so verändert, dass alte Abläufe wegfallen
• Die Plattform lässt sich technisch nicht mehr sinnvoll betreiben
• Ein Rollback auf das Altsystem bleibt während der Umstellung möglich

Fehlen diese Punkte, ist der Weg über ein paralleles Projekt fast immer die sicherere Wahl.

Egal welcher Weg es wird, der erste Schritt ist immer derselbe. Ihr baut ein Netz, bevor ihr springt. Die Reihenfolge hat sich in unseren Projekten bewährt:

1. Statische Analyse mit PHPStan auf einem Level, das die Codebasis heute schafft, abgesichert durch eine Baseline
2. Characterization Tests für Code, dessen Verhalten niemand mehr genau beschreiben kann
3. Unit und Functional Tests mit PHPUnit für die Logik, an der Umsatz hängt
4. E2E Tests mit Cypress für die wichtigsten Wege durch die Oberfläche
5. Eine Pipeline, die diese Prüfungen bei jedem Commit ausführt

Sebastian Bergmann, der Erfinder von PHPUnit, beschreibt dieses Vorgehen als Flugschreiber für euren Code: Die Tests zeichnen auf, was die Anwendung heute tut, ohne zu bewerten, ob es richtig ist. Sein Artikel A flight recorder for your code zeigt, wie man so selbst ohne bestehende Tests einsteigt.

Mit diesem Netz wird die eigentliche Frage leichter. Ihr seht, wie viel Verhalten wirklich im Code steckt, wie stabil die Tests laufen und wo die Risiken liegen. Erst dann lohnt sich die Entscheidung zwischen Umbau und neuem Projekt.

KI Coding Agents verändern die Rechnung. Sie erklären fremden Code in Minuten, schlagen Testfälle vor und schreiben Boilerplate schneller als jedes Team. Das macht einen Neubau billiger als vor ein paar Jahren und verführt zu dem Gedanken, die KI könne das Altsystem einfach nachbauen.

Genau hier liegt die Falle. Ein Agent kennt die Sonderfälle nicht, die nirgends dokumentiert sind. Er baut nach, was er im Code sieht, und vereinfacht dabei gern Logik, die aus gutem Grund kompliziert ist. Deshalb gilt bei uns: Die KI unterstützt das Team, das Team entscheidet und prüft. Jeder Schritt läuft gegen Tests und statische Analyse, bevor er gemergt wird.

Wie das in der Praxis aussieht, beschreiben wir im Bereich AI Code Refactoring. Wer KI Werkzeuge im Team einführen will, findet im Vibe Coding Consulting den passenden Rahmen mit Guardrails.

Wir begleiten Teams genau an diesem Punkt: Bestand verstehen, Verhalten absichern, dann den Weg wählen. Die Werkzeuge dafür findet ihr ausführlich im Glossar.

Für die Bestandsaufnahme nutzen wir PHPStan Bodyscan, Churn PHP und PHP Metrics. Die Schichten prüft Deptrac, den Abstand zur aktuellen Sprachversion PHPCompatibility. Für die Ablösung kombinieren wir das Strangler Fig Pattern mit einem Anti Corruption Layer, Parallel Run und Feature Flags. Datenbankänderungen laufen über Parallel Change. Fachliche Grenzen ziehen wir mit Domain Driven Design und klaren Bounded Contexts. Die Grundlagen der Serie stehen in den Grundlagen des PHP Refactorings und bei den SOLID Prinzipien in PHP.

Diese Fragen hören wir von Entwicklern und Geschäftsführern, wenn eine Legacy Anwendung an ihre Grenzen kommt.