Das Strangler-Fig-Pattern: Legacy-Systeme schrittweise mit Rust modernisieren

Geschäftskritische Legacy-Systeme sind selten nur alte Software. In ihnen stecken über Jahre gewachsene Geschäftsregeln, Sonderfälle und Integrationen, die den täglichen Betrieb am Laufen halten. Genau deshalb ist ein vollständiger Ersatz so riskant: Das neue System muss nicht nur denselben Funktionsumfang liefern, sondern auch Verhalten reproduzieren, das oft nirgends vollständig dokumentiert ist.

Das Strangler-Fig-Pattern verteilt dieses Risiko auf kontrollierbare Schritte. Neue Features und klar abgegrenzte Fachfunktionen entstehen neben dem Legacy-System. Eine Routing-Schicht entscheidet, ob eine Anfrage noch vom Legacy-System oder bereits von einem neuen Service verarbeitet wird. Mit jeder erfolgreichen Umstellung verliert das Legacy-System Verantwortung, bis es schließlich abgeschaltet werden kann. Dieser Ansatz wird häufig als Legacy Software Modernization oder Legacy System Migration beschrieben.

Dieser Beitrag zeigt, wie das Strangler-Fig-Pattern funktioniert, an welchen Stellen neue Systemgrenzen entstehen sollten und wie eine schrittweise Migration in fünf Phasen gelingt. Zudem beleuchten wir die entscheidende Rolle der Datenmigration und warum performante Rust-Microservices die ideale Wahl für moderne Zielarchitekturen sind.

Was das Strangler-Fig-Pattern wirklich leistet

Martin Fowlers Strangler-Fig-Metapher beschreibt neue Software, die schrittweise um das bestehende System herum wächst. So werden Risiko, Investition und Nutzen in kleineren Einheiten steuerbar.

Technisch besteht das Pattern aus drei wiederkehrenden Schritten. Zuerst wird ein Zugriffspunkt geschaffen, über den sich Anfragen abfangen lassen. Danach übernimmt eine neue Anwendung oder ein neuer Service eine klar definierte Fachfunktion. Schließlich wird der bisherige Pfad entfernt, sobald Nutzung, Daten und Abhängigkeiten vollständig umgestellt sind. Dieser Zyklus wird nicht einmalig für das gesamte System durchgeführt, sondern für jeden fachlichen Ausschnitt erneut.

Der Parallelbetrieb ist dabei nicht als unerwünschter Nebeneffekt, sondern als Teil der Risikokontrolle zu betrachten. Das Unternehmen kann weiterhin neue Funktionen ausliefern, während die Modernisierung läuft. Jede migrierte Fachfunktion erzeugt einen überprüfbaren Zwischenstand und kann bereits Nutzen stiften. Allerdings entsteht vorübergehend zusätzliche Architektur: Routing, Adapter, Datensynchronisation und parallele Betriebsstrukturen müssen entwickelt, überwacht und später wieder entfernt werden.

Damit unterscheidet sich der Beitrag bewusst von einer allgemeinen Begründung für Modernisierung. Welche wirtschaftlichen Warnzeichen überhaupt für ein Legacy-Problem sprechen, behandelt bereits der Artikel Die wichtigsten Anzeichen, dass Ihr Legacy-System Ihrem Unternehmen zu viel Geld kostet. Hier geht es um die Architektur der tatsächlichen Ablösung.

Wo die neue Systemgrenze entstehen sollte

Die erste Grenze sollte nicht entlang technischer Schichten wie Oberfläche, Geschäftslogik und Datenbank gezogen werden. Solche Schnitte erzeugen neue Services, die für fast jede Änderung gemeinsam angepasst werden müssen. Besser ist eine Fachfunktion mit eigenem Zweck, etwa Preisberechnung, Dokumentenerzeugung, Betrugsprüfung oder Bestandsreservierung. Der neue Service kann dann eine vollständige Fachfunktion übernehmen, statt nur eine technische Teilaufgabe des Monolithen auszulagern.

Nach außen übernimmt meist eine Fassade oder ein Proxy das Routing. Kunden und aufrufende Systeme verwenden weiterhin denselben Einstiegspunkt, während die Fassade einzelne Pfade an das Legacy-System oder an neue Services weiterleitet. Nach innen kann zusätzlich ein Anti-Corruption Layer nötig sein. Er übersetzt alte Datenstrukturen und Begriffe in das neue Domänenmodell, damit historische Konventionen nicht die Architektur des neuen Services bestimmen.

