Ohne Ausfallzeit ablösen: Strangler-Pattern-Migration in 7 Schritten

Setzen Sie auf die Strangler-Pattern-Migration, wenn Sie einen grossen, geschäftskritischen Monolithen ohne Ausfallzeit ablösen müssen: Führen Sie eine Routing-Fassade ein, lösen Sie einen Bounded Context nach dem anderen heraus und prüfen Sie jede Scheibe mit Schattenverkehr, bevor Sie umschalten. Der Zielkonflikt ist real. Sie tauschen den schnellen Big-Bang-Zeitplan gegen einen längeren, sichereren mit dem Zusatzaufwand des Parallelbetriebs. Dafür erhalten Sie laufend Nutzen, einen funktionierenden Weg zurück und kein Alles-oder-nichts-Risiko an einem einzigen Umschaltwochenende.

---

Kurz gefasst:

• Die erste Fassade muss eine produktive, versionierte Routing-Schicht sein, die den Verkehr weiterleitet, ohne die Anfragen zu verändern. Wer diesen Schritt überspringt, handelt sich später komplizierte Rollbacks ein.

• Eine Anti-Corruption Layer und Feature-Flags mit klarer Verantwortung und Verfallsdatum verhindern, dass Eigenheiten des Altsystems ins neue System einsickern, und vermeiden dauerhaftes Provisorium.

• Die Schrittfolge beginnt mit der Zerlegung des Systems in Bounded Contexts. Danach migrieren Sie schrittweise: zuerst die Lesezugriffe umleiten, später die Schreibzugriffe, mit vorab definierten Abnahmekriterien und Rollback-Auslösern.

• CDC in Kombination mit dem Transactional-Outbox-Pattern ist die sicherste Methode zur Datensynchronisation bei langen Migrationen, denn Dual-Write-Verfahren riskieren Inkonsistenzen und stille Fehler.

• Laufende Überwachung von Latenz, Fehlerraten und Geschäftskennzahlen mit vorab festgelegten Schwellenwerten ist für ein sicheres Umschalten unverzichtbar. Automatisierte Rollbacks sorgen dafür, dass Sie bei Problemen schnell wieder auf sicherem Boden stehen.

---

Was ist das Strangler Pattern, und wann setzen Sie es ein?

Das Strangler-Fig-Pattern hat seinen Namen vom echten Baum: Die Würgefeige wächst um einen Wirtsstamm herum und übernimmt nach und nach dessen tragende Rolle, bis das ursprüngliche Holz nicht mehr gebraucht wird. In der Software stellen Sie eine Fassade vor Ihr Altsystem, die jede eingehende Anfrage entweder an das alte System oder an einen neuen Dienst leitet, Fähigkeit für Fähigkeit, bis der Altcode nichts mehr zu tun hat. Das ist das strangler fig pattern, wie es Microsofts Azure Architecture Center definiert, und es ist der Standardbezug für alle, die eine solche Migration planen.

Nicht jede Ablösung eines Altsystems braucht so viel Zeremonie. Ein kleines internes Werkzeug mit drei Nutzer:innen, das ein Wochenende Ausfall verträgt, übersteht vermutlich auch eine Neuentwicklung am Stück. Greifen Sie zur Strangler-Pattern-Architektur, wenn mehrere dieser Punkte zutreffen:

• Das System hat echte Verfügbarkeitsanforderungen, und ein misslungenes Umschalten würde Umsatz oder Vertrauen kosten.

• Sie können klar abgegrenzte Bounded Contexts erkennen (Fakturierung, Lagerbestand, Authentifizierung) statt eines einzigen Knäuels aus Logik.

• Sie haben genug Zugriff auf den Altcode und dessen Datenschicht, um Verkehr abzufangen und zu spiegeln.

• Den Verantwortlichen im Unternehmen sind schrittweise Erfolge lieber, als ein Jahr auf eine einzige grosse Enthüllung zu warten.

