Was ist ein Strangler Fig Pattern? Legacy ablösen ohne alles neu zu bauen

Stellen Sie sich vor, Sie müssen eine Brücke erneuern, während der Verkehr weiterläuft. Kein Abriss, keine Vollsperrung, kein Chaos. Sie bauen daneben, leiten den Verkehr schrittweise um und reißen das Alte erst ab, wenn das Neue trägt.

Genau das beschreibt das Strangler Fig Pattern für Software.

Es ist eine der bewährtesten Strategien, um Legacy Software abzulösen, ohne alles auf einmal neu zu bauen. Dieser Artikel erklärt, wie das Muster funktioniert, wann es die richtige Wahl ist und wann nicht.

Was steckt hinter dem Namen?

Der Name klingt ungewöhnlich. Er kommt von einer Feigenart in tropischen Wäldern. Die Würgefeige wächst um einen bestehenden Baum herum. Sie umhüllt ihn langsam, übernimmt seine Funktionen und ersetzt ihn am Ende vollständig. Der alte Baum verschwindet, ohne dass das Ökosystem zusammenbricht.

Dieses Bild hat der Softwarearchitekt Martin Fowler 2004 auf Legacy-Migrationsprojekte übertragen. Der Kern seiner Beobachtung: Der sicherste Weg, ein altes System zu ersetzen, ist, daneben ein neues aufzubauen, Stück für Stück umzuleiten und das Alte erst dann abzuschalten, wenn es keine Aufgaben mehr hat.

Das Problem mit dem Komplett-Rewrite

Wer ein veraltetes System modernisieren will, kommt früher oder später auf die Idee: "Wir bauen das alles neu." Das klingt nach dem saubersten Weg. Tabula Rasa. Moderner Stack. Kein Legacy-Code mehr.

Die Realität sieht anders aus.

Ein vollständiger Rewrite ist eines der riskantesten Vorhaben in der Softwareentwicklung. Projekte dauern länger als geplant. Budgets werden überschritten. Funktionen, die im alten System selbstverständlich waren, fehlen im neuen. Und während das neue System entsteht, läuft das alte weiter, sammelt neue Anforderungen und vergrößert den Abstand zum Entwicklungsstand des neuen Systems.

Das nennt sich "Moving Target Problem". Bis das neue System fertig ist, hat sich das Ziel verschoben.

Das Strangler Fig Pattern löst dieses Problem, indem es den Rewrite überflüssig macht. Kein "alles auf einmal", sondern schrittweiser Übergang.

Wie das Muster in der Praxis funktioniert

Das Grundprinzip lässt sich in drei Phasen beschreiben.

Phase 1: Neues System parallel aufbauen

Neben dem bestehenden Legacy-System entsteht ein neues. Nicht als Ersatz für das gesamte System, sondern für einen definierten, abgrenzbaren Teil. Das kann ein einzelner Prozess sein, eine bestimmte Funktion oder ein Benutzerbereich.

Der wichtige Punkt: Das alte System läuft unverändert weiter. Kein Eingriff, kein Risiko.

Phase 2: Traffic umleiten

Sobald der neue Teilbereich stabil läuft, wird der Datenverkehr dorthin umgeleitet. Für Nutzer ändert sich nichts sichtbares. Sie erreichen die gleiche Adresse, landen aber im neuen System.

Technisch geschieht das oft über einen vorgeschalteten Proxy oder ein API-Gateway. Der Proxy entscheidet, welche Anfragen ans neue und welche ans alte System gehen.

Phase 3: Altes System Stück für Stück abschalten

Dieser Vorgang wird wiederholt: neuen Bereich bauen, Verkehr umleiten, alten Bereich abschalten. Funktion für Funktion, Bereich für Bereich.

Am Ende läuft nur noch das neue System. Das alte wurde nicht in einem Akt gesprengt, sondern schrittweise ersetzt. Ohne großen Knall, ohne Ausfallzeiten, ohne den gefürchteten Big Bang.

Wann das Muster gut funktioniert

Das Strangler Fig Pattern ist keine Universallösung. Es funktioniert besonders gut unter bestimmten Voraussetzungen.