Die Microsoft-Beschreibung des Strangler-Fig-Patterns warnt ausdrücklich davor, die Fassade zum Engpass oder Single Point of Failure werden zu lassen. Die Routing-Schicht benötigt daher dieselben Standards wie ein produktiver Service: redundante Instanzen, Lasttests, Timeouts, Monitoring und ein sauberes Konfigurationsmanagement.

Ein geeigneter erster Ausschnitt erfüllt möglichst viele der folgenden Bedingungen:

Fachliche Geschlossenheit: Die Fachfunktion hat eine klar abgegrenzte Verantwortung und einen erkennbaren Verantwortlichen.
Umleitbarer Zugriffspunkt: Anfragen lassen sich über URL, Nachrichtentyp, Mandant, Funktion oder einen bestehenden Integrationspunkt umleiten.
Begrenzte Abhängigkeiten: Der Ausschnitt benötigt nicht bei jedem Aufruf interne Zustände aus mehreren Bereichen des Monolithen.
Eigenständige Datenhoheit: Es lässt sich bestimmen, welche Daten der neue Service langfristig besitzt.
Messbarer Nutzen: Fehlerrate, Änderungszeit, Durchsatz, Ressourcenbedarf oder Sicherheitsrisiko können vor und nach der Migration verglichen werden.

Eine Übergangsarchitektur mit Ablaufdatum

Die Architektur während der Migration ist absichtlich komplexer als der gewünschte Endzustand. Zwei Implementierungen laufen parallel, Daten werden zeitweise kopiert und Adapter verbinden Modelle, die langfristig getrennt sein sollen. Diese Bausteine sind sinnvoll, weil sie kleine Umschaltungen und einen kontrollierten Rollback ermöglichen. Problematisch werden sie erst, wenn aus einer geplanten Übergangsarchitektur ein unbefristeter Dauerzustand wird.

Deshalb erhält jedes temporäre Element bereits bei seiner Einführung ein Exit-Kriterium. Für eine Routing-Regel kann das bedeuten, dass 100 Prozent der produktiven Aufrufe seit sechs Wochen stabil über den neuen Service laufen. Eine Datensynchronisation endet, wenn alle nachgelagerten Systeme auf die neue Quelle umgestellt und die Abgleichberichte fehlerfrei sind. Ein Anti-Corruption Layer wird entfernt, sobald kein Legacy-Aufrufer mehr das alte Modell benötigt. Diese Kriterien gehören allesamt in die Roadmap und in das technische Backlog.

Auch die Zuständigkeit muss eindeutig geregelt sein. Während der Umstellung müssen sich das neue und das alte Team die Verantwortung für den gesamten Geschäftsprozess teilen. Ohne diese geteilte Verantwortung entstehen Lücken an den Systemgrenzen: Der neue Service wird als “fertig” gefeiert, während im Hintergrund vergessene Batch-Jobs, Admin-Werkzeuge oder Datenströme weiterhin heimlich am alten System hängen.

Ein nützliches Arbeitsmittel ist ein Migrationsregister (oft als Live-Dashboard umgesetzt) pro Fachfunktion. Es hält aktuellen Anteil des auf den neuen Service gerouteten Traffics, führende Datenquelle, bekannte Aufrufer, Rollback-Pfad, offene Abhängigkeiten und Stilllegungstermin fest. Damit wird Fortschritt nicht nur über abgeschlossene Tickets, sondern über tatsächlich entfernte Verantwortung im Legacy-System sichtbar.