Martin Fowler, der die strangler fig metaphor bekannt gemacht hat, versteht Modernisierung als Erkundungsarbeit. Sie kennen selten alle Eigenheiten des Altsystems im Voraus. Sie lernen sie kennen, indem Sie den neuen Dienst mit echtem Verkehr betreiben und beobachten, wo er vom alten abweicht.

Welche Bausteine brauchen Sie, bevor Sie etwas herauslösen?

Vier Teile müssen vorhanden sein, bevor Sie den ersten Bounded Context anfassen. Wer eines davon auslässt, landet bei genau jenen Strangler-Migrationen, die als dauerhafte Halbfertigbaustelle enden.

1. Die Fassade. Das kann ein API-Gateway sein, ein Reverse Proxy wie Nginx oder ein eigens gebauter Router. Die Routing-Entscheidung kann über den URL-Pfad, einen Request-Header, ein Nutzersegment oder eine prozentuale Canary-Verteilung fallen. Die choice of façade shapes everything downstream, auch wie fein Ihr Rollback ausfallen kann.

2. Die Anti-Corruption Layer (ACL). Sie übersetzt zwischen dem Datenmodell des Altsystems und dem Modell Ihres neuen Dienstes, damit Altlasten nicht in sauberen neuen Code durchsickern. Contract-Tests gegen diese Schicht finden Brüche, bevor der Produktivbetrieb sie findet.

3. Feature-Flags. Trennen Sie Release-Schalter (neuer Codepfad für echte Nutzer:innen) von Betriebsschaltern (Verhalten für Last oder Konfiguration anpassen) und Notschaltern (sofortiges vollständiges Zurücksetzen). Jedes Flag braucht eine namentlich verantwortliche Person und ein Verfallsdatum, sonst wird daraus ein dauerhaftes Provisorium, an dessen Freigabe sich niemand mehr erinnert.

4. Werkzeuge für Vergleich und Schattenverkehr. Schicken Sie Produktivverkehr an beide Systeme, vergleichen Sie die Ausgaben Feld für Feld und schalten Sie den neuen Pfad erst frei, wenn die Abweichungen unter einen Schwellenwert fallen, den Sie vorab festgelegt haben und nicht unter Druck improvisieren.

Profitipp: Legen Sie für jedes Feature-Flag einen Kalendereintrag für dessen eigene Entfernung an. Ein Flag ohne Verfallsdatum ist ein Flag, das die Entwicklerin überlebt, die es geschrieben hat.

Wie planen Sie eine Strangler-Pattern-Migration Schritt für Schritt?

Die Reihenfolge zählt mehr als die Werkzeuge. Architekt:innen, die hier Schritte überspringen, stehen am Ende mit einem verteilten Monolithen da statt mit einem modernisierten System.

1. Bestand aufnehmen und nach Domänen zerlegen. Bilden Sie Ihr Altsystem in Bounded Contexts ab, bevor Sie eine einzige Zeile neuen Code schreiben. Hier entscheidet sich, ob eine Migration Fahrt aufnimmt oder in der Analyse stecken bleibt.

2. Die Fassade als wirkungslose Naht einbauen. In dieser Phase leitet sie alles unverändert ans Altsystem weiter, und sie gehört vom ersten Tag an in die Versionsverwaltung.

3. Die erste Scheibe nach Wert oder geringer Kopplung wählen. Bevorzugen Sie eine Fähigkeit, die für das Geschäft zählt, aber nicht sechs weitere Teilsysteme berührt. Ein practical migration guide for architects empfiehlt, mit vertikalen fachlichen Scheiben zu starten und nicht mit horizontalen technischen Schichten wie «alle Datenbankaufrufe».

4. Die ACL und den neuen Dienst bauen, danach parallel betreiben, mit Schattenverkehr und einem Vergleichswerkzeug, das auf Abweichungen achtet.

