Strangler Fig: Einen Legacy-PHP-Monolithen ohne Feature-Freeze zu Laravel migrieren

Jede Legacy-PHP-Anwendung landet irgendwann in derselben Besprechung. Die Codebasis ist zehn Jahre alt, niemand will das Bestellmodul anfassen, das verwendete Framework hat seit 2019 kein Release mehr gesehen, und jemand schlägt einen Rewrite vor. Achtzehn Monate, heißt es. Feature-Freeze, solange wir daran arbeiten.

Dieses Projekt hat eine gut dokumentierte Misserfolgsquote, und der Mechanismus ist immer derselbe: Das Geschäft kann nicht wirklich achtzehn Monate stillstehen, also werden Änderungen am alten System vorgenommen, das neue fällt zurück, und die Migration wird zu einem dauerhaft beweglichen Ziel. Zwei Jahre später haben Sie zwei Systeme, und eines davon ist unfertig.

Das Strangler-Fig-Pattern vermeidet das, indem es ganz auf einen Cutover verzichtet. Neue Funktionalität entsteht in Laravel, bestehende wandert Route für Route hinüber, und der Traffic geht jeweils an das System, dem der Pfad gerade gehört. Die alte Anwendung schrumpft, bis sie verschwunden ist.

Die Routing-Grenze

Alles hängt daran, eine Anfrage an die eine oder die andere Anwendung schicken zu können, ohne dass der Nutzer es merkt. Setzen Sie einen Reverse Proxy vor beide und routen Sie nach Pfad.

• Leiten Sie am ersten Tag standardmäßig alles an die Legacy-Anwendung, damit der Proxy zunächst nichts verändert und unabhängig von jeder Migrationsarbeit ausgerollt werden kann.
• Verschieben Sie immer nur eine Route, indem Sie sie in die Laravel-Liste des Proxys eintragen. Das ist ab jetzt Ihr Migrationsmechanismus — und es ist eine Konfigurationsänderung.
• Halten Sie den Rollback trivial. Eine Route zurück auf Legacy zu setzen muss eine Konfigurationsänderung und ein Reload sein, kein Deployment. Sie werden das brauchen.
• Routen Sie nicht nach cleveren Kriterien. Pfad-Präfixe genügen. Routing nach Nutzersegment oder Feature Flag klingt reizvoll und verdoppelt die Zustände, über die Sie nachdenken müssen.

Dieses eine Stück Infrastruktur verwandelt eine Wette über achtzehn Monate in eine Reihe von Entscheidungen über jeweils eine Woche.

Sessions und Authentifizierung: zuerst lösen

Das erste wirklich schwierige Problem — und dasjenige, an dem Migrationen hängen bleiben, die es übersprungen haben. Ein Nutzer muss sich auf einer Legacy-Seite anmelden können und angemeldet bleiben, wenn die nächste Anfrage bei Laravel landet.

1. Verlagern Sie die Session-Speicherung dorthin, wo beide Anwendungen lesen können — Redis oder die Datenbank —, bevor Sie irgendeine Route migrieren.
2. Einigen Sie sich auf ein Serialisierungsformat. Zwei PHP-Anwendungen mit unterschiedlichen Framework-Versionen serialisieren eine Session nicht zwangsläufig identisch. Testen Sie das ausdrücklich, statt es anzunehmen.
3. Teilen Sie Cookie-Domain und -Pfad und gleichen Sie den Cookie-Namen ab.
4. Ein System besitzt die Authentifizierung. In der Regel Laravel, sobald dessen Login-Route migriert ist, während die Legacy-Anwendung die Session nur liest und nicht schreibt.
5. Testen Sie Session-Ablauf und -Regeneration über die Grenze hinweg. Auf der einen Seite abgemeldet und auf der anderen weiterhin angemeldet zu sein, ist ein Sicherheitsfehler, keine Unannehmlichkeit.

Die Datenbankgrenze

Die pragmatische Antwort für die meisten Migrationen: Beide Anwendungen teilen sich eine Datenbank, und Sie versuchen nicht, das Schema während der Migration neu zu entwerfen.

Das stößt manchen auf, und es ist trotzdem richtig. Code und Schema gleichzeitig zu migrieren bedeutet, dass jedes Problem zwei mögliche Ursachen hat, und es nimmt Ihnen die Möglichkeit, eine einzelne Route unabhängig zu verschieben. Kommen Sie zuerst auf Laravel; verbessern Sie das Schema danach, wenn Sie nur noch eine Codebasis haben und sie guten Gewissens ändern können.

• Bilden Sie das Legacy-Schema mit Eloquent-Modellen ab, so wie es ist, inklusive der Tabellennamen, die Sie nie wählen würden.
• Schreiben Sie in dieselben Tabellen, damit beide Systeme denselben Stand sehen und keine Synchronisationsschicht kaputtgehen kann.
• Vorsicht bei Legacy-Triggern und Stored Procedures — sie enthalten häufig undokumentierte Geschäftslogik, die auch unter Laravel ausgelöst wird.
• Führen Sie Migrationen nur für neue Tabellen ein. Lassen Sie Laravels Migrationssystem nicht mitten im Projekt die Hoheit über das Legacy-Schema übernehmen.
• Achten Sie auf Legacy-Code, der Timestamps oder IDs anders schreibt, als Eloquent es erwartet. Das ist eine häufige Quelle subtiler Fehler.