Praktische Tipps für Ihr Migrationsregister & Dashboard:
- Zentral & zugänglich halten: Hosten Sie das Register oder das Dashboard an einem gut sichtbaren Ort (wie einem gemeinsamen Wiki, Confluence oder einem Live-BI-Dashboard), damit Entwickler und Stakeholder dieselbe Informationsquelle nutzen.
- Status-Updates automatisieren: Nutzen Sie nach Möglichkeit einfache Skripte in der CI/CD-Pipeline, um aktuelle Routing-Prozentsätze oder aktive Feature-Flags direkt in den Tracker einzuspeisen. Das spart manuelle Pflege.
- Abschaltung an Bedingungen knüpfen: Verbinden Sie Stilllegungstermine mit konkreten, messbaren Kriterien (z. B. “100 % des Traffics laufen seit 4 Wochen stabil”). Das verhindert, dass alte Pfade ewig weiterlaufen.
- Aufrufer systematisch erfassen: Erfassen Sie nicht nur die Haupt-APIs, sondern auch alle im Hintergrund laufenden CRON-Jobs, Backup-Szenarien und Datenexporte, die an der Domäne hängen, damit vor dem Abschalten nichts vergessen wird.

Legacy-System-Migration in fünf Phasen

1. Geschäftsziel und reale Nutzungspfade erfassen

Am Anfang steht meistens ein geschäftliches Ziel. Soll eine besonders fehleranfällige Funktion stabilisiert werden? Blockiert ein Teil des Systems häufige Releases? Steigen die Betriebskosten eines stark ausgelasteten Pfads? Diese Priorisierung verhindert, dass die Migration an einer technisch einfachen, aber wirtschaftlich unwichtigen Stelle beginnt.

Danach werden reale Aufrufe, Abhängigkeiten und Datenflüsse erfasst. Architekturdiagramme allein reichen dafür selten aus. Access-Logs, verteilte Traces, Query-Logs, Batch-Jobs und gespreäche mit dem Betriebsteam zeigen, welche Aufrufer tatsächlich existieren. Gleichzeitig entsteht eine Baseline aus Latenz, Fehlerrate, Lastprofil, Supportfällen und Änderungsaufwand.

Zur Bestandsaufnahme gehören auch nichtfunktionale Anforderungen, die im Code kaum sichtbar sind: Wartungsfenster, Aufbewahrungsfristen, externe Verträge, Zertifizierungen und saisonale Lastspitzen. Sie bestimmen, wann ein Pfad umgeschaltet werden darf und wie lange ein Rollback möglich bleiben muss. Eine technisch saubere Grenze ist wertlos, wenn sie einen Monatsabschluss, eine Audit-Anforderung oder die zugesicherte Verfügbarkeit eines Kundenprozesses verletzt.

2. Einen kontrollierten Routing-Einstiegspunkt einführen

Die Fassade wird zunächst vor das bestehende System gesetzt, ohne Verhalten zu verändern. Sämtlicher Traffic geht weiterhin an das Legacy-System. Dieser scheinbar kleine Schritt prüft, ob Routing, Authentifizierung, Header, Sessions, Timeouts und Fehlerverhalten unverändert bleiben. Erst wenn die Fassade selbst stabil und beobachtbar ist, sollte sie produktive Anfragen an einen neuen Service senden.

Nicht jede Migration benötigt dafür ein neues API-Gateway. Ein bestehender Reverse Proxy, eine Messaging-Infrastruktur oder ein Adapter in der Anwendung kann dieselbe Aufgabe übernehmen. Entscheidend ist, dass die Zuordnung eindeutig konfiguriert, getestet und schnell rückgängig gemacht werden kann.

3. Eine vollständige Fachfunktion als eigenständigen Service bauen

Der neue Service sollte eine fachliche Operation End-to-End verantworten. Seine öffentliche Schnittstelle folgt dem benötigten fachlichen Vertrag und kopiert nicht automatisch interne Klassen oder Datenbanktabellen des Legacy-Systems. Wo Begriffe oder Formate abweichen, übersetzt ein Anti-Corruption Layer zwischen Legacy- und Domänenmodell. AWS beschreibt diese Schicht als Adapter, der das neue Domänenmodell von der Legacy-Semantik abschirmt und bestehende Aufrufer während des Übergangs unverändert lässt.

Zur Abnahme gehören Schnittstellentests gegen dokumentierte Beispiele und gegen beobachtetes Verhalten des Legacy-Systems. Bei deterministischen Funktionen kann eine Anfrage gespiegelt werden: Der neue Service berechnet das Ergebnis parallel, während zunächst nur die alte Antwort produktiv verwendet wird. Abweichungen werden protokolliert, klassifiziert und erst nach fachlicher Prüfung akzeptiert oder korrigiert.

