Ein Versicherungsunternehmen startete ein Projekt, das intern nur “die Ablösung” hieß: Das zwanzig Jahre alte Kernsystem sollte innerhalb von 18 Monaten komplett neu gebaut werden. Nach 20 Monaten war das neue System noch nicht produktiv. Nach 26 Monaten wurde das Projekt beendet – mit einem zweistelligen Millionenbetrag Investition und einem Altsystem, das weiterhin lief, weil es musste.
Die neue Anwendung hatte nie den vollen Funktionsumfang des alten Systems erreicht, weil während der Bauzeit ständig neue Anforderungen an das alte System gestellt wurden, die dann auch im neuen nachgezogen werden mussten. Ein bewegliches Ziel, das sich schneller bewegte als der Neubau.
Das ist kein Einzelfall, sondern ein wiederkehrendes Muster bei Legacy-Modernisierungsprojekten. Der vollständige Neustart – oft romantisierend “grüne Wiese” genannt – scheitert überdurchschnittlich häufig. Nicht weil die neue Technologie schlecht wäre, sondern weil das Grundproblem eines Big-Bang-Ansatzes strukturell ist.
Warum der Komplett-Neustart so oft scheitert
Ein Legacy-System, das seit Jahren produktiv läuft, enthält nicht nur Code. Es enthält akkumuliertes Geschäftswissen – Sonderfälle, historische Entscheidungen, Workarounds für Kunden, die vor Jahren einen Sonderwunsch hatten und deren Lösung nie wieder entfernt wurde. Ein Neubau, der “das System einfach neu und sauber” implementiert, unterschätzt fast immer, wie viel von diesem impliziten Wissen tatsächlich gebraucht wird.
Hinzu kommt das Moving-Target-Problem: Während das neue System gebaut wird, steht das Geschäft nicht still. Das alte System bekommt weiterhin neue Anforderungen, weil es das ist, was tatsächlich produktiv läuft und Umsatz generiert. Jede neue Anforderung im Altsystem vergrößert die Lücke, die der Neubau schließen muss – bevor er überhaupt live gegangen ist.
Was das Strangler-Fig-Pattern eigentlich ist
Der Name stammt von Martin Fowler, der ihn nach der Würgefeige benannt hat: eine Pflanze, die sich um einen Wirtsbaum herum entwickelt, ihn über Jahre langsam umschließt und irgendwann vollständig ersetzt, ohne dass je ein einzelner Moment existiert, in dem der alte Baum “abgeschaltet” wird. Übertragen auf Software bedeutet das: Statt das Altsystem komplett zu ersetzen, wird es Stück für Stück von einem neuen System umwachsen – Funktionsbereich für Funktionsbereich, bis irgendwann nichts vom Original übrig ist.
Technisch funktioniert das über eine Facade- oder Routing-Schicht – häufig ein API-Gateway oder Reverse Proxy –, die vor beiden Systemen liegt und pro Anfrage entscheidet: Wird das vom alten oder vom neuen System beantwortet? Zu Beginn beantwortet das Altsystem fast alles. Mit jedem migrierten Modul verschiebt sich der Anteil.
Die Rolle der Routing-Schicht
Diese Facade ist der eigentliche Kern der Strategie. Sie macht die Migration für Endnutzer und andere Systeme unsichtbar – niemand muss wissen, dass eine bestimmte Anfrage inzwischen von einem neuen Microservice statt vom alten Monolithen beantwortet wird. Das erlaubt inkrementelle Cutover: ein Modul, ein Team, ein überschaubares Risiko pro Schritt, statt eines einzigen Alles-oder-nichts-Release-Termins.
Genauso wichtig: Die Routing-Schicht macht Rollback trivial. Verhält sich das neue Modul in Produktion unerwartet, wird der Traffic für diesen Bereich einfach zurück auf das Altsystem geroutet – ohne Notfall-Deployment, ohne Downtime.
Was diese Strategie voraussetzt
Das Strangler-Fig-Pattern ist kein Selbstläufer. Es setzt voraus, dass sich das Altsystem überhaupt in sinnvolle Bounded Contexts – fachlich zusammenhängende, entkoppelbare Bereiche – zerlegen lässt. Bei einem stark verwobenen Monolithen mit gemeinsamer Datenbank und zirkulären Abhängigkeiten ist bereits diese Analyse ein erheblicher Teil der Arbeit – und sie muss vor der ersten Zeile neuen Codes stehen, nicht danach.
Es braucht außerdem Observability, um zu wissen, welcher Teil des alten Systems tatsächlich noch aktiv genutzt wird – und welcher seit Jahren toter Code ist, der gar nicht migriert werden muss. Und es braucht organisatorische Disziplin: Wenn während der Migration weiterhin ausschließlich das Altsystem neue Features bekommt, weil “die Migration ja sowieso läuft”, wächst das Zielsystem schneller, als das neue System hinterherkommt – dasselbe Moving-Target-Problem, nur in kleinerem Maßstab.
Wann Big Bang doch die bessere Wahl ist
Nicht jede Modernisierung braucht diesen Aufwand. Bei kleinen, klar abgegrenzten Systemen ohne komplexe Abhängigkeiten, oder bei Systemen, die ohnehin bald vollständig abgeschaltet werden, kann ein direkter Neubau schneller und günstiger sein als eine monatelange Facade-Konstruktion. Das Strangler-Fig-Pattern zahlt sich vor allem bei großen, geschäftskritischen Systemen aus, die während der gesamten Migration weiterlaufen müssen – also genau dort, wo ein Big Bang am meisten Risiko trägt.
Ein realistischer Fahrplan
Der Einstieg beginnt nicht mit Code, sondern mit einer Landkarte: Welche fachlichen Bereiche lassen sich isolieren? Welcher davon hat das beste Verhältnis aus Geschäftswert und technischem Risiko, um als erstes migriert zu werden? Der erste migrierte Bereich sollte bewusst klein und risikoarm gewählt werden – er dient dazu, das Muster, die Routing-Schicht und die Teamprozesse zu beweisen, bevor die geschäftskritischen Kernbereiche folgen.
Danach ist Priorisierung nach Geschäftswert und Risiko wichtiger als eine starre Reihenfolge. Das Ziel ist nicht, das Altsystem so schnell wie möglich loszuwerden – es ist, es so sicher wie möglich zu ersetzen, während das Geschäft ununterbrochen weiterläuft.