Strangler-Fig-Pattern bezeichnet eine Vorgehensweise der Software-Modernisierung, bei der ein Altsystem nicht auf einen Schlag ersetzt, sondern Funktion für Funktion von einem neuen System umwachsen und abgelöst wird. Eine Fassade leitet jede Anfrage entweder an den alten oder den neuen Code weiter, sodass beide Systeme über Monate oder Jahre nebeneinander laufen. Am Ende übernimmt das neue System alle Aufgaben, das alte wird abgeschaltet.
Der Begriff stammt von Martin Fowler. Er hatte 2001 im Regenwald von Queensland Würgefeigen gesehen: Pflanzen, die in der Krone eines Baums keimen, ihre Wurzeln nach unten wachsen lassen und den Wirt über Jahre so vollständig umschließen, dass er abstirbt und nur noch die Feige steht. Am 29. Juni 2004 veröffentlichte Fowler dazu den Bliki-Eintrag „StranglerApplication“. Weil der Name „Strangler“ ohne den botanischen Kontext nach Gewalt klang, benannte er den Beitrag später in „Strangler Fig Application“ um, zuletzt überarbeitet im August 2024. Das Bild blieb dasselbe: Das Neue wächst um das Alte herum, bis das Alte überflüssig ist.
Für Geschäftsführer und IT-Leiter im Mittelstand ist das Pattern vor allem eine Antwort auf eine unangenehme Frage: Was tun mit einem System, das das Geschäft trägt, aber niemand mehr anfassen will? Dieser Eintrag erklärt, wie das Muster funktioniert, wo es bei Monolithen und bei mobilen Apps greift, welche Risiken es mitbringt und wie es sich von einem Big-Bang-Rewrite und von Refactoring unterscheidet.
Wie das Strangler-Fig-Pattern funktioniert
Das Muster hat eine einfache Grundidee und vier Phasen. Die Microsoft-Architekturdokumentation beschreibt sie als Einführung der Fassade, inkrementelle Zerlegung, Stilllegung des Altsystems und Entfernen der Fassade. In der Praxis sieht das so aus.
Phase 1: Fassade und Routing
Zuerst stellst du eine Schicht vor das Altsystem, die alle Aufrufe entgegennimmt. Bei einem Web-Backend ist das ein Reverse Proxy, ein API-Gateway oder ein Routing-Layer in der Anwendung selbst. Diese Fassade ändert zunächst nichts; sie reicht jede Anfrage unverändert an den alten Code weiter. Ihr Wert liegt darin, dass du ab jetzt pro Route, pro Endpunkt oder pro Bildschirm entscheiden kannst, wer antwortet. Ohne diese Abfangstelle gibt es kein Strangler-Fig-Pattern; Microsoft nennt fehlende Abfangbarkeit ausdrücklich als Ausschlusskriterium.
Phase 2: Inkrementelle Ablösung
Dann wählst du eine erste Funktion aus, baust sie im neuen System nach und schaltest die Fassade für genau diese Funktion um. Alles andere läuft weiter über das Altsystem. Die erste Scheibe sollte klein, gut abgegrenzt und fachlich wertvoll sein: ein Bereich, den das Business ohnehin ändern will, oder einer, der häufig Fehler produziert. Jede weitere Funktion folgt demselben Zyklus aus Nachbauen, Umschalten, Beobachten. Fowler betont, dass der große Vorteil dieses Vorgehens im reduzierten Risiko liegt, weil jeder Schritt klein ist und das Altsystem als Rückfallebene erhalten bleibt.
Phase 3: Koexistenz von alt und neu
Die längste Phase ist die, in der beide Systeme gleichzeitig produktiv sind. Hier entscheidet sich, ob das Projekt gelingt. Das neue System braucht Zugriff auf Daten, die noch im alten liegen, und umgekehrt. AWS empfiehlt in seiner Prescriptive Guidance dafür einen Anti-Corruption Layer, also eine Übersetzungsschicht, die Aufrufe zwischen altem und neuem Datenmodell vermittelt, sowie eine Synchronisation über Nachrichten-Queues, wenn beide Systeme eigene Datenbanken halten. Je sauberer diese Grenzen gezogen sind, desto weniger Überraschungen tauchen später auf.
Phase 4: Rückbau
Wenn die letzte Funktion umgezogen ist, bekommt das Altsystem keine Anfragen mehr und kann abgeschaltet werden. Danach wird auch die Fassade entfernt oder bewusst als dauerhaftes Gateway beibehalten. Dieser Schritt wird in vielen Projekten vergessen. Ein Altsystem, das zwar nichts mehr tut, aber noch läuft, kostet Lizenzen, Hosting und Aufmerksamkeit und bleibt ein Sicherheitsrisiko.
Anwendung: vom Monolithen zu Microservices
Der klassische Anwendungsfall ist die Zerlegung eines gewachsenen Monolithen in Microservices. Die AWS-Dokumentation zum Strangler-Fig-Pattern beschreibt genau diesen Weg: Ein API-Gateway wird zwischen Oberfläche und Monolith gesetzt, dann werden einzelne Services wie Benutzerverwaltung, Warenkorb oder Kundenkonto nacheinander herausgelöst und als eigenständige Dienste mit eigener Datenhaltung betrieben. Der Monolith schrumpft mit jedem Schritt, bis er stillgelegt werden kann.
Für ein mittelständisches Unternehmen mit einem ERP-nahen Backend, einer alten Shop-Software oder einem selbst entwickelten Kundenportal heißt das konkret: Du musst nicht entscheiden, ob du „alles neu“ machst. Du entscheidest, welcher Bereich als Erster herausgelöst wird. Häufig ist das ein Bereich mit hoher Änderungsfrequenz und klaren Schnittstellen, etwa Preisberechnung, Auftragsstatus oder die Authentifizierung. Die Schnittstelle zum Rest des Systems ist dann oft eine REST-API, die auch dann bestehen bleibt, wenn der Monolith längst verschwunden ist.
Ein Nebeneffekt, den viele unterschätzen: Das Pattern zwingt dazu, das Altsystem wirklich zu verstehen. Beim Nachbauen einer Funktion fallen die undokumentierten Sonderfälle auf, die das Geschäft seit Jahren stillschweigend trägt. Fowler nennt genau dieses Problem als Hauptgrund, warum komplette Neuentwicklungen scheitern: Niemand kennt mehr das vollständige Verhalten des alten Systems, und beim Rewrite wird ein großer Teil davon unbeabsichtigt wieder nachgebaut.
Anwendung auf mobile Apps: Brownfield-Integration
Weniger bekannt, aber für viele Unternehmen aktueller, ist die Anwendung des Musters auf mobile Apps. Eine bestehende native App in Swift oder Kotlin, die seit Jahren im Store liegt, lässt sich nicht einfach durch eine Fassade auf Serverseite ablösen. Die Abfangstelle liegt hier in der App selbst: Die Navigation entscheidet pro Bildschirm, ob eine native Ansicht oder ein neues Modul angezeigt wird.
Technisch funktioniert das über die sogenannte Brownfield-Integration. React Native und Flutter lassen sich als Modul in eine bestehende native App einbetten. Die native Shell bleibt bestehen, mit Login, Push-Benachrichtigungen, Hardware-Zugriff und Store-Konfiguration. Einzelne Screens oder ganze Bereiche werden nach und nach durch Cross-Platform-Module ersetzt, die iOS und Android gleichzeitig bedienen. Der Nutzer merkt davon im besten Fall nichts, weil die App zu jedem Zeitpunkt vollständig funktioniert und über denselben Store-Eintrag aktualisiert wird.
Dieses Vorgehen hat für Unternehmen, die eine Bestands-App modernisieren müssen, einen praktischen Vorteil: Es lässt sich mit den Fristen der App-Stores vereinbaren. Wer wegen neuer Target-SDK-Anforderungen ohnehin ein Release ausliefern muss, kann dieses Release als ersten Schritt der Ablösung nutzen, statt zwölf Monate auf eine komplett neue App zu warten. Welche Technologie für die neuen Module sinnvoll ist, hängt vom Team und vom Bestand ab; einen Überblick gibt der Eintrag zur Cross-Platform-Entwicklung. In der App-Entwicklung bei nextlevels kommen dafür je nach Ausgangslage React Native oder Flutter zum Einsatz, auch dann, wenn ein nativer Kern erhalten bleibt.
Realbeispiel: Shopify und die iterative Portierung der Shopify-App
Ein öffentlich gut dokumentiertes Beispiel ist die Migration der mobilen Apps von Shopify auf React Native. Im Januar 2020 kündigte Shopify an, alle neuen mobilen Apps in React Native zu bauen, beantwortete die Frage nach einem Rewrite der bestehenden nativen Apps aber ausdrücklich mit „Nein“ und überließ die Entscheidung jedem App-Team. Ende 2022 beschrieb der Staff Developer Mauricio de Meirelles im Shopify-Engineering-Blog, wie das in der Praxis aussah: Für die Shopify-App mit rund 300 Bildschirmen pro Plattform entschied sich das Team gegen eine Neuentwicklung und für eine schrittweise Übernahme. Zunächst wurde nur der Root-Screen portiert, was etwa vier Monate dauerte, während die inneren Feature-Screens nativ blieben. Danach galt die Regel „alle neuen Features in React Native, bestehende Features werden parallel migriert“, intern „Iterative Porting“ genannt. Das ist das Strangler-Fig-Pattern auf App-Ebene.
Bemerkenswert ist der Kontrast im selben Unternehmen. Für die Point-of-Sale-App entschied Shopify sich nach eigener Aussage für einen vollständigen Rewrite, weil sich die Probleme nicht mit inkrementellen Änderungen beheben ließen. Dasselbe Unternehmen nutzte also beide Strategien, je nach Zustand des Altsystems. Im Januar 2025 zog Mustafa Ali, Director of Engineering, Bilanz: Alle mobilen Apps liefen nach fünf Jahren auf React Native, mit Bildschirm-Ladezeiten unter 500 Millisekunden (P75) und über 99,9 Prozent absturzfreien Sitzungen; „100 Prozent React Native“ bezeichnete er dabei ausdrücklich als Anti-Ziel, weil Hardware-Zugriff und Hintergrundprozesse nativ blieben. InfoQ fasste diese Retrospektive im April 2025 zusammen.
Die Geschichte hat eine Pointe, die zum Pattern passt: Im September 2026 kündigte Shopify an, die Apps wieder nativ in Swift und Kotlin zu bauen, weil KI-Coding-Agenten den Aufwand für zwei Plattformen inzwischen stark senken. Die Shop-App wurde dafür in zwölf Wochen komplett neu gebaut. Für dich heißt das nicht, dass eine der beiden Richtungen falsch war. Es heißt, dass Technologieentscheidungen bei Apps eine Halbwertszeit haben und dass ein Vorgehen, das die App zu jedem Zeitpunkt lauffähig hält, bei jedem Richtungswechsel hilft.
Vorteile und Risiken
Das Pattern ist kein Selbstläufer. Es tauscht ein großes, einmaliges Risiko gegen viele kleine, dauerhafte Aufwände. Ob dieser Tausch sich lohnt, hängt von der Ausgangslage ab.
| Aspekt | Vorteil | Risiko | Gegenmaßnahme |
|---|---|---|---|
| Risiko pro Schritt | Jede Umstellung ist klein und rückgängig zu machen | Viele kleine Schritte summieren sich zu langer Laufzeit | Scheiben nach Geschäftswert priorisieren, Fortschritt messen |
| Zwei Stacks parallel | Neues Wissen entsteht, während das Alte noch läuft | Doppelte Wartung, doppelte Builds, doppelte Fehlerquellen | Klare Zuständigkeiten, kein neues Feature mehr im Altsystem |
| Endtermin | Kein harter Cut-over-Tag, kein Wochenende der Angst | Ohne Enddatum bleibt das Altsystem für immer halb am Leben | Abschalttermin und Rückbau von Anfang an einplanen |
| Datenkonsistenz | Daten können schrittweise migriert werden | Zwei Wahrheiten für denselben Datensatz, Synchronisationsfehler | Pro Entität genau ein führendes System, Anti-Corruption Layer |
| Fassade | Zentrale Stelle für Routing, Logging, Feature-Flags | Engpass oder Single Point of Failure | Fassade schlank halten, Lasttest, Ausfallsicherheit |
Das gefährlichste Risiko ist aus unserer Sicht nicht technisch, sondern organisatorisch. Ein Strangler-Fig-Projekt ohne verbindlichen Abschalttermin wird zur Dauerbaustelle, in der zwei Systeme, zwei Deployments und zwei Wissensstände nebeneinander gepflegt werden. Die laufenden Kosten dieses Zustands gehören in jede Betrachtung der Total Cost of Ownership. Wer das Pattern wählt, sollte deshalb nicht nur die erste Scheibe planen, sondern auch die letzte.
Das zweite große Risiko ist die Datenhaltung. Solange beide Systeme in dieselbe Datenbank schreiben, ist das Problem überschaubar, aber die Kopplung bleibt. Sobald das neue System eine eigene Datenbank bekommt, brauchst du eine Regel, welches System für welche Daten führend ist, und einen Mechanismus, der Änderungen zuverlässig überträgt. Microsoft weist zudem darauf hin, dass bei Altsystemen, deren Code nicht mehr änderbar ist, Change Data Capture auf Datenbankebene ein Ausweg sein kann.
Abgrenzung zu Big-Bang-Rewrite und Refactoring
Das Strangler-Fig-Pattern wird oft als Mittelweg zwischen zwei Extremen beschrieben. Das trifft es nur zum Teil, denn es ist weniger ein Kompromiss als ein eigener Weg mit eigenen Regeln.
Beim Big-Bang-Rewrite wird das neue System parallel entwickelt und an einem Stichtag komplett umgeschaltet. Das klingt sauber, hat aber zwei strukturelle Schwächen. Erstens bekommt das Business während der Entwicklungszeit keine neuen Funktionen, oder das Altsystem wird weiterentwickelt und das neue muss hinterherlaufen. Zweitens muss das neue System am Stichtag alles können, was das alte konnte, inklusive der Sonderfälle, die niemand mehr dokumentiert hat. Fowler schreibt, er habe diesen scheinbar einfachen Plan die meiste Zeit „in Flammen aufgehen“ sehen. Es gibt Situationen, in denen der Rewrite trotzdem richtig ist: wenn das Altsystem so klein ist, dass die Ablösung in Wochen gelingt, wenn sich Anfragen nicht abfangen lassen oder wenn die Architektur so verfahren ist, dass keine Scheibe sauber herauszulösen wäre. Shopifys POS-Rewrite ist ein Beispiel für diese bewusste Entscheidung.
Refactoring verbessert die innere Struktur eines Systems, ohne sein Verhalten nach außen zu ändern, und bleibt dabei im selben Technologie-Stack. Es baut technische Schuld ab, ersetzt das System aber nicht. Das Strangler-Fig-Pattern ersetzt. Beide schließen sich nicht aus: Häufig wird eine Funktion im Altsystem zunächst refaktoriert, damit sie eine klare Schnittstelle bekommt, und erst dann herausgelöst. Refactoring ist also oft die Vorbereitung einer Scheibe, nicht ihre Alternative.
Eine dritte Abgrenzung betrifft das Replatforming, also den Wechsel der Plattform, etwa von einem Shopsystem zu einem anderen oder von einem eigenen Rechenzentrum in die Cloud. Replatforming beschreibt das Ziel; das Strangler-Fig-Pattern beschreibt einen möglichen Weg dorthin. Nicht jedes Replatforming läuft inkrementell, und nicht jedes Strangler-Fig-Projekt wechselt die Plattform.
Wann das Pattern passt und wann nicht
Das Strangler-Fig-Pattern ist dann die richtige Wahl, wenn das Altsystem geschäftskritisch ist, wenn es über längere Zeit weiterlaufen kann und wenn sich seine Aufrufe an einer Stelle abfangen lassen. Es ist die falsche Wahl, wenn das System klein genug für einen schnellen Komplettersatz ist, wenn das Altsystem aus Lizenz- oder Sicherheitsgründen kurzfristig abgeschaltet werden muss oder wenn der Quellcode und die Datenbank nicht zugänglich sind. Vor der Entscheidung lohnt sich eine kurze Bestandsaufnahme der Schnittstellen, des Datenmodells und der fachlichen Bereiche, die sich als erste Scheiben eignen. Was dabei herauskommt, ist meist ehrlicher als jede Schätzung für einen Rewrite.
Häufige Fragen zum Strangler-Fig-Pattern
Wie lange dauert eine Migration nach dem Strangler-Fig-Pattern?
Das hängt von der Größe des Altsystems und der Zahl der Scheiben ab. Shopify brauchte für seine gesamte App-Landschaft rund fünf Jahre, allein die Portierung des Root-Screens der Shopify-App dauerte etwa vier Monate. Bei einem mittelständischen Backend sind je nach Umfang sechs bis 24 Monate realistisch. Entscheidend ist, dass von Anfang an ein Abschalttermin festgelegt und der Fortschritt in migrierten Funktionen gemessen wird.
Funktioniert das Strangler-Fig-Pattern auch bei einer mobilen App?
Ja, über die Brownfield-Integration. React Native oder Flutter werden als Modul in die bestehende native App eingebettet, und die Navigation entscheidet pro Bildschirm, ob eine alte native Ansicht oder ein neues Modul angezeigt wird. Die App bleibt zu jedem Zeitpunkt vollständig lauffähig und kann über denselben Store-Eintrag aktualisiert werden. Die Shopify-App wurde genau so migriert.
Was ist der Unterschied zwischen Strangler-Fig-Pattern und Refactoring?
Refactoring verbessert die innere Struktur eines Systems im selben Technologie-Stack, ohne es zu ersetzen. Das Strangler-Fig-Pattern ersetzt das System Funktion für Funktion durch ein neues, meist in einem anderen Stack. In der Praxis geht Refactoring einer Scheibe oft voraus, damit die Funktion eine saubere Schnittstelle bekommt, bevor sie herausgelöst wird.
Die Originalbeschreibung des Musters findest du bei Martin Fowler, eine ausführliche Architekturanleitung mit Fassade, Anti-Corruption Layer und Datensynchronisation in der Microsoft-Azure-Architekturdokumentation.