4. Dateneigentum bewusst verschieben

Eine Service-Extraktion ist erst vollständig, wenn klar ist, welches System für die zugehörigen Daten verantwortlich ist. Ein neuer Service, der dauerhaft direkt in die Datenbank des Monolithen schreibt, besitzt zwar einen eigenen Prozess, aber keine echte Unabhängigkeit. Gleichzeitig ist eine sofortige Datenbanktrennung oft zu riskant, weil Berichte, Batch-Prozesse oder andere Legacy-Funktionen noch auf dieselben Tabellen zugreifen.

Deshalb braucht man für jede Migrationsschritt einen Übergangsplan: initialer Datenimport, zeitlich begrenzte Synchronisation, Konsistenzprüfungen, Umschaltung des führenden Systems (System of Record) und ein späterer Rückbau der alten Tabellen oder Schreibpfade. Der Übergangsplan muss feststehen, bevor produktive Schreibzugriffe aufgeteilt werden, um sich nicht im Chaos zu verlieren.

5. Traffic verlagern und den alten Pfad entfernen

Der Rollout beginnt mit internen oder risikoarmen Aufrufen und wird über definierte Stufen schrittweise ausgeweitet. Routing nach Mandant, Region, Nutzergruppe oder Prozentanteil begrenzt die Auswirkungen eines Fehlers. Für jede Stufe existieren Abbruchkriterien, etwa erhöhte Fehlerraten, fachliche Abweichungen oder ein überschrittenes Latenzbudget. Ebenso wichtig ist ein getesteter Rollback-Pfad, solange die alte Implementierung noch verfügbar ist.

Nach einer stabilen Beobachtungsphase wird nicht nur das Routing geändert. Alte Endpunkte, Jobs, Tabellenzugriffe, Konfigurationen und Monitoring-Regeln müssen nachweislich entfernt werden. Sonst schrumpft das Legacy-System im Architekturdiagramm, bleibt aber im Betrieb bestehen. Erst der Rückbau beendet einen Migrationsschritt und reduziert die tatsächliche Komplexität.

Warum die Datenmigration den Takt vorgibt

Code lässt sich vergleichsweise leicht parallel betreiben. Bei Daten ist das schwieriger, weil inkonsistente Datenstände sofort fachliche Folgen haben. Vor jeder Umstellung muss daher ein System of Record feststehen. Während der Übergangsphase darf es Kopien geben, aber nicht zwei gleichberechtigte Eigentümer derselben Information.

Ein häufiges Vorgehen kombiniert einen initialen Import mit Change Data Capture (CDC). Änderungen aus dem bisherigen Datenbestand werden anschließend als Ereignisse an den neuen Speicher übertragen. Werkzeuge wie Debezium lesen dazu beispielsweise Transaktionslogs oder Replikationsströme. Das reduziert Eingriffe in den Legacy-Code, beseitigt aber nicht die Notwendigkeit von Reihenfolge, Wiederholbarkeit und Konsistenzkontrollen.

Dual Writes, bei denen eine Geschäftsfunktion in zwei Datenbanken schreibt, wirken einfacher, erzeugen aber einen kritischen Fehlerfall: Ein Schreibvorgang kann erfolgreich sein, während der zweite scheitert. Robuster sind häufig ein führender Schreibpfad, eine transaktionale Outbox oder eine nachvollziehbare Synchronisationspipeline. Unabhängig vom Mechanismus braucht die Migration Abgleichberichte, idempotente Verarbeitung und einen definierten Punkt, ab dem ein Rollback eine Rückmigration der Daten erfordert.

Die strategische Rolle von Rust-Microservices

Das Strangler-Fig-Pattern schreibt keine Programmiersprache vor. Diese technologische Unabhängigkeit ist ein erhebelicher betrieblicher Vorteil: Indem Systemgrenzen hinter Netzwerkprotokollen (wie HTTP, gRPC oder Message-Queues) isoliert werden, ermöglicht das Pattern von Natur aus eine polyglotte Architektur. Es bietet einen risikoarmen, schrittweisen Weg, um moderne, hochperformante Programmiersprachen wie Rust in ein Legacy-System einzuführen, ohne das gesamte Entwicklerteam sofort umschulen oder einen riskanten Big-Bang-Rewrite wagen zu müssen.