Was zuerst migriert wird

Die Reihenfolge zählt mehr als das Tempo.

1. Etwas Risikoarmes und Sichtbares — eine statische Seite, ein Kontaktformular, ein Hilfebereich. Ziel ist, Routing, Sessions und Deployment durchgängig zu beweisen, nicht Wert zu liefern.
2. Neue Features, ab sofort. Alles, was nach dem ersten Tag entsteht, entsteht in Laravel. Genau das finanziert die Migration selbst: Die Roadmap bezahlt das Wachstum des neuen Systems.
3. Als Nächstes die Bereiche mit den häufigsten Änderungen. Was das Team am häufigsten bearbeitet, profitiert am meisten von der wartbaren Codebasis, und der Aufwand zahlt sich sofort aus.
4. Leselastige Seiten für Kunden, bei denen Sie neben der Migration auch Performance- und SEO-Gewinne mitnehmen.
5. Checkout, Zahlung und Auftragsabwicklung zuletzt. Höchstes Risiko, höchste Fehlerkosten — und bis dahin hat Ihr Team ein Dutzend einfachere Dinge migriert.
6. Backend und Back-Office ganz zum Schluss, sofern sie nicht aktiv im Weg stehen. Interne Nutzer ertragen Hässlichkeit; Kunden nicht.

Der Instinkt sagt, man solle mit dem schlimmsten Modul beginnen. Widerstehen Sie ihm. Wer mit dem Schwierigsten anfängt, trifft bei der ersten Migration zugleich zum ersten Mal auf sämtliche Infrastrukturprobleme auf einmal.

Die Roadmap in Bewegung halten

Darum geht es im Kern, und das muss bewusst geschützt werden.

• Legen Sie eine feste Aufteilung fest — etwa 70 % Roadmap, 30 % Migration — und halten Sie sie ein. Eine Migration, die die gesamte Kapazität verschlingt, wird binnen eines Quartals zu einem Geschäftsproblem, und Geschäftsprobleme werden gestrichen.
• Jede migrierte Route soll etwas liefern. Beheben Sie einen bekannten Fehler, verbessern Sie die Seite, ergänzen Sie eine kleine Funktion. Eine Migration, die sechs Monate lang keinen sichtbaren Wert liefert, verliert ihren Sponsor.
• Berichten Sie den Fortschritt in migrierten Routen und gelöschten Legacy-Dateien. Gelöschter Code ist der einzige eindeutige Beleg dafür, dass eine Strangler-Fig-Migration funktioniert.
• Fassen Sie den Legacy-Code nur an, um Fehler zu beheben. Jede Verbesserung an einem System, das Sie ohnehin abschalten, ist verlorenes Geld.

Die Fehlermuster

1. Bei 60 % stehen bleiben. Die einfachen Routen sind erledigt, die schweren stehen aus, und der Schmerz hat so weit nachgelassen, dass die Dringlichkeit verfliegt. Jetzt pflegen Sie dauerhaft zwei Systeme, was schlechter ist als jedes einzelne für sich. Vereinbaren Sie von Anfang an, was den Abschluss auslöst.
2. Eine Abstraktionsschicht zwischen beiden Systemen bauen. Das fühlt sich nach guter Ingenieursarbeit an und ist ein drittes System, das gewartet werden will — und das die Migration überleben wird, der es dienen sollte.
3. Das Schema gleichzeitig migrieren. Verdoppelt die Variablen bei jedem Zwischenfall.
4. Keine Disziplin beim Löschen. Wenn mit den migrierten Routen kein Legacy-Code verschwindet, migrieren Sie nicht, Sie duplizieren.
5. Das Undokumentierte unterschätzen. Cron-Jobs, Webhook-Endpoints, Auswertungen, die jemand in der Buchhaltung monatlich ausführt, eine Integration, an die sich niemand erinnert. Erfassen Sie all das, bevor Sie beginnen — sonst finden diese Dinge Sie in der Produktion, bevor Sie sie finden.

Wann Sie darauf verzichten sollten

Strangler Fig ist nicht immer die richtige Antwort. Verzichten Sie darauf, wenn die Legacy-Anwendung wirklich klein ist — unter ein paar tausend Zeilen ist ein direkter Rewrite schneller, und der Apparat für den Parallelbetrieb ist Overhead, den Sie nicht brauchen. Verzichten Sie darauf, wenn das Legacy-System komplett abgeschaltet und nicht ersetzt wird. Und verzichten Sie darauf, wenn sich die Geschäftslogik selbst ändern muss; Logik zu migrieren, die Sie ohnehin verwerfen wollen, ist doppelte Arbeit.

Dieses Pattern steckt hinter dem größten Teil unserer Laravel-Entwicklung an übernommenen Systemen, und es schließt an den Analyseschritt an, den wir unter eine Legacy-PHP-Codebasis übernehmen beschreiben. Unsere Laravel-Plattformpraxis und unsere Modernisierung individueller PHP-Anwendungen decken beide Hälften des Problems ab.

Lassen Sie die Reihenfolge prüfen

Die Entscheidungen zu Routing, Sessions und Reihenfolge bestimmen, ob das funktioniert. Wir prüfen Ihre, bevor Sie Entwicklungskapazität darauf festlegen. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.