Die häufigste Anfrage bei einem alten PHP-System klingt so: "Der Code ist ein Albtraum, wir schreiben das komplett neu." Verständlich. Aber fast immer ist die Neuentwicklung die teuerste und riskanteste Option von allen. Ein System, das seit acht Jahren Rechnungen schreibt, Bestellungen abwickelt und Steuerlogik korrekt anwendet, ist kein Müll. Es ist der Beweis, dass die Fachlogik funktioniert. Das Problem ist selten die Logik selbst, sondern der Code drumherum: veraltete Frameworks, globaler Zustand, fehlende Tests, PHP 5.6 unter der Haube.
Deshalb lohnt es sich, eine PHP Migration schrittweise anzugehen statt in einem großen Wurf. Dieser Artikel zeigt, wie das ohne Ausfall gelingt und warum der Big Bang so oft scheitert.
Warum scheitert der Big-Bang-Rewrite so oft?
Ein Big-Bang-Rewrite scheitert, weil er über Monate keinen auslieferbaren Zwischenstand produziert und das alte System weiterläuft, während das neue nachziehen muss. Sie entwickeln parallel gegen ein bewegliches Ziel.
Konkret passiert Folgendes: Während Ihr Team das neue System baut, muss das alte weiter gewartet werden. Bugfixes und neue Anforderungen landen in beiden Codebasen oder nur in der alten. Das neue System ist bei Go-live bereits veraltet. Dazu kommt, dass in einem gewachsenen System Fachwissen steckt, das niemand mehr vollständig kennt: der Sonderfall bei Stornos, die Rundungsregel im dritten Bundesland, der eine Kunde mit dem abweichenden Rechnungslauf. Ein Rewrite auf der grünen Wiese verliert genau dieses Wissen, und es fällt erst im Produktivbetrieb auf.
Was bedeutet das Strangler-Fig-Muster konkret?
Das Strangler-Fig-Muster ersetzt ein Altsystem Stück für Stück, indem neue Funktionalität um das alte System herum wächst, bis das Alte vollständig verdrängt ist. Der Name geht auf Martin Fowler und die Würgefeige zurück, die einen Baum umwächst und am Ende ersetzt.
In der Praxis setzen Sie einen Router oder eine Fassade vor die Anwendung. Jeder Request läuft zuerst durch diese Schicht. Anfangs leitet sie alles an das Legacy-System weiter. Nach und nach fangen Sie einzelne Routen ab und leiten sie an neu geschriebene Module. Das kann so simpel sein wie eine Regel im Reverse Proxy oder ein Front-Controller in PHP:
// Vereinfachte Fassade im Front-Controller
$path = $request->getPathInfo();
if (str_starts_with($path, '/api/invoices')) {
return $newInvoiceApp->handle($request); // neu, z. B. Symfony
}
return $legacyKernel->handle($request); // alles andere: Altsystem
Der entscheidende Punkt: Beide Systeme laufen gleichzeitig, teilen sich in der Regel dieselbe Datenbank, und der Nutzer merkt vom Umbau nichts.
PHP Migration schrittweise: Wo fangen Sie an?
Beginnen Sie mit einem Modul, das fachlich abgegrenzt und geschäftskritisch, aber nicht das Herzstück ist. So gewinnen Sie Erfahrung mit dem Verfahren, ohne beim ersten Schnitt das Kernsystem zu gefährden.
Eine bewährte Reihenfolge:
- Fundament sichern. Bringen Sie die bestehende Anwendung zuerst auf eine unterstützte PHP-Version. Der Sprung von 5.6 oder 7.x auf 8.x mit Werkzeugen wie Rector und PHPStan ist oft der wirkungsvollste erste Schritt, und er verändert die Architektur noch gar nicht.
- Charakterisierungstests schreiben. Bevor Sie etwas ersetzen, sichern Sie das aktuelle Verhalten mit Tests ab, die das System so beschreiben, wie es ist, nicht wie es sein sollte. Diese Tests sind Ihr Sicherheitsnetz.
- Nähte finden. Identifizieren Sie eine Stelle, an der sich ein Modul sauber herauslösen lässt, etwa eine in sich geschlossene API oder ein selten geänderter Bereich.
- Ersten Schnitt setzen. Schreiben Sie dieses eine Modul neu, hängen Sie es hinter die Fassade und schalten Sie es live.
Wie migrieren Sie die Datenbank ohne Ausfall?
Die Datenbank migrieren Sie schrittweise mit dem Expand-and-Contract-Muster: Sie erweitern das Schema abwärtskompatibel, stellen den Code um, und entfernen die alte Struktur erst danach. So muss nie ein hartes Umschalten stattfinden.
Ein Beispiel: Sie wollen eine Spalte umbenennen oder eine Tabelle aufteilen. Statt es in einer riskanten Migration zu erzwingen, gehen Sie in drei Phasen vor:
- Expand: Neue Spalte oder Tabelle hinzufügen, ohne die alte zu entfernen. Beide werden parallel geschrieben.
- Migrate: Bestandsdaten im Hintergrund übertragen, Lesezugriffe schrittweise auf die neue Struktur umstellen.
- Contract: Erst wenn kein Code mehr die alte Struktur nutzt, wird sie entfernt.
Weil altes und neues PHP-Modul sich dieselbe Datenbank teilen, ist eine gemeinsame, konsistente Datensicht der kritischste Teil des ganzen Vorhabens. Hier lohnt sich besondere Sorgfalt.
Wie behalten Sie Sicherheit und Kontrolle?
Kontrolle behalten Sie durch Feature-Flags und schrittweises Ausrollen: Neue Module gehen erst für einen kleinen Teil des Verkehrs live und lassen sich bei Problemen sofort zurückschalten.
Nutzen Sie ein Feature-Flag, um zwischen altem und neuem Pfad umzuschalten, ohne ein Deployment. Fällt etwas auf, drehen Sie das Flag zurück, statt in Panik einen Hotfix zu deployen. Nebenbei ist die Migration der ideale Zeitpunkt, alte Sicherheitslücken zu schließen: SQL-Injection durch String-Konkatenation, unsalted Passwort-Hashes oder fehlende CSRF-Prüfungen gehören in die neu geschriebenen Module gar nicht erst hinein. Prepared Statements, password_hash() und die CSRF-Mechanismen von Symfony oder Laravel sind hier Pflicht, kein Extra.
Ehrliche Praxis: Was Sie realistisch erwarten sollten
Eine schrittweise Migration ist kein schnelleres Verfahren als der Rewrite, sondern ein sichereres. Sie tauschen die Illusion eines großen Befreiungsschlags gegen viele kleine, kontrollierte Schritte, von denen jeder einzeln in Produktion geht und jeder einzeln zurückgenommen werden kann. Manche Module werden Sie am Ende gar nicht neu schreiben, weil das Alte einfach funktioniert und der Aufwand sich nicht rechnet. Das ist kein Scheitern, sondern eine gute Entscheidung.
Der ehrlichste Rat: Fangen Sie klein an, mit einem einzigen Modul und einem Sicherheitsnetz aus Tests. Wenn dieser erste Schnitt sitzt, haben Sie ein wiederholbares Verfahren statt eines Riesenrisikos. Genau bei solchen schrittweisen PHP-Migrationen unterstützt LegacyWerk, wenn Sie einen erfahrenen Blick von außen brauchen.