Rust is besonders interessant, wenn ein extrahierter Service hohe Last verarbeitet, vorhersehbare Ressourcennutzung benötigt oder nicht vertrauenswürdige Daten verarbeitet. Ein Service sollte jedoch nicht allein deshalb in Rust entstehen, weil die Sprache modern ist. Die technische Wahl muss zum Engpass und zum langfristig verfügbaren Know-how für Betrieb und Wartung im Team passen.

Die allgemeinen Stärken, Grenzen und Frameworks von Rust im Backend behandelt bereits der Beitrag Rust für die Backend-Entwicklung. Für die Legacy-Migration ist stattdessen entscheidend, dass der neue Service als eigenständiges Artefakt mit einem klar versionierten Schnittstellenvertrag entwickelt und ausgerollt werden kann. Die Grenze verläuft damit zwischen Systemen und nicht zwischen Programmiersprachen innerhalb eines Prozesses.

Diese Grenze braucht explizite Regeln für Timeouts, Retries, Idempotenz und Fehlerantworten. Synchrone Aufrufe eignen sich für unmittelbare Ergebnisse, erhöhen aber die Kopplung zur Laufzeit. Asynchrone Ereignisse entkoppeln Sender und Empfänger zeitlich, verlangen dafür aber klare Zuständigkeiten und den Umgang mit mehrfach zugestellten Nachrichten. Wer lediglich viele kleine Services um dieselbe Datenbank herum baut, erhält keine moderne Architektur, sondern einen verteilten Monolithen.

Typische Risiken und passende Gegenmaßnahmen

Die Fassade wird zur Dauerlösung: Für jeden Routing-Eintrag werden Verantwortliche, Ablaufkriterium und geplanter Rückbau dokumentiert.
Das neue Modell übernimmt alte Begriffe und Sonderfälle: Ein Anti-Corruption Layer übersetzt bewusst zwischen beiden Modellen und bleibt möglichst servicebezogen.
Daten gehören gleichzeitig zwei Systemen: Pro Domäne wird zu jeder Phase ein führender Schreibpfad festgelegt; Kopien werden abgeglichen und nur vorübergehend betrieben.
Zu viele Services entstehen zu früh: Konzentrieren Sie sich darauf, grobgranulare Fachfunktionen mit klarem, eigenständigem Geschäftsnutzen zu extrahieren, anstatt das System anhand einzelner technischer Klassen oder Datenbanktabellen zu kleinteilig zu schneiden.
Fehler verschwinden zwischen den Systemen: Gemeinsame Correlation IDs verbinden Logs, Metriken und Traces über Fassade, Legacy-System und den neuen Service.
Der Parallelbetrieb endet nie: Jeder Migrationsschritt enthält ein Budget für Stilllegung, Datenbereinigung und Entfernung alter Betriebswege.

Gerade während der Koexistenz ist verteiltes Tracing wichtig. OpenTelemetry beschreibt Traces als durchgängigen Pfad einer Anfrage über mehrere Services. Im Rust-Ökosystem kann das tracing-Crate von Tokio strukturierte Ereignisse und Spans erzeugen und an eine OpenTelemetry-Infrastruktur weitergeben. So bleibt erkennbar, welcher Pfad eine Anfrage verarbeitet hat und wo Latenz entsteht oder Fehler auftreten.

Woran lässt sich der Fortschritt messen?

Der Anteil neuer Codezeilen ist keine brauchbare Erfolgskennzahl. Eine Strangler-Migration ist erfolgreich, wenn Verantwortung messbar vom Legacy-System verschwindet und der Betrieb gleichzeitig stabil bleibt. Sinnvolle Kennzahlen sind:

Anteil der produktiven Aufrufe, die über neue Services laufen
Zahl verbleibender Aufrufer, Jobs und Datenbankzugriffe auf die abzulösende Legacy-Funktion
Fachliche Abweichungen zwischen alter und neuer Verarbeitung
Fehlerrate, P95- und P99-Latenz sowie Verfügbarkeit je Routing-Pfad
Dauer von Änderung, Test und Deployment der modernisierten Fachfunktion
Zusätzliche Kosten des Parallelbetriebs und bereits stillgelegte Legacy-Ressourcen