5. Zuerst die Lesezugriffe hochfahren, dann die Schreibzugriffe. Leiten Sie einen kleinen Prozentsatz des Leseverkehrs als Canary auf den neuen Pfad, halten Sie, erweitern Sie, und beginnen Sie erst mit der Migration der Schreibzugriffe, wenn sich das Lesen als stabil erwiesen hat.

6. Abnahmekriterien und Rollback-Auslöser festlegen, bevor Sie hochfahren, nicht erst, wenn um zwei Uhr nachts etwas kaputtgeht.

7. Formell ausser Betrieb nehmen. Entfernen Sie den alten Codepfad, räumen Sie das Datenbankschema auf und ziehen Sie die Routing-Regel der Fassade für diese Fähigkeit an einem geplanten Datum zurück.

Phase	Hauptrisiko, wenn sie fehlt	Aufwand für Rollback
Fassade einbauen	Später fehlt die sichere Naht zum Umleiten	Gering, Konfiguration zurücksetzen
ACL und Schattenverkehr	Dateneigenheiten des Altsystems verderben den neuen Dienst	Mittel
Canary für Lesezugriffe	Stille Abweichungen in den Ausgaben erreichen die Nutzer:innen	Mittel
Canary für Schreibzugriffe	Die Daten der beiden Systeme laufen auseinander	Hoch
Ausserbetriebnahme	Fassadenschulden bleiben unbefristet bestehen	Entfällt, nur ein Weg

Welche Datenstrategie passt: CDC, Outbox oder Dual-Write?

An der Datenmigration scheitern die meisten Strangler-Vorhaben, nicht an der Routing-Logik. Zwei Systeme, die in zwei Datenspeicher schreiben, erzeugen ein Synchronisationsproblem, das erst verschwindet, wenn einer der Speicher abgeschaltet wird.

Dual-Write, bei dem Ihre Anwendung in derselben Anfrage sowohl in die alte als auch in die neue Datenbank schreibt, sieht am Whiteboard einfach aus und geht im Produktivbetrieb dauernd schief. Schlägt der zweite Schreibvorgang fehl, nachdem der erste geglückt ist, haben Sie still inkonsistente Daten, ohne dass irgendein Signal auf den Fehler hinweist.

Change Data Capture (CDC) zusammen mit dem Transactional-Outbox-Pattern ist der sicherere und in der Branche bevorzugte Weg. Das Outbox-Pattern schreibt Ihre fachliche Änderung und einen Ereignisdatensatz in derselben Datenbanktransaktion. Ein separater Relay-Prozess, etwa Debezium, das das Write-Ahead-Log einer Datenbank mitliest, veröffentlicht dieses Ereignis anschliessend asynchron auf einem Message Bus. Nichts geht verloren, denn Ereignis und fachlicher Schreibvorgang werden entweder beide bestätigt oder beide zurückgerollt.

Die Praxis ist sich bei diesem Zielkonflikt einig: Dual-Write ist fragil und nur eine Übergangslösung, während CDC plus Outbox der bevorzugte Ansatz ohne Ausfallzeit ist, sobald Sie länger als ein paar Wochen damit arbeiten.

In sicherheitskritischen Bereichen wie Zahlungen oder Berechtigungen genügen selbst CDC und Outbox allein nicht. Betreiben Sie Schattenschreibvorgänge mit lückenlosem Vergleich Feld für Feld und verlangen Sie ein Zeitfenster ganz ohne Abweichungen, bevor Sie das neue System echten Schreibverkehr übernehmen lassen. Eine falsche Berechtigungsprüfung wiegt schlicht anders als eine falsche Produktbeschreibung, und Ihr Migrationsplan sollte diesen Unterschied ausdrücklich abbilden.

Welche Tests und Rollback-Sicherungen brauchen Sie im Produktivbetrieb?

Vergleichswerkzeuge für den Schattenverkehr brauchen festgelegte Abnahmeschwellen, bevor Sie auch nur ein Prozent echten Leseverkehr umleiten, nicht danach. Entscheiden Sie im Voraus, was «genügend nah» für die Ausgabe Ihres Vergleichs bedeutet, denn «wir merken es schon, wenn wir es sehen» ist kein Schwellenwert.

