Die meisten Legacy-Projekte, die auf meinem Tisch landen, beginnen mit demselben Satz: "Das Ding müssen wir eigentlich komplett neu bauen." In fast keinem Fall stimmt das. Ein System, das seit acht oder zwölf Jahren die Rechnungen schreibt, den Lagerbestand führt oder Bestellungen verarbeitet, ist kein Müll. Es ist der lebende Beweis, dass die Fachlogik funktioniert. Das Problem sitzt selten in der Logik selbst, sondern im Code drumherum: globale Zustände, direkte SQL-Strings im Template, keine Tests, eine PHP-Version, die längst aus dem Support gefallen ist.
Genau hier setzt das Strangler Fig Pattern an. Es ist die pragmatischste Methode, ein Altsystem abzulösen, ohne den Betrieb je anzuhalten und ohne das Risiko einer großen Umstellung an einem einzigen Wochenende.
Was ist das Strangler Fig Pattern?
Das Strangler Fig Pattern ist eine Migrationsstrategie, bei der ein neues System schrittweise um das alte herumwächst und dessen Funktionen einzeln ersetzt, bis das Altsystem vollständig abgelöst ist. Der Betrieb läuft während der gesamten Migration ununterbrochen weiter.
Der Name stammt von der Würgefeige (englisch strangler fig). Diese Pflanze wächst an einem Wirtsbaum empor, umschließt ihn nach und nach und übernimmt am Ende dessen Standort komplett, während der ursprüngliche Baum vergeht. Martin Fowler hat dieses Bild vor Jahren auf die Software-Modernisierung übertragen. Der Kern: Sie ersetzen nicht alles auf einmal, sondern Funktion für Funktion, und schalten das Alte erst ab, wenn das Neue nachweislich trägt.
Warum eine komplette Neuentwicklung fast immer die falsche Wahl ist
Ein Rewrite klingt verlockend, weil er sauber wirkt. In der Praxis ist er die teuerste und riskanteste Option, die Sie wählen können. Dafür gibt es drei handfeste Gründe.
- Sie unterschätzen die Fachlogik. In jeder gewachsenen Anwendung stecken Hunderte kleiner Sonderfälle, die niemand mehr dokumentiert hat: die Skonto-Regel für einen bestimmten Kundentyp, der Umgang mit Altverträgen, die Rundung bei der Steuerberechnung. Diese Regeln sind der eigentliche Wert. Bei einem Rewrite auf der grünen Wiese entdecken Sie sie oft erst, wenn sie im neuen System fehlen und ein Kunde sich beschwert.
- Sie haben während der Neuentwicklung zwei Systeme. Das Alte muss weiter gepflegt werden, weil das Geschäft nicht stillsteht. Jede neue Anforderung müssen Sie doppelt bauen. Das zieht Rewrites regelmäßig in die Länge.
- Der Big-Bang-Wechsel ist ein Alles-oder-nichts-Ereignis. Am Umstellungstag muss alles gleichzeitig funktionieren. Geht etwas schief, gibt es keinen sauberen Rückweg.
Das Strangler Fig Pattern umgeht alle drei Punkte, weil es die Ablösung in kleine, einzeln absicherbare Schritte zerlegt.
Wie funktioniert die Ablösung technisch?
Das Herzstück ist eine Schicht, die alle eingehenden Anfragen abfängt und entscheidet, ob sie ans Altsystem oder an den neuen Code gehen. Diese Schicht wird oft als Fassade oder Routing-Proxy bezeichnet. In PHP-Projekten lässt sie sich auf mehreren Ebenen realisieren.
Routing auf HTTP-Ebene
Ein Reverse Proxy (etwa nginx oder Traefik) leitet bestimmte URL-Pfade an die neue Symfony- oder Laravel-Anwendung, den Rest an das Altsystem. Beispiel: /rechnungen/* geht bereits an den Neubau, alles andere weiter an den alten Index. So können Sie einzelne Module fachlich abgeschlossen umziehen, ohne die Nutzer zu spüren zu geben, dass zwei Anwendungen laufen.
Routing innerhalb der Anwendung
Wenn ein sauberer Schnitt auf URL-Ebene nicht möglich ist, hilft ein Front Controller, der pro Route entscheidet. Ältere Frameworks lassen sich häufig in eine Symfony-Anwendung einbetten: Das neue Framework übernimmt Routing, Security und Session, und für noch nicht migrierte Routen ruft es den Legacy-Code über eine Bridge auf. Symfony bringt dafür mit dem HttpKernelInterface und Fallback-Mechanismen die passenden Ansatzpunkte mit.
Die Datenbank als gemeinsame Wahrheit
Der kritischste Punkt ist fast immer die Datenhaltung. In der Regel teilen sich altes und neues System zunächst dieselbe Datenbank. Das ist bewusst so, denn es hält beide Seiten synchron. Wichtig: Legen Sie fest, welche Seite für welche Tabelle schreibend zuständig ist. Zwei Systeme, die dieselbe Tabelle unkontrolliert schreiben, erzeugen Dateninkonsistenzen, die schwer zu finden sind. Ein sauberer Schnitt entlang von Tabellen- oder Aggregat-Grenzen zahlt sich hier aus.
Ein realistischer Ablauf in fünf Schritten
- Fassade einziehen. Setzen Sie den Routing-Proxy vor das Altsystem, ohne zunächst etwas umzuleiten. Alles läuft weiter wie bisher. Damit haben Sie den Hebel, den Sie später brauchen.
- Ersten Schnitt wählen. Nehmen Sie ein Modul mit klaren Grenzen und überschaubarem Risiko, nicht das Herzstück. Ein Reporting oder ein Exportmodul eignet sich oft besser als die Rechnungsstellung.
- Neu bauen und absichern. Setzen Sie die Funktion neu um, idealerweise mit Tests, die das Verhalten des Altsystems zuerst abbilden (Characterization Tests). So stellen Sie sicher, dass das Neue exakt dasselbe tut, inklusive der undokumentierten Sonderfälle.
- Umschalten und beobachten. Leiten Sie den Verkehr für dieses Modul auf den Neubau um. Bei kritischen Funktionen läuft der alte Pfad im Schattenbetrieb parallel weiter, damit Sie Abweichungen erkennen, bevor Nutzer sie merken.
- Alten Pfad entfernen. Erst wenn das neue Modul über Wochen stabil läuft, löschen Sie den alten Code. Dieser Schritt wird gern vergessen, ist aber wichtig, damit die Codebasis nicht dauerhaft doppelt existiert.
Dann beginnt der Zyklus von vorn mit dem nächsten Modul. Jeder Schritt ist für sich abgeschlossen, einzeln testbar und im Zweifel einzeln zurückrollbar.
Woran das Strangler Fig Pattern scheitert
Ehrlich gesagt: nicht am Pattern selbst, sondern an der Disziplin. Zwei Fehler sehe ich immer wieder.
Der erste ist der nie abgeschlossene letzte Schritt. Teams migrieren die einfachen 80 Prozent, und der schwierige Rest bleibt für Jahre im Altsystem hängen. Dann tragen Sie dauerhaft die Kosten für zwei Systeme. Nehmen Sie sich die harten Module früh vor, nicht zuletzt.
Der zweite ist der fehlende Sicherheitsblick beim Routing. Wenn altes und neues System sich Sessions oder Authentifizierung teilen, muss die Fassade sauber prüfen, wer worauf zugreifen darf. Ein Legacy-Login, das im Klartext-Cookie hängt, wird durch den Proxy nicht besser. Die Ablösung ist der richtige Moment, solche Altlasten mitzuziehen.
Kurzer Praxis-Tipp
Fangen Sie klein und sichtbar an. Wählen Sie als ersten Schnitt ein Modul, dessen erfolgreiche Ablösung Sie intern zeigen können, aber dessen Ausfall niemanden ruiniert. Dieser erste Erfolg schafft das Vertrauen, das Sie für die schwierigen Schnitte danach brauchen. Und dokumentieren Sie bei jedem Modul, welche Fachregeln Sie beim Umbau entdeckt haben. Diese Liste ist am Ende oft wertvoller als der neue Code.
Wir bei LegacyWerk begleiten genau solche schrittweisen Ablösungen und haben die typischen Stolperstellen dafür in einem kompakten Strangler-Fig-Playbook zusammengefasst, das Sie kostenlos anfordern können.