Diese Werte werden vor Beginn erfasst und an jedem Umschaltpunkt erneut geprüft. Die Migrations-Roadmap bleibt dadurch an messbare Ergebnisse gekoppelt. Ein Service wird nicht deshalb ausgerollt, weil der Zeitplan es verlangt, sondern weil Schnittstellenvertrag, Datenmigration, Betriebsreife und Rollback ausreichend validiert sind.

Wann ist das Pattern nicht die richtige Wahl?

Für ein kleines, vollständig dokumentiertes System kann ein direkter Ersatz günstiger sein als jahrelanger Parallelbetrieb. Ungeeignet ist das Pattern auch, wenn sich Zugriffe nicht abfangen lassen, interne Aufrufe nicht angepasst werden können oder das Legacy-System sehr kurzfristig abgeschaltet werden muss. Harte regulatorische Vorgaben können doppelte Datenhaltung zusätzlich begrenzen.

Außerdem muss die Zielarchitektur nicht automatisch aus zahlreichen Microservices bestehen. Entscheidend sind unabhängige fachliche Grenzen und ein kontrollierbarer Betrieb. Der Beitrag Software skalierbar gestalten ordnet Monolithen, modulare Monolithen und Microservices nach Wachstumsphase und tatsächlichem Bedarf ein.

Fazit: Das Legacy-System verliert Verantwortung, nicht nur Code

Das Strangler-Fig-Pattern macht aus einer riskanten Gesamtablösung eine Folge überprüfbarer Architekturentscheidungen. Eine stabile Fassade lenkt Zugriffe, fachlich geschnittene eigenständige Services übernehmen Verantwortung und ein kontrollierter Datenübergang schafft eindeutige Zuständigkeiten. Der entscheidende Abschluss jedes Schritts ist die Entfernung des alten Pfads.

trust!NICKOL unterstützt Unternehmen dabei, geeignete Systemgrenzen zu identifizieren, Übergangsarchitekturen zu entwerfen und eine priorisierte Migrations-Roadmap aufzubauen. So wird aus einer abstrakten Modernisierungsabsicht ein Programm mit messbaren Ergebnissen und beherrschbarem Risiko.

FAQ zum Strangler-Fig-Pattern

Ist das Strangler-Fig-Pattern dasselbe wie eine Microservice-Migration?

Nein. Das Pattern beschreibt die schrittweise Ablösung eines bestehenden Systems. Neue Teile können Microservices, Module oder eigenständige Anwendungen sein. Microservices sind nur dann sinnvoll, wenn fachliche Grenzen, Skalierung oder unabhängige Deployments den zusätzlichen Betriebsaufwand rechtfertigen.

Muss der Quellcode des Legacy-Systems verfügbar sein?

Nicht zwingend. Für rein externes Routing kann ein Proxy bestimmte Anfragen oft ohne tiefgreifende Eingriffe umleiten. Sobald interne Aufrufe deaktiviert, Datenzugriffe geändert oder alte Funktionen sauber entfernt werden müssen, ist Zugriff auf den Quellcode sowie Kontrolle über Deployment und Betrieb meist notwendig.

Wie verhindert man inkonsistente Daten während der Migration?

Für jede Domäne wird ein führendes System festgelegt. Datenkopien werden über einen definierten Mechanismus synchronisiert und automatisch abgeglichen. Idempotente Verarbeitung, nachvollziehbare Ereignisse und klare Umschaltkriterien verhindern, dass zwei unabhängige Wahrheiten entstehen.

Warum eignen sich Rust-Microservices für die Modernisierung?

Rust kombiniert native Performance mit Speichersicherheit und vorhersehbarer Ressourcennutzung. Das ist besonders wertvoll für hoch ausgelastete, sicherheitskritische oder ressourcenintensive Services. Die Sprache ersetzt jedoch keine saubere Servicegrenze, Datenstrategie oder Betriebsorganisation.

Wann kann das Legacy-System endgültig abgeschaltet werden?

Erst wenn kein produktiver Traffic, kein interner Aufrufer, kein Batch-Job und kein Reporting-Prozess mehr von der alten Funktion abhängt. Zusätzlich müssen die neuen Datenbestände validiert, Betriebskennzahlen stabil und die vereinbarte Rollback-Frist abgelaufen sein.