Modulares oder teilweise abgrenzbares Altsystem: Je klarer die Grenzen zwischen Funktionsbereichen im alten System sind, desto einfacher ist die schrittweise Ablösung. Monolithische Systeme, bei denen alles mit allem verwoben ist, machen das Muster schwieriger, aber nicht unmöglich.

Laufender Betrieb darf nicht unterbrochen werden: Wer eine geschäftskritische Anwendung betreibt, kann sich keinen Ausfall leisten. Das Strangler Fig Pattern ist eine der wenigen Strategien, die eine Migration ohne Betriebsunterbrechung ermöglichen.

Schrittweise finanzierbar: Kein großes Investitionsbudget für einen Einmal-Rewrite. Stattdessen kontrollierte, planbare Ausgaben, die sich über den Migrationszeitraum verteilen.

Technische Schulden sind erheblich, aber das System trägt noch: Das System ist angesammelt und überfällig für eine Erneuerung, aber nicht am Zusammenbrechen. Es gibt noch genug Zeit für einen geordneten Übergang.

Wann das Muster nicht funktioniert

Es gibt Situationen, in denen das Strangler Fig Pattern an Grenzen stößt.

Ein hochgradig verflochtenes System ohne klare Schnittstellen macht die schrittweise Ablösung sehr schwierig. Wenn jeder Teil des Systems von jedem anderen abhängt, lässt sich kein sinnvoller Startpunkt finden.

Auch wenn das alte System sehr schlecht dokumentiert ist und niemand mehr genau weiß, was es eigentlich tut, wird die Migration riskanter. Man kann kein neues System bauen, das ein altes ersetzt, wenn man das alte nicht versteht.

Und wenn das System schlicht am Ende ist, wirklich nicht mehr gewartet werden kann und unmittelbar zusammenbricht: Dann bleibt manchmal nur der vollständige Neustart. Auch das ist eine legitime Entscheidung. Aber sie ist selten.

Ein konkretes Beispiel aus dem Mittelstand

Eine Handelsgesellschaft betreibt eine intern entwickelte Bestellplattform auf PHP 5.6. Das System läuft seit 2009. Es hat keine Dokumentation, keine automatisierten Tests und drei Entwickler haben es seither verlassen.

Ein Komplett-Rewrite würde ein Jahr dauern und einen sechsstelligen Betrag kosten. Und während das neue System entsteht, baut das alte weiter an, was nicht im neuen ankommt.

Stattdessen: Das Reporting-Modul wird zuerst ausgelagert. Es hat eine klare Abgrenzung und wird von weniger kritischen Prozessen genutzt. Ein neues Reporting läuft auf moderner Technologie, der alte Teil bleibt unberührt.

Im nächsten Schritt folgt das Kundenverwaltungsmodul. Dann die Bestellverarbeitung.

Nach 18 Monaten läuft das neue System vollständig. Das alte wurde nie "abgelöst", es wurde ausgehöhlt, bis nichts mehr übrig blieb.

Was das für Ihre Situation bedeutet

Sie müssen kein Entwickler sein, um zu verstehen, ob das Strangler Fig Pattern für Ihr System infrage kommt.

Die entscheidende Frage lautet: Gibt es in Ihrer Anwendung Bereiche, die klar abgegrenzt sind und eigenständig funktionieren? Gibt es Funktionen, die seltener genutzt werden und deshalb ein guter Startpunkt für eine Migration wären?

Wenn die Antwort ja lautet, ist das ein gutes Zeichen.

Wenn die Antwort "ich weiß nicht" lautet, ist das ebenfalls ein Ausgangspunkt. Ein Software-Audit kann Klarheit schaffen, bevor irgendwelche Entscheidungen getroffen werden.

Fazit: Schritt für Schritt ist besser als alles auf einmal

Das Strangler Fig Pattern ist keine Wunderwaffe. Aber es ist eine ehrliche Strategie für eine echte Herausforderung. Legacy-Software ablösen, ohne den Betrieb zu riskieren, ohne ein Riesenprojekt zu starten und ohne zu hoffen, dass ein Komplett-Rewrite irgendwann fertig wird.

Sanieren statt abreißen. Das ist auch bei Software oft der klügere Weg.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihr System an und sagen Ihnen, welche Migration-Strategie zu Ihrer Situation passt.