Beobachten Sie diese Signale laufend, sobald der neue Pfad live ist:

• Latenz-Perzentile (p50, p95, p99), nicht nur Mittelwerte, die Ausreisser verstecken.

• Fehlerrate des neuen Dienstes im Vergleich zur Basislinie des Altsystems für denselben Verkehrsausschnitt.

• Gleichstand bei den Geschäftskennzahlen: Anzahl Bestellungen, Umsatz pro Stunde, Erfolgsquote bei Anmeldungen, was auch immer für das Geschäft wirklich zählt.

• Korrelations-IDs, die durch beide Systeme laufen, damit Sie eine Anfrage über die Fassade, beide Backends und das Vergleichswerkzeug hinweg nachverfolgen können.

Legen Sie einen Canary-Zeitplan mit echten Haltephasen fest. Fahren Sie nie an einem Freitagnachmittag hoch.

Profitipp: Automatisieren Sie das Rollback auf eine bekannt funktionierende Fassadenkonfiguration aus der Versionsverwaltung, und stoppen Sie die Zeit. Dauert ein Rollback länger als fünf Minuten, ist es noch kein echtes Sicherheitsnetz, sondern Hoffnung.

Was gehört auf die Strangler-Checkliste jeder Architektin und jedes Architekten?

Ampersand Labs hat Migrationen von Altsystemen für Organisationen mit wirklich komplizierten Altbeständen durchgeführt, darunter Hunderte miteinander verbundene Websites einer Schweizer Partei aus einem einzigen System. Einige wenige Kontrollen unterscheiden dabei immer wieder die Migrationen, die zu Ende kommen, von jenen, die jahrelang stocken:

• Bestimmen Sie für die Fassade selbst eine namentlich verantwortliche Person und ein Service-Level-Ziel. Sie ist produktive Infrastruktur, keine Behelfsbrücke.

• Legen Sie für jede herausgelöste Fähigkeit am selben Tag ein Datum für die Ausserbetriebnahme fest, an dem Sie mit dem Herauslösen beginnen, nicht erst, wenn sie live ist.

• Bevorzugen Sie vertikale Scheiben entlang der Bounded Contexts gegenüber horizontalen technischen Schichten, denn horizontales Schneiden ist genau der Weg, auf dem verteilte Monolithen aus Versehen entstehen.

• Halten Sie erfahrene Entwickler:innen von der Planung über das Herauslösen bis zur Übergabe im Projekt, denn Wissen, das mitten im Projekt verloren geht, macht aus «vorübergehenden» Fassadenschulden dauerhafte.

• Verlangen Sie pro Herauslösung drei Ergebnisse: einen Vergleichsbericht, ein schriftliches Rollback-Handbuch und den Pull Request zur Ausserbetriebnahme, der den alten Pfad entfernt.

Ohne festes Abschaltziel bleibt der Altcode einfach liegen, und die Einsparungen, die Sie dem Unternehmen versprochen haben, tauchen in keiner Rechnung je auf.

Senior-Begleitung für Ihre Strangler-Migration

Strangler-Migrationen sollten so laufen, wie es dieser Leitfaden beschreibt: Fassade zuerst, ein Bounded Context nach dem anderen, Vergleichsdaten vor jedem Umschalten. Der Vorteil dieses Vorgehens liegt in der durchgehenden Führung: Erfahrene Entwickler:innen sind vom ersten Architekturgespräch bis zum letzten Pull Request zur Ausserbetriebnahme dabei, damit der Plan für das Herauslösen stimmig bleibt.

Diese Kontinuität zählt genau bei der Arbeit, um die es in diesem Beitrag geht: bei Migrationen und Replatforming von Altsystemen, wo verlorenes Wissen mitten im Projekt aus einem Sechsmonatsplan eine Hetzjagd über achtzehn Monate macht. Ampersand übernimmt auch die Systemintegration und die API-Arbeit, auf die CDC- und Outbox-Pipelines angewiesen sind, sowie den laufenden Betrieb, sobald Ihre Fassade produktiv ist.

Wenn Sie eine Migration abstecken und vor der Zusage die Einschätzung erfahrener Entwickler:innen zu Ihrer Architektur möchten: Schauen Sie sich aktuelle Preise und Zusammenarbeitsmodelle an oder werfen Sie einen Blick auf aktuelle Schweizer Softwareprojekte, um zu sehen, wie sich der Ansatz in der Praxis auswirkt.

Quellen

Für eine tiefere technische Grundlage über diesen Leitfaden hinaus beginnen Sie bei den massgeblichen Quellen: dem Eintrag zum Strangler-Fig-Pattern im Azure Architecture Center von Microsoft, Martin Fowlers ursprünglichem Bliki-Beitrag und der Wikipedia summary für einen schnellen enzyklopädischen Überblick. Zu den Umsetzungsdetails von CDC und Outbox behandelt der Praxisbeitrag des HLD Handbook die Abwägungen bei den Werkzeugen ausführlich. Wenn Ihre Migration öffentlich sichtbare URLs berührt, lohnt sich diese SEO-Checkliste für Migrationen, bevor Sie die Routing-Regeln Ihrer Fassade festzurren.

• strangler fig pattern

• strangler fig metaphor

• choice of façade shapes everything downstream

• practical migration guide for architects

Häufige Fragen

Was ist das Strangler Pattern in der Softwarearchitektur?

Es ist eine Migrationstechnik, bei der eine Routing-Fassade vor dem Altsystem steht und jede Anfrage entweder an den alten Code oder an einen neuen Dienst als Ersatz leitet. Mit der Zeit wandert immer mehr Verkehr zu den neuen Diensten, bis das Altsystem vollständig abgeschaltet werden kann.

Wie lange dauert eine Strangler-Pattern-Migration?

Das hängt von Grösse und Komplexität des Systems ab. Fallreihen aus der Branche zeigen jedoch durchgehend, dass Strangler-Migrationen longer than big-bang rewrites while carrying lower deployment risk. Rechnen Sie für einen einzelnen Bounded Context mit Monaten und für einen ganzen Altbestand womöglich mit Jahren.

Ist Dual-Write während einer Migration je vertretbar?

Dual-Write kann als kurzfristige Brücke für unkritische Daten funktionieren, ist aber fragil: Ein Teilfehler hinterlässt zwei still inkonsistente Systeme. Für alles, was länger als ein paar Wochen läuft, ist CDC in Verbindung mit dem Transactional-Outbox-Pattern der sicherere Standard.

Was ist der grösste Fehler von Teams beim Strangler Pattern?

Die Fassade als Provisorium zu behandeln. Ohne zugewiesene Verantwortung, ein SLO und ein am ersten Tag festgelegtes Datum für die Ausserbetriebnahme bleiben die Fassade und ihre alten Codepfade meist unbegrenzt bestehen, statt abgeschaltet zu werden.

Kann Ampersand Labs eine Strangler-Migration von A bis Z begleiten?

Ja. Ampersand Labs bietet Migration und Replatforming von Altsystemen unter der Leitung erfahrener Entwickler:innen, von der Planung bis zur Ausserbetriebnahme, dazu die Systemintegration, die CDC- und Outbox-Pipelines voraussetzen. Die aktuellen Preisangaben finden Sie auf der Preisseite von Ampersand Labs.

Empfohlen

• Migration & Replatforming von Altsystemen in Zürich

• Die Mitte: über 600 Websites für eine Schweizer Partei aus einem System betreiben.

• Systemintegration & API-Entwicklung in Zürich

• Habitects AG: die technische Seite einer Plattform für Badsanierungen verantworten, bis über eine Fusion hinaus.