Der Würgefeigenbaum wächst um einen anderen Baum herum, bis er ihn vollständig ersetzt hat. Klingt brutal – ist es auch, aber auf eine elegante Art. Martin Fowler hat dieses Bild 2004 auf Software übertragen und damit das vielleicht wichtigste Migrationsmuster der letzten zwei Jahrzehnte beschrieben. Und ja, es heißt wirklich "Würgefeigenbaum". Der Name ist Programm.

Das Grundprinzip

Statt das bestehende System zu ersetzen, wächst das neue System um das alte herum. Anfragen, die das neue System verarbeiten kann, werden dorthin geleitet. Alle anderen laufen weiter durch das Legacy-System. Schrittweise verschiebt sich die Last, bis das alte System abgeschaltet werden kann – still und leise, ohne dass es jemand bemerkt.

In PHP-Projekten funktioniert das häufig über einen Facade-Layer: Ein zentraler Einstiegspunkt – ein Front-Controller oder ein Reverse-Proxy – entscheidet, welches System die Anfrage bearbeitet.

Die drei Phasen in der Praxis

Phase 1: Facade etablieren

Zunächst wird eine Schicht vor das Legacy-System gezogen, ohne das Verhalten zu ändern. Alle Anfragen laufen durch die Facade, werden aber 1:1 weitergeleitet. Nach außen ändert sich nichts. Das ist der langweiligste Schritt – und der wichtigste.

Phase 2: Modul für Modul ablösen

Jetzt beginnt die eigentliche Arbeit: Ein Modul nach dem anderen wird im neuen System reimplementiert. Wichtig ist die Reihenfolge: Ich beginne mit Modulen, die wenige Abhängigkeiten haben und gut testbar sind. Die Facade leitet entsprechende Anfragen um, sobald das neue Modul produktionsreif ist. Das Legacy-System schrumpft, während kaum jemand etwas davon mitbekommt.

Phase 3: Legacy abschalten

Wenn alle Module migriert sind, hat das Legacy-System keine Aufgabe mehr. Es kann abgeschaltet werden – idealerweise mit einem klaren Datum, einem letzten Monitoring-Zeitraum als Sicherheitsnetz, und vielleicht einem kleinen Team-Ritual, das den Abschluss würdigt.

Was dieses Muster so wertvoll macht

Das Strangler Fig Pattern entkoppelt Migration von Risiko. Jeder Migrationsschritt ist reversibel: Wenn ein neues Modul Probleme macht, leitet die Facade wieder zurück. Es gibt keinen Moment, in dem das gesamte System auf dem Spiel steht.

Das Ziel ist nicht, das System an einem Tag zu ersetzen. Das Ziel ist, jeden Tag ein bisschen weniger Legacy zu haben.

Häufige Fehler

Der größte Fehler ist der Versuch, die Facade zu komplex zu machen – mit zu viel Routing-Logik, Transformationen und Zustandsmanagement. Die Facade sollte so dünn wie möglich sein. Komplexität gehört ins neue System, nicht in den Übergangsbereich. Sonst baut man einfach nur ein weiteres Legacy-System, das irgendwann auch abgelöst werden muss.

Fazit

Das Strangler Fig Pattern ist kein Wundermittel, aber es ist das ehrlichste Migrationsmuster, das ich kenne. Es respektiert die Realität: dass Legacy-Systeme nicht über Nacht ersetzt werden können, dass Teams parallel liefern müssen und dass Risiko minimiert werden muss. Wer damit arbeitet, hört auf, Migration als einmaliges Projekt zu denken – und beginnt, sie als kontinuierlichen Prozess zu verstehen.