Strangler Fig Pattern – Legacy-Systeme schrittweise ablösen

Ein Legacy-System (gewachsene Bestandssoftware) verschwindet selten „einfach so“. Oft steckt darin die wichtigste Fachlogik, während Technologie-Stack, Deploy-Prozess oder Datenzugriff nicht mehr zu den heutigen Anforderungen passen. Ein vollständiges Neuschreiben klingt verlockend, scheitert aber in der Praxis häufig an Zeit, Budget, unklaren Anforderungen und der schwer reproduzierbaren Fachlichkeit, die über Jahre in Tickets, Bugfixes und Sonderfällen entstanden ist.

Das Strangler Fig Pattern setzt hier an: Statt eine Anwendung abrupt zu ersetzen, wird neue Funktionalität schrittweise außen herum aufgebaut und der alte Kern Stück für Stück „abgeschnürt“, bis er entbehrlich wird. Entscheidend ist nicht nur die Architekturidee, sondern das technische Handwerkszeug: Routing, Schnittstellen, Datenstrategie, Observability, Tests und ein belastbarer Rückfallweg.

Welche Modernisierungsprobleme das Muster wirklich löst

In realen Systemen treffen meist mehrere Schmerzpunkte gleichzeitig aufeinander: neue Produktanforderungen kollidieren mit langen Release-Zyklen, Änderungen am Datenmodell sind riskant, und einzelne Komponenten sind so eng gekoppelt, dass selbst kleine Anpassungen Nebenwirkungen erzeugen. Genau hier ist ein inkrementeller Ansatz hilfreich.

Typische Symptome in Legacy-Anwendungen

• Änderungen benötigen auffällig viel Abstimmung, weil die Auswirkungen schwer vorhersehbar sind.
• Regressionen werden spät gefunden, weil Tests fehlen oder zu langsam laufen.
• Einzelne Module sind „unantastbar“, weil Wissen fehlt oder Debugging zu teuer ist.
• Technische Limits bremsen neue Features (z.B. alte Frameworks, starre Deployments, fehlende horizontale Skalierung).

Das Muster hilft vor allem bei Systemen, die weiterhin betrieben werden müssen. Es ist weniger geeignet, wenn die Anwendung ohnehin bald abgeschaltet wird oder wenn eine klare, stabile Neuentwicklung bereits fertig konzipiert ist und parallel problemlos laufen kann.

Routing als Hebel: Requests gezielt auf Alt oder Neu lenken

Der Kernmechanismus ist kontrolliertes „Vorschalten“. Ein Reverse Proxy, API Gateway oder ein Edge-Router übernimmt die Entscheidung, ob ein Request zur alten Anwendung oder zu neuen Komponenten geleitet wird. Der Wechsel erfolgt dann nicht nach Bauchgefühl, sondern entlang technischer und fachlicher Grenzen.

Praktische Varianten für das Routing

• API Gateway: Zentraler Einstiegspunkt für Clients; geeignet, wenn mehrere Services entstehen und Authentifizierung, Rate Limits oder Transformationslogik benötigt werden.
• Reverse Proxy vor einem Web-Monolithen: Einfacher Einstieg, wenn primär URL-Pfade oder Subdomains migriert werden.
• Routing auf Feature-Ebene: Ein Teil der UI oder bestimmter Endpunkte wird neu gebaut und gezielt ausgeliefert.

Wichtig ist, dass Routing-Entscheidungen deterministisch und beobachtbar sind. Es muss jederzeit klar sein, warum ein Request bei Alt oder Neu gelandet ist (z.B. per Header, Log-Feld oder Trace-Attribut). Für robuste Schnittstellen lohnt sich ergänzend Schema-Validation für APIs, damit unerwartete Payloads früh auffallen.

Schneiden entlang von Domänen statt nach Code-Struktur

Der häufigste Fehler bei schrittweiser Ablösung: Es wird nach technischen Schichten getrennt („Controller neu, DB bleibt“), statt nach fachlichen Verantwortlichkeiten. Sinnvoller ist eine Aufteilung entlang von Domänen (z.B. „Rechnungsstellung“, „Kundenverwaltung“, „Bestand“), weil sich dort stabile Grenzen und eigene Datenhoheiten ableiten lassen.

Gute Kandidaten für den ersten Schnitt

• Module mit klarer Schnittstelle nach außen (z.B. Reporting, Import/Export, Benachrichtigungen).
• Funktionalität mit hoher Änderungsrate (hier bringt Entkopplung schnell Nutzen).
• Bereiche mit eindeutiger Datenquelle und wenig Querverweisen.

Schwieriger sind Querschnittsthemen wie Berechtigungen, Mandantenfähigkeit oder Preislogik, weil sie häufig überall „hineinleaken“. Diese Themen sollten früh sichtbar gemacht werden, aber nicht zwingend als erstes extrahiert werden.

Datenstrategie: Synchronisieren, spiegeln oder übernehmen

Die größte technische Entscheidung betrifft Daten. Neue Komponenten brauchen verlässliche Daten, gleichzeitig darf die Übergangsphase keine Inkonsistenzen erzeugen. In der Praxis ergeben sich drei typische Wege, die sich auch kombinieren lassen.

Optionen für den Umgang mit Daten

Für verlässliche Event-Weitergabe aus einer transaktionalen Welt ist das Outbox Pattern oft die pragmatische Brücke: Änderungen werden in der Datenbank atomar erfasst und anschließend zuverlässig an Messaging oder Integrationskomponenten publiziert. Das reduziert „verlorene Events“ in Übergangsphasen.

Konsistenz sauber definieren

Nicht jede Datenabweichung ist ein Fehler. Entscheidend ist eine klare Festlegung pro Domäne: Wo wird starke Konsistenz benötigt (z.B. Zahlungsauslösung), wo reicht „eventual consistency“ (zeitverzögerte Angleichung, z.B. Suchindex, Analytics)? Diese Regeln müssen in APIs und UI-Verhalten sichtbar sein, etwa durch Statusfelder, Zeitstempel oder explizite „in Verarbeitung“-Zustände.

So werden Schnittstellen stabil, obwohl zwei Welten koexistieren

Während der Migration existieren Alt- und Neusystem parallel. Das macht Schnittstellenarbeit zur wichtigsten Disziplin: Verträge müssen stabil sein, Fehlerbilder konsistent und Änderungen kontrolliert. Ein häufiger Streitpunkt ist die Frage, ob neue Komponenten die alten Endpunkte „nachbauen“ oder ob ein neues API-Design eingeführt wird.

Empfehlung für die Übergangsphase

• Extern (Client-seitig) möglichst wenige Brüche: gleiche URLs, gleiche Response-Felder, gleiches Auth-Verhalten.
• Intern dürfen neue Modelle entstehen, aber mit Übersetzern/Adaptern an der Kante.
• Versionierung nur einsetzen, wenn echte parallele Verträge unvermeidbar sind. Sonst droht langfristige Doppelpflege. Bei Bedarf hilft eine saubere Linie wie in API-Versionierung im Backend.

Für Robustheit sind zudem klare Timeouts und Fehlerrückgaben wichtig. Gerade wenn Neu-Komponenten zunächst weniger „ausgehärtet“ sind, sollten Ausfälle nicht den gesamten Request-Pfad blockieren. Ein kontrolliertes Timeout-Verhalten ist dabei wichtiger als „irgendwie schnell“; passend dazu ist Request-Timeouts im Backend als Grundlage.

Migration ohne Blindflug: Telemetrie, Logging und Release-Strategie

Inkrementelle Ablösung funktioniert nur, wenn Betriebssignale verlässlich sind. Während der Übergangszeit steigen die Fehlerquellen: Routing, Adapter, doppelte Datenflüsse, unterschiedliche Laufzeitumgebungen. Deshalb braucht es ein Minimum an Observability, bevor der erste Traffic umgelegt wird.

Messpunkte, die sich in der Praxis bewähren

• Routing-Metriken: Anteil Requests Alt/Neu, Fehlerquote pro Ziel, Latenz pro Pfad.
• Korrelations-IDs: Ein Request muss über Proxy, neue Services und Legacy nachvollziehbar sein.
• Strukturiertes Logging mit sensiblen Daten im Blick. Gerade beim Übergang werden oft zusätzliche Felder geloggt; dabei hilft HTTP-Request-Logging – strukturierte Logs ohne Datenleck.

Für Releases ist eine „Traffic Shaping“-Strategie sinnvoll: erst interne Nutzer, dann kleiner Prozentanteil, dann Ramp-up. Das funktioniert auch ohne spezielle Plattform, solange Routing-Regeln schrittweise anpassbar sind und Rollbacks schnell greifen. Feature-Toggles können ergänzen, sind aber kein Ersatz für saubere Architekturgrenzen.

Entscheidungshilfe: Welche Route passt zum aktuellen System?

• Wenn der Einstiegspunkt ohnehin konsolidiert werden muss (z.B. mehrere Clients, viele Endpunkte): Gateway oder Reverse Proxy zuerst etablieren.
• Wenn das Legacy-System besonders fragile Deployment-Prozesse hat: zunächst read-only Features auslagern (z.B. Such- oder Reporting-Pfade), um Vertrauen aufzubauen.
• Wenn Datenintegrität kritisch ist: zuerst Datenflüsse modellieren, dann Writes migrieren; Replikation oder Outbox-Mechanismen früh einplanen.
• Wenn die Anwendung stark monolithisch ist: domänennahe Schnitte wählen und Adapter an der Kante bauen, statt Querzugriffe „mitzunehmen“.
• Wenn Teams parallel arbeiten sollen: Ownership pro Domäne klären (Service-Verantwortung, Datenhoheit, On-Call), bevor Code geschnitten wird.

Konkrete Schritte, die sich in Projekten schnell auszahlen

Ein inkrementeller Ansatz steht und fällt mit einem kleinen, aber sauberen Start. Der erste Schnitt muss nicht groß sein, aber er muss End-to-End funktionieren: Routing, Build, Deploy, Monitoring, Tests und ein Rückweg.

Vorgehen in umsetzbaren Etappen

• Zielbild für 6–12 Monate skizzieren: Welche Domänen sollen eigenständig werden, welche bleiben länger im Legacy?
• Einheitlichen Eintrittspunkt herstellen (Proxy/Gateway) und Requests transparent markieren.
• Ersten Domänen-Slice wählen (klein, klar abgegrenzt) und Adapter zwischen Alt und Neu implementieren.
• Anti-Corruption Layer (Schutzschicht) an der Grenze bauen: Legacy-Datenmodelle nicht in neue Services „durchreichen“, sondern übersetzen.
• Teststrategie festlegen: Contract/Integrationstests an der Grenze, plus Smoke-Tests für Routing-Regeln.
• Traffic schrittweise umlegen, Rollback definieren, Beobachtbarkeit vor dem Ramp-up prüfen.

Gerade der Anti-Corruption Layer ist ein häufiger Kostenpunkt, aber er verhindert, dass neue Services dieselben Altlasten übernehmen. Ohne diese Schicht wird die Migration oft nur „eine neue Hülle um dieselben Probleme“.

Häufige Stolperfallen und wie sie sich vermeiden lassen

Doppelte Fachlogik erzeugt Drift

Wenn Business-Regeln parallel in Alt und Neu leben, entsteht schnell Divergenz. Statt Regeln zu kopieren, sollten Übergangslösungen bewusst gewählt werden: entweder eine Seite bleibt „Master“ für eine Domäne, oder es wird eine gemeinsame Bibliothek als Zwischenlösung genutzt. Beides ist nicht ideal, aber transparenter als implizite Doppelpflege.

Zu frühe Optimierung der Zielarchitektur

In der Migrationsphase zählt Stabilität stärker als Perfektion. Ein neuer Service darf zunächst „langweilig“ sein: klare API, solide Tests, einfache Persistenz. Erst wenn der Domänen-Schnitt trägt, lohnen sich Optimierungen wie asynchrone Workflows oder ausgefeilte Caching-Strategien.

Security und Secrets werden nebenbei gelöst

Neue Komponenten benötigen eigene Credentials, Token, Datenbank-User und Rotationsprozesse. Das sollte nicht improvisiert werden. Eine saubere Grundlage liefert sicheres Secret-Management. Für API-Schutz gilt: Auth-Entscheidungen zentralisieren (z.B. Gateway) oder konsistent in allen Services implementieren, aber nicht gemischt ohne klare Regeln.

Wann das Muster nicht die beste Wahl ist

Es gibt Situationen, in denen ein inkrementeller Ersatz mehr Komplexität erzeugt als Nutzen. Wenn der Alt-Code kaum noch genutzt wird, die Daten leicht exportierbar sind und die Neuentwicklung wirklich überschaubar bleibt, kann eine parallele Neuentwicklung mit Cutover sinnvoll sein. Ebenso, wenn regulatorische Anforderungen einen langen Parallelbetrieb erschweren oder wenn die Systemgrenzen so verwaschen sind, dass kein stabiler Domänen-Schnitt möglich ist. Dann ist zunächst Architekturarbeit nötig: Abhängigkeiten sichtbar machen, Module entkoppeln, Build- und Testzeiten in den Griff bekommen.

Richtig angewendet schafft das Muster eine kontrollierte Modernisierung: neue Teile werden produktiv genutzt, während der Legacy-Kern Stück für Stück verschwindet. Entscheidend ist das Engineering rundherum: Routing-Transparenz, klare Domänengrenzen, eine belastbare Datenstrategie und eine Migration, die Betrieb und Rollback ernst nimmt.