Ratgeber & Vergleiche · Stand: 18. Oktober 2026

Strangler Fig Pattern: Altsysteme schrittweise und kontrolliert ablösen

Beim Strangler Fig Pattern ersetzt ein Team Funktionen eines Altsystems nach und nach, während noch benötigte Teile weiterlaufen. Ein kontrollierter Übergang lenkt ausgewählte Aufgaben zur neuen Lösung. Für jeden Schritt müssen Nutzerablauf, Datenverantwortung, Abnahme und Rückfall zusammenpassen. Abgeschlossen ist er, wenn die ersetzte Altlogik und ihre unnötig gewordenen Abhängigkeiten tatsächlich entfallen.

Der Name stammt vom Bild einer Würgefeige, die sich um einen vorhandenen Baum entwickelt. Martin Fowler übertrug diese botanische Metapher auf Softwaremodernisierung. Für eine IT-Ablösung ist daran vor allem das allmähliche Übernehmen von Verantwortung hilfreich: Das Neue wächst, während das Alte gezielt weniger Aufgaben erhält.

Wann sich der Übergangsaufwand lohnt

Eine schrittweise Ablösung kann passen, wenn ein großes, in Geschäftsprozesse eingebettetes System weiter gebraucht wird, einzelne fachliche Bereiche aber begrenzbar sind. Das Unternehmen kann dann Funktionen nacheinander ersetzen und aus jedem Schritt lernen. Dazu muss es die zusätzliche Übergangsarchitektur und den zeitweisen Parallelbetrieb tragen können.

Auch Fowler betont, dass der Ansatz eine tief eingebettete Systemablösung nicht einfach macht. Prüfen Sie den Geschäftsnutzen eines Schritts gegen seine Übergangskosten. Eine neue Technologie allein ist kein ausreichender Grund, jede bestehende Funktion nachzubauen. Manche Funktion wird weiterhin benötigt, andere kann vereinfacht werden oder entfallen.

Welche Eingriffe sind tatsächlich möglich?

Erfassen Sie getrennt die Kontrolle über Eingangsrouten, Anwendungscode, Datenbank und weitere Integrationspunkte. Ein umleitbarer Webaufruf hilft wenig, wenn ein unveränderbarer Hintergrundjob weiterhin direkt in dieselben Daten schreibt. Berücksichtigen Sie außerdem Anmeldung, Berechtigungen, Benutzeroberfläche und angebundene Fremdsysteme.

Zugriff auf den gesamten Quellcode ist nicht in jedem Entwurf zwingend. Microsoft beschreibt auch veränderbare Integrationspunkte außerhalb der Anwendung. Es müssen aber genügend Eingriffsmöglichkeiten bestehen, um die gewählte Funktion kontrolliert zu übernehmen und alte Schreibwege zu beenden.

Bei fremdem SaaS bleiben die tatsächlich angebotenen APIs, Exporte und vertraglich nutzbaren Übergänge maßgeblich. Das Innere einer Anbieteranwendung lässt sich nicht wie eigener Code in neue Komponenten zerlegen. Die Prüfung kann deshalb auch ergeben, dass ein anderer Ablöseweg erforderlich ist.

Den ersten Schnitt aus Nutzersicht beschreiben

Als fiktives Beispiel dient ein Kundenportal, dessen Benachrichtigungseinstellungen bisher Teil eines Monolithen sind. Kunden sollen ihre Einstellungen ansehen, ändern, speichern und beim nächsten Aufruf korrekt wiederfinden können. Anmeldung und andere Kontofunktionen bleiben zunächst im Bestand. Es handelt sich um ein eigenes Modell, nicht um ein eBiz-Kundenprojekt.

„Die Einstellungsseite neu bauen“ wäre als Auftrag zu ungenau. Die zusammenhängende Nutzeraufgabe umfasst auch Berechtigung, aktuelle Werte, erfolgreiche Änderung und verständliche Fehlerbehandlung. Wenn die neue Seite speichert, der alte Versandprozess aber weiterhin andere Einstellungen liest, ist die Aufgabe nicht fertig.

Untersuchen Sie dafür zwei Perspektiven:

• Von außen: Welche durchgehende Aufgabe kann der Kunde nach der Freigabe erledigen? Wie bleiben Navigation, Identität, Statusanzeigen und Ergebnisdarstellung verständlich?
• Von innen: Welche Aufrufe, Tabellen, Regeln und Hintergrundjobs tragen diese Aufgabe? Wo lässt sich die Verantwortung fachlich sinnvoll begrenzen?

Die fachliche Grenze ist wichtiger als eine beliebige Bildschirmseite oder technische Schicht. Domain-driven Design und eine gemeinsame Ereignisübersicht, etwa durch Event Storming, können beim Verstehen helfen. AWS nennt Domänen und Abhängigkeiten ausdrücklich als Vorarbeit. Eine vollständige Microservice-Landkarte muss daraus nicht vor dem ersten Schritt entstehen.

Bewerten Sie Kandidaten nach Nutzen, Lerngewinn, Kopplung und Auswirkung eines Fehlers. Ein kleiner technischer Baustein kann intern bereits ausgeliefert werden; für die Nutzerfreigabe braucht es trotzdem einen kohärenten Ablauf. Im Beispiel darf ein neuer Speicherbaustein erprobt werden, bevor Kunden mit der neuen Oberfläche arbeiten.

Anfragen kontrolliert zwischen Alt und Neu verteilen

Eine Fassade oder ein Proxy kann einen stabilen Eingang bereitstellen und ausgewählte Anfragen zur neuen Implementierung leiten. Im Portalbeispiel betrifft die Regel den vereinbarten Bereich für Benachrichtigungseinstellungen. Andere Kontoanfragen bleiben beim Monolithen.

Die Route muss konkret genug sein, um Verhalten zu prüfen: Welche Lese- und Schreibaufrufe gehören zum Bereich? Gilt die Freigabe für alle Kunden oder eine definierte Gruppe? Wie werden Fehler behandelt? Eine unvollständige Regel darf nicht beispielsweise das Lesen zur neuen und das Speichern unbemerkt zur alten Logik schicken.

Die folgende Darstellung zeigt den Übergang von zunächst alten zu schrittweise neuen Funktionswegen. Der letzte Zustand betrifft die übernommene Funktion; verbleibende Bereiche können weiter im Altsystem liegen.

Die Fassade ist selbst Teil des Betriebs. Sie kann Engpass oder Ausfallstelle werden und benötigt Beobachtung sowie ausreichende Kapazität. Für manche Systeme lässt sich die Übergangsentscheidung auch über eine geeignete direkte Integration steuern. Entscheidend ist der kontrollierte Wechsel, nicht ein bestimmtes Gatewayprodukt.

Innere Aufrufe über einen Adapter übersetzen

Äußeres Routing löst nicht alle inneren Abhängigkeiten. Im Beispiel muss der verbleibende Versandprozess die gültigen Benachrichtigungseinstellungen lesen können. Ein interner Adapter kann seinen bisherigen Aufruf auf die neue Schnittstelle abbilden.

Ein Anti-Corruption Layer übersetzt dabei auch Bedeutungen: Der alte Aufruf erwartet vielleicht mehrere Ja-/Nein-Felder, die neue Komponente verwaltet benannte Kanäle und Zustände. Diese Zuordnung muss ausdrücklich definiert und geprüft werden. Microsoft beschreibt den Adapter als Schutz davor, alte Semantik ungeprüft in das neue Modell zu übernehmen.

Halten Sie fest, welche Altkomponenten ihn noch verwenden. Wenn jeder neue Baustein ständig synchron auf viele alte Funktionen angewiesen bleibt, entsteht leicht eine schwer betreibbare verteilte Kopplung. Sobald eine Abhängigkeit endet, gehört auch ihr Übergangsadapter auf die Liste zur Bereinigung.

Schrittweise Ersetzung innerhalb einer Anwendung

Die neue Funktion muss nicht sofort ein eigener Service sein. Eine verwandte Technik ist Branch by Abstraction: Aufrufender Code nutzt eine gemeinsame Abstraktion, hinter der zunächst die alte und später eine neue Implementierung stehen. Danach werden die Aufrufer schrittweise umgestellt und die nicht mehr benötigte Implementierung entfernt.

Fowler beschreibt dabei mehrere Implementierungen hinter einer Abstraktion, während das System weiterhin baubar und lauffähig bleibt. Das ist eine innere Austauschgrenze statt einer äußeren HTTP-Routingentscheidung. Beide können zur schrittweisen Modernisierung beitragen; Microservices, Container oder Kubernetes gehören nicht zur Definition des Ablöseprinzips.

Schreibverantwortung vor dem Datenumzug festlegen

Für den Modellfall legen wir je Phase einen führenden Schreibweg fest. Die neue Oberfläche und eine neue Datenbank müssen nicht gleichzeitig produktiv werden. Zunächst könnte die neue Oberfläche über eine bestehende Schnittstelle weiterhin in den alten Bestand schreiben. Später übernimmt die neue Komponente auch ihre eigenen Daten.

Diese Phasen sind ein möglicher Entwurf, keine ausführbare Migrationsanleitung. Vor seiner Umsetzung muss feststehen, wie sämtliche Schreibzugriffe erkannt, umgestellt oder gesperrt werden. Auch ein gemeinsam verwendeter Datenbankserver entscheidet nicht, welches Team fachlich für eine Einstellung verantwortlich ist.

Zwei unabhängige Schreibwege erzeugen zusätzliche Fehlerfälle: Einer kann erfolgreich sein, der andere scheitern; Wiederholungen können unterschiedliche Ergebnisse verursachen. Dual Writes sind deshalb kein kostenloser Übergang. Falls Schnittstellen, Ereignisse oder Synchronisierung verwendet werden, brauchen sie Regeln für Reihenfolge, Wiederholung, Fehler und Wiederherstellung.

Daten und fachliche Wirkung abgleichen

Eine Initialkopie allein bleibt hinter weiterlaufenden Änderungen zurück. Legen Sie fest, wie diese nachgeführt werden und wie vor der Umschaltung der vollständige relevante Bestand geprüft wird. Im Beispiel gehören aktuelle Einstellungen, Änderungen während des Kopierens und inzwischen entfernte beziehungsweise deaktivierte Einträge zum Vergleich.

Prüfen Sie zusätzlich das Verhalten: Würde derselbe Kunde für denselben Kanal dieselbe wirksame Einstellung erhalten? Roh gezählte Zeilen beantworten diese Frage nicht. Berücksichtigen Sie verzögerte Änderungen, Konflikte und fehlende Übertragungen.

Eine Schattenverarbeitung kann neue Ergebnisse zum Vergleich berechnen, ohne sie bereits produktiv zu verwenden. Sie darf im Beispiel aber keine zweite Benachrichtigung auslösen. Solche Nebenwirkungen müssen unterbunden oder kontrolliert werden. Vereinbaren Sie die akzeptierten Ergebnisse und Abweichungen vor der Freigabe. Microsoft verbindet den Wechsel des führenden Datenbestands ausdrücklich mit Validierung und Konsistenzprüfung.

Freigabe und Rückfall am selben Fall prüfen

Tests sollten die Schnittstellenverträge, die Integration der verbleibenden Altteile und den vollständigen Nutzerablauf abdecken. Im Portal gehören dazu Anmeldung, Berechtigung, Lesen, Speichern, erneutes Öffnen und das Lesen der Einstellung durch den Versandprozess. Der technische Dienst kann bereits ausgeliefert sein, während sein neuer Nutzerweg noch nicht freigegeben ist.

Eine eigene Freigabematrix verbindet die notwendigen Bedingungen:

Der letzte einfach rücknehmbare Zeitpunkt liegt in diesem Entwurf vor dem Wechsel der Schreibverantwortung. Danach muss für einen Rückweg klar sein, wie die neuen Änderungen in einen wieder arbeitsfähigen alten Bestand gelangen. Ohne ein geprüftes Verfahren dafür ist ein früherer Systemstand kein gültiger Rückfall.

Auch erhaltene Tabellen allein beweisen noch keinen funktionierenden Rückweg. Code, Schnittstellen, Datenstand und Betriebsfähigkeit müssen zusammenpassen. Microsoft warnt, dass ein Rückfall nach dem Entfernen alter Datenobjekte und Synchronisation deren Wiederherstellung und das Nachspielen von Änderungen erfordert und dadurch aufwendiger und riskanter wird. AWS empfiehlt einen Rückfallplan für jeden ersetzten Bereich.

Parallelbetrieb mit Entscheidungen verbinden

Beobachten Sie Fehler, Antwortzeiten, fachliche Ergebnisabweichungen und den Rückstand der Datenfortschreibung. Beziehen Sie die Fassade und systemübergreifende Aufrufe ein. Im Modell kann die neue Oberfläche funktionieren, obwohl der alte Versandprozess den neuen Adapter nicht mehr erreicht.

Bestimmen Sie deshalb vorab, wer bei welchem Befund entscheidet. Eine unerklärte Abweichung wirksamer Einstellungen hält die nächste Freigabe an. Ein nicht mehr erreichbarer Pflichtverbraucher erfordert eine festgelegte Betriebsreaktion. Weiterrollen, pausieren und zurückfallen sind unterschiedliche Entscheidungen; die letzte bleibt an den gültigen Rückweg gebunden. Die Kriterien müssen zum Anwendungsfall passen, statt erfundene allgemeine Grenzwerte zu übernehmen.

Den Ablöseschritt im Team wiederholbar machen

Der Arbeitsgang lässt sich für weitere Bereiche wiederholen: fachlich abgrenzen, Abhängigkeiten verstehen, neue Verarbeitung umsetzen, prüfen, kontrolliert umschalten und entfallene Altverantwortung entfernen. Ein Schritt sollte dadurch die noch benötigte Altlogik tatsächlich verringern.

Neue Anforderungen können gezielt in den neuen Bereich aufgenommen werden, wenn sie dort fachlich passen. Fehler im verbleibenden Bestand müssen währenddessen weiter behandelt werden. Halten Sie zusätzliche Alt-Erweiterungen bewusst fest: Wenn jede neue Funktion wieder im Monolithen landet, wächst die zu beseitigende Aufgabe weiter.

Backlog und Sprint-Ziele

Nehmen Sie nutzbare fachliche Inkremente, Abhängigkeiten, Abnahme und spätere Bereinigung ins Backlog auf. Im Beispiel gehören nicht nur neue Oberfläche und Speicher dazu, sondern auch Versandadapter, Vergleich, Schreibsperre und das Entfernen der alten Einstellungslogik. Benennen Sie die Verantwortlichen für den Bereich und für jeden Übergang.

Ein Sprint-Ziel kann etwa lauten, den vollständigen Einstellungsablauf über die bestehende Schreibschnittstelle überprüfbar zu machen. Ein anderes Ziel kann eine noch offene Datenabhängigkeit klären und den nächsten Schnitt absichern. Ein bloßer Stapel unabhängig fertiggestellter Bauteile beschreibt dagegen noch keine kohärente Nutzerfreigabe.

Scrum schreibt dabei kein Produktionsrelease am Sprintende vor. Laut Scrum Guide muss ein Inkrement nutzbar und geprüft sein sowie die Definition of Done erfüllen. Mehrere Inkremente im Sprint und Lieferung vor seinem Ende sind möglich; das Sprint Review ist kein Release-Gate. Das Pattern verlangt umgekehrt auch keine bestimmte agile Methode.

CI/CD und Bereitstellung

Versionierte Routingregeln, wiederholbare Auslieferung und automatisierte Tests unterstützen den Übergang. Die Pipeline sollte die relevanten Vertrags-, Integrations- und Nutzerprüfungen nachvollziehbar ausführen. Eine erfolgreiche Bereitstellung darf die gesonderte Freigabe des Schreibwechsels nicht unbemerkt ersetzen.

Canary-Releases können eine neue Version zunächst für einen begrenzten Verkehrsanteil freigeben. Blue-Green hält getrennte Bereitstellungsumgebungen für einen kontrollierten Wechsel vor. Beide sind mögliche Hilfen, keine Vorgaben des Strangler Fig Pattern. Sie lösen insbesondere keine fehlende Datenrückführung.

Kubernetes kann containerisierte Anwendungen betreiben und Rollouts unterstützen. Die Kubernetes-Übersicht grenzt davon das Bauen der Anwendung und die Festlegung der CI/CD-Praxis ab. Prüfen Sie zusätzlich Last, Ressourcen und Skalierungsbedarf während des Parallelbetriebs: Alte Anwendung, neue Komponenten und Synchronisierung benötigen zeitweise gemeinsam Kapazität. Containerautomatisierung entscheidet nicht, wann eine fachliche Übernahme sicher genug freigegeben werden kann.

Wissen und Betrieb übergeben

Dokumentieren Sie nach der Freigabe Schnittstellen, Routingregeln, führenden Datenbestand und verbliebene Abhängigkeiten. Der Betrieb braucht Alarme, Wiederanlauf und einen gültigen Rückfallweg beziehungsweise dessen ausdrückliche Grenze. Fachliche Verantwortliche müssen wissen, welche Ergebnisse sie abnehmen; Entwickler und Support müssen den neuen Fehlerweg nachvollziehen können.

Planen Sie die Schulung nach betroffenen Rollen. Im Modell sollte der Support eine fehlgeschlagene Einstellungsänderung zuordnen können, während das Betriebsteam den Versandadapter und dessen Zuständigkeit kennt. Eine dokumentierte gemeinsame Übergangsverantwortung verhindert, dass Alt- und Neuteam denselben Fehler jeweils dem anderen Bereich zuschreiben.

Altlogik und Provisorien wirklich entfernen

Vor der Stilllegung prüfen Sie Aufrufe, Hintergrundjobs, Schnittstellen, Datenzugriffe und notwendige historische Bestände. Im Beispiel darf die alte Einstellungslogik erst entfallen, wenn auch der Versand und alle weiteren bekannten Verbraucher den bestätigten neuen Weg verwenden. Rückfallentscheidung und Datenanforderungen müssen dazu freigegeben sein.

Entfernen Sie dann unbenötigte Routen, Schreibrechte, Logik und Übergangsadapter. Nicht jede Fassade muss verschwinden: Ein für verbliebene Clients weiterhin benötigter Adapter kann begründet bestehen bleiben. Seine Rolle und Verantwortung müssen dann zum dauerhaften Betrieb passen.

Dokumentieren Sie, welche Ressource, Lizenz oder Betriebszuständigkeit tatsächlich endet und welche noch benötigt wird. Eine Funktion ist nicht bereits abgelöst, weil niemand mehr ihre alte Bildschirmseite öffnet.

Typische Fehler gezielt vermeiden

Den ersten verantwortbaren Auftrag festlegen

Für den Modellfall wäre ein begrenzter Auftrag: Benachrichtigungseinstellungen als vollständige Nutzeraufgabe übernehmen, zunächst über den bestehenden Schreibweg. Der Auftrag enthält den späteren Datenwechsel und seine Rückfallgrenze, ohne diese Schritte vorzeitig freizugeben. Als Ergebnis sind Route, Zuständigkeit, Vergleich und abzulösende Altteile konkret benannt.

Rechnen Sie dabei Übergangsarchitektur, Parallelbetrieb und Teambefähigung mit ein. Wenn sich die Schreibzugriffe nicht kontrollieren lassen oder die ganze Anwendung ohnehin kurzfristig entfallen muss, kann die Entscheidung gegen dieses Muster ausfallen.

Für eine passende Abgrenzung lässt sich die kontrollierte Ablösung von SaaS und Funktionskernen mit eBiz anschließen. Ein sinnvoller Startpunkt ist eine einzelne Nutzeraufgabe samt ihrer Daten- und Integrationsrechte – und die Frage, welche alte Verantwortung nach erfolgreicher Übernahme tatsächlich wegfallen kann.