Strangler Fig Pattern
Altsysteme schrittweise und risikoarm migrieren
Ausgangslage
IT-Migrationsprojekte sind längst kein Ausnahmefall mehr, sie gehören zum Geschäftsalltag. Altsysteme, die über Jahre in Betrieb sind, erreichen irgendwann einen Punkt, an dem Custom Features teuer zu implementieren und Workarounds die Regel sind. Die ursprünglichen Wissensträger, die Prozesse und Features kennen, sind oft nicht mehr verfügbar. Was bleibt, ist ein System, das geschäftskritische Prozesse abbildet, aber technisch in die Jahre gekommen ist.
Die zentrale Herausforderung dabei: Kunden und Mitarbeiter nutzen dieses System aktiv. Eine Migration muss gelingen, ohne den laufenden Betrieb zu gefährden und ohne große Downtimes, Datenverlust oder böse Überraschungen.
Genau hier setzt das Strangler Fig Pattern an.
Was ist das Strangler Fig Pattern?
Das Pattern wurde erstmals 2004 von Martin Fowler beschrieben, inspiriert von Würgefeigen, die er in einem australischen Regenwald beobachtet hat. Der Name stammt von der Würgefeige (Ficus, engl. Strangler Fig) — einer Pflanze, die sich um einen bestehenden Baum windet, langsam dessen Funktion übernimmt und ihn schließlich vollständig ersetzt.
Übertragen auf die Softwaremigration bedeutet das: Anstatt ein Altsystem auf einen Schlag abzulösen, werden einzelne Prozesse und Features schrittweise auf ein neues System migriert. Das alte System läuft parallel weiter, bis es vollständig abgelöst ist.
Der Kerngedanke lässt sich auf drei Prinzipien herunterbrechen:
Inkrementelle Migration — Ein Prozess nach dem anderen wird migriert, nicht alles auf einmal.
Facade als Traffic-Steuerung — Eine vorgeschaltete Schicht (Facade) leitet Anfragen entweder an das alte oder das neue System weiter.
Jederzeit Rollback-fähig — Wenn ein migrierter Prozess nicht wie erwartet funktioniert, kann der Traffic über die Facade sofort zurück auf das Altsystem geleitet werden.
Wann lohnt sich das Strangler Fig Pattern?
Nicht jede Migration erfordert dieses Pattern. Bei kleinen, überschaubaren Systemen kann eine Komplettablösung effizienter sein. Das Strangler Fig Pattern entfaltet seine Stärken bei Systemen, die groß und komplex genug sind, um eine schrittweise Migration zu rechtfertigen.
Entscheidungshilfe: Strangler Fig vs. Komplettablösung
| Kriterium | Komplettablösung | Strangler Fig Pattern |
|---|---|---|
| Systemgröße | Klein (wenige Prozesse) | Groß (viele Prozesse/Module) |
| Toleranz für Downtime | Hoch | Niedrig |
| Komplexität der Abhängigkeiten | Gering | Hoch |
| Datenmigration | Einfach, einmalig möglich | Komplex, inkrementell nötig |
| Rollback-Anforderung | Akzeptabel ohne Rollback | Rollback muss jederzeit möglich sein |
| Projektlaufzeit | Kurz (Wochen) | Lang (Monate bis Jahre) |
Daumenregel: Sobald ein System mehr als eine Handvoll eng verzahnter Geschäftsprozesse abbildet, aktive Kunden hat und bei Ausfall Geschäftsschaden entsteht, ist das Strangler Fig Pattern die sicherere Wahl.
Prozesse identifizieren und priorisieren
Bevor die Migration beginnt, müssen alle Prozesse und Features des Altsystems erfasst, kategorisiert und priorisiert werden. Zwei Dimensionen sind dabei entscheidend:
Risiko vs. Geschäftswert
| Hoher Geschäftswert | Niedriger Geschäftswert | |
|---|---|---|
| Hohes Risiko | Sorgfältig planen, spät migrieren — hier gibt es die meisten Abhängigkeiten und den größten potenziellen Schaden | Kritisch hinterfragen — lohnt sich die Migration oder kann der Prozess entfallen? |
| Niedriges Risiko | Zuerst migrieren — schneller Business Value bei geringem Risiko | Zuletzt migrieren oder ganz abschalten, wenn der Prozess nicht mehr benötigt wird |
Die ideale Reihenfolge: Starte mit Prozessen, die niedriges Risiko und hohen Geschäftswert haben. Das liefert schnell sichtbare Ergebnisse und baut Vertrauen im Team und bei Stakeholdern auf.
Gleichzeitig bietet die Analyse die Gelegenheit, Prozesse zu identifizieren, die gar nicht mehr benötigt werden. Altsysteme sammeln über die Jahre Features an, die niemand mehr nutzt — die Migration ist der richtige Moment, diese bewusst abzuschalten.
Die Facade: Herzstück der Migration
Die Facade ist die zentrale Steuerungsschicht im Strangler Fig Pattern. Sie sitzt zwischen den Clients und den Backend-Systemen und entscheidet, welcher Traffic wohin geht.
So funktioniert die Facade
Vor der Migration: Die Facade leitet den gesamten Traffic an das Altsystem.
Während der Migration: Prozess für Prozess wird umgestellt. Migrierte Prozesse werden auf das neue System geroutet, nicht migrierte bleiben auf dem Altsystem.
Nach der Migration: Das Altsystem ist vollständig abgelöst. Die Facade kann entfernt werden — oder sie bleibt als API-Management-Schicht bestehen, etwa um Abwärtskompatibilität für ältere Clients zu gewährleisten.
Vorteile der Facade
Rollback jederzeit möglich: Funktioniert ein migrierter Prozess nicht wie erwartet, wird der Traffic sofort auf das Altsystem zurückgeleitet.
A/B-Tests: Alter und neuer Prozess können parallel betrieben werden, um Verhalten und Performance zu vergleichen.
Parallelbetrieb: Kunden merken im Idealfall nichts von der Migration — die Facade abstrahiert die Komplexität.
Typische Migrationsszenarien
Das Strangler Fig Pattern ist nicht auf einen bestimmten Technologie-Stack beschränkt. Es lässt sich überall dort einsetzen, wo ein gewachsenes System schrittweise abgelöst werden soll. Hier sind die häufigsten Szenarien:
Monolith auf Microservices migrieren — Ein monolithisches System wird schrittweise in einzelne Microservices zerlegt. Jeder Service übernimmt einen klar abgegrenzten Prozess. Die Facade steuert, welche Anfragen noch an den Monolith gehen und welche bereits vom neuen Service bedient werden.
Integrationssystem ablösen — Gewachsene Integrationsplattformen verbinden oft dutzende Systeme miteinander. Eine Komplettablösung ist hier besonders riskant, weil jede Integration eigene Datenformate, Protokolle und Fehlerbehandlung mitbringt. Mit dem Strangler Fig Pattern wird eine Integration nach der anderen auf die neue Plattform überführt. Beispiel: BizTalk-Integrationen auf Azure-Services migrieren — etwa auf Logic Apps, Azure Functions, Service Bus und API Management.
On-Premises auf Cloud migrieren — Lokale Infrastruktur wird Schritt für Schritt in die Cloud verlagert. Einzelne Workloads werden nacheinander migriert, während die Facade den Traffic zwischen On-Premises und Cloud steuert. So lassen sich Cloud-Vorteile früh nutzen, ohne den gesamten Betrieb auf einmal umzustellen.
Legacy-Frontend modernisieren — Ältere Desktop-Anwendungen oder veraltete Web-UIs werden schrittweise durch moderne Frontends ersetzt. Einzelne Bereiche oder Module der Oberfläche werden nacheinander neu gebaut, während der Rest der Anwendung unverändert weiterläuft. Die Facade routet Nutzer je nach Modul auf die alte oder neue Oberfläche. Voraussetzung: Die Businesslogik darf nicht fest in der UI verankert sein. Falls doch, muss sie vorher in eigene Services herausgelöst werden.
Abhängigkeiten und Daten: Die unterschätzte Herausforderung
Die größte Herausforderung im Strangler Fig Pattern ist selten die Migration der Logik selbst — es ist die Datenverfügbarkeit und Datenmigration.
Was beachtet werden muss
Datenzugriff: Während des Parallelbetriebs müssen sowohl das alte als auch das neue System auf konsistente Daten zugreifen können. Wer schreibt wohin? Wer ist die führende Quelle?
Datenmigration: Daten müssen inkrementell migriert werden, nicht alles auf einmal. Das erfordert eine klare Strategie für Synchronisation und Konfliktauflösung.
Abhängigkeiten tracken: Migrierte Prozesse können von Daten abhängen, die noch im Altsystem liegen, und umgekehrt. Diese Abhängigkeiten müssen dokumentiert und aktiv verwaltet werden.
Ein genaues und inkrementelles Verwalten von bereits migrierten Prozessen und Features ist für den Projekterfolg wesentlich.
Sichtbarkeit schaffen: Monitoring als Bonus
Altsysteme leiden häufig unter fehlender Sichtbarkeit — es gibt kein oder kaum Monitoring, kaum Metriken, kaum Alerting. Die Migration ist die ideale Gelegenheit, dieses Defizit zu beheben.
Jeder migrierte Prozess kann von Anfang an mit Monitoring, Logging und Alerting ausgestattet werden. Das liefert nicht nur operative Sicherheit für die neuen Komponenten, sondern verbessert auch die Gesamttransparenz über das System. Ein Vorteil, der weit über das Migrationsprojekt hinaus wirkt.
Das größte Risiko: Zu viel auf einmal
Das Strangler Fig Pattern funktioniert, weil es durch Teile und Herrsche Komplexität beherrschbar macht. Das größte Risiko besteht darin, dieses Prinzip zu verletzen.
Es ist verlockend, mehrere Prozesse gleichzeitig zu migrieren, weil das Team glaubt, die Komplexität zu beherrschen. Doch genau das führt zu den Problemen, die das Pattern eigentlich vermeiden soll:
Abhängigkeiten werden übersehen
Rollbacks werden komplex oder unmöglich
Fehler sind schwerer zu isolieren
Die Disziplin, einen Prozess nach dem anderen zu migrieren, ist der entscheidende Erfolgsfaktor. Es geht darum, Risiko zu minimieren — nicht darum, schnell fertig zu werden.
Das Strangler Fig Pattern nimmt auch den Zeitdruck vom Team. Unerwartete Komplexität oder fehlendes Wissen treffen jedes Migrationsprojekt. Der Projektplan kann dann angepasst werden, ohne das gesamte Projekt zu gefährden. Die Zuständigkeit wird schrittweise vom alten System an das neue abgegeben, kontrolliert und nachvollziehbar.
Zusammenfassung
Das Strangler Fig Pattern ist kein Werkzeug für jede Migration, aber das richtige für die schwierigen: große, gewachsene Altsysteme mit aktiven Nutzern, lückenhafter Dokumentation und hoher Geschäftskritikalität.
Die Kernprinzipien:
Inkrementell migrieren — ein Prozess nach dem anderen
Facade nutzen — Traffic steuern, Rollback ermöglichen, Parallelbetrieb sicherstellen
Risiko minimieren — nicht Geschwindigkeit maximieren
Daten als eigene Herausforderung behandeln — Verfügbarkeit, Synchronisation und Migration aktiv planen
Sichtbarkeit schaffen — Monitoring von Anfang an einbauen
Am Ende steht ein vollständig abgelöstes Altsystem — schrittweise migriert, ohne unnötiges Risiko und mit kontinuierlichem Business Value auf dem Weg dorthin.
