Der „Big Bang“-Mythos: Warum das komplette Rewrite eures Legacy-Systems scheitern wird (und wie das Strangler Fig Pattern es rettet)
Es ist der feuchte Traum jedes frustrierten Entwicklerteams und oft die teuerste Fehlentscheidung, die ein CTO treffen kann: „Lass uns den alten Monolithen einfach wegschmeißen und auf der grünen Wiese komplett neu bauen.“
Die Argumente klingen verlockend: Die alte Codebase ist ein Spaghettihaufen, das Framework ist veraltet, die Feature-Velocity tendiert gegen Null und keiner versteht mehr, wie die Kernfunktionen im Detail funktionieren. Ein kompletter Neuanfang („Big Bang Rewrite“) verspricht Erlösung. Alles soll sauberer, modularer und moderner werden.
Doch die Realität schlägt hart zu. In über zehn Jahren Beratung im Bereich Legacy-Modernisierung habe ich fast kein „Big Bang“-Rewrite-Projekt gesehen, das pünktlich, im Budget oder überhaupt erfolgreich abgeschlossen wurde. Die meisten dieser Projekte sterben einen leisen, extrem teuren Tod.
Warum das komplette Rewrite in der Praxis fast immer scheitert
Es gibt drei fundamentale Gründe, warum der „Big Bang“-Ansatz ein mathematisches Himmelfahrtskommando ist:
1. Das „Moving Target“-Problem
Während Ihr Team an der neuen Software arbeitet, steht das Business nicht still. Der Markt verlangt neue Features, Kunden finden kritische Bugs und die Konkurrenz schläft nicht. Das bedeutet: Ihr altes System muss im Live-Betrieb weiterentwickelt werden.
Das neue System jagt einem beweglichen Ziel hinterher. Jedes Feature, das im Legacy-System hinzukommt, muss im neuen System nachgebaut werden. Die Folge? Das Release-Datum verschiebt sich immer weiter nach hinten, während der Druck vom Management ins Unermessliche steigt.
2. Der „Second-System Effect“ (nach Fred Brooks)
Wenn Entwickler endlich die Chance bekommen, alles „richtig“ zu machen, neigen sie zu massiver Überkonstruktion. Jedes coole Pattern, das im alten System keinen Platz hatte, soll nun implementiert werden. Plötzlich wird aus einem simplen CRUD-Dienst ein hochkomplexes, event-basiertes Microservice-Netzwerk mit Kubernetes, CQRS und Graph-Datenbanken. Die Komplexität explodiert, bevor überhaupt die erste Zeile produktive Business-Logik läuft.
3. Das Phantom des „impliziten Wissens“ (Bug-Parity)
Ein Legacy-System ist wie ein Sedimentgestein: Es enthält Schichten aus jahrelangen Bugfixes, Edge-Case-Behandlungen und regulatorischen Workarounds. Kein Entwickler und kein Product Owner erinnert sich an all diese Nuancen. Dokumentiert sind sie erst recht nicht.
Wenn Sie das System neu bauen, bauen Sie unweigerlich alte, längst gelöste Bugs wieder ein. Sie müssen nicht nur Feature-Parity erreichen, sondern auch Bug-Parity – und das ist ohne funktionierende Regressionstests der alten Codebase praktisch ummöglich.
Die architektonische Lösung: Das Strangler Fig Pattern
Professionelle Software-Architektur sucht nicht das größte Risiko, sondern minimiert es. Die sicherste Methode, einen Monolithen abzulösen, ist das Strangler Fig Pattern (benannt nach der Würgefeige, die einen Wirtsbaum umschlingt, bis dieser abstirbt).
Anstatt das alte System abzuschalten und das neue einzuschalten, lassen Sie das neue System schrittweise wachsen, während es dem Monolithen Stück für Stück die Funktionalität entzieht.
Der methodische Ablauf in 4 Schritten
Schritt 1: Den Interceptor (Routing-Layer) etablieren
Bevor Sie eine einzige Zeile neuen Code schreiben, schalten Sie einen Routing-Layer vor Ihre Anwendung. Das kann ein API-Gateway (wie Envoy oder Kong), ein klassischer Nginx-Reverse-Proxy oder ein Cloudflare Worker sein. Sämtlicher Traffic fließt ab jetzt durch diesen Interceptor, der anfangs 100 % der Anfragen an den alten Monolithen weiterleitet.
Schritt 2: Eine vertikale Scheibe herausschneiden
Suchen Sie sich eine klar abgegrenzte Domäne (z. B. das „Rechnungswesen“ oder die „Benutzerregistrierung“). Bauen Sie diese Funktionalität als eigenständigen, modernen Service neu auf. Wichtig: Schneiden Sie das System vertikal (vom UI/API bis zur Datenbank) und nicht horizontal.
Schritt 3: Das Routing umschalten
Sobald der neue Service bereit ist, konfigurieren Sie das API-Gateway um. Anfragen, die die migrierte Domäne betreffen (z. B. /api/v1/invoices), werden nun an den neuen Service geroutet. Alle anderen Anfragen gehen weiterhin an den Monolithen.
Schritt 4: Die Brücke schlagen und aufräumen
Oft benötigt der neue Service Daten aus dem alten System (oder umgekehrt). Etablieren Sie eine asynchrone Datensynchronisation mittels Change Data Capture (CDC) oder Messaging-Queues.
Sobald der neue Service stabil läuft und alle Daten migriert sind, löschen Sie den alten Code im Monolithen. Wiederholen Sie diesen Prozess mit der nächsten Domäne.
Die Vorteile dieser Strategie in der Praxis
- Kontinuierlicher Business-Value: Sie liefern bereits nach wenigen Wochen statt erst nach Jahren echten Mehrwert in Produktion.
- Minimales Release-Risiko: Wenn beim Umschalten einer einzelnen Route etwas schiefgeht, rollen Sie innerhalb von Sekunden im Routing-Layer zurück. Das System bleibt lauffähig.
- Echte Feature-Velocity: Ihr Team lernt das neue System im echten Betrieb kennen und kann kontinuierlich Feedback einbauen, statt jahrelang im luftleeren Raum zu entwickeln.
Fazit: Evolution statt Revolution
Der „Big Bang“-Ansatz fühlt sich heroisch an, ist aber meistens ein Akt der architektonischen Kapitulation. Professionelle Modernisierung ist kein Event, sondern ein kontinuierlicher evolutionärer Prozess. Das Strangler Fig Pattern ermöglicht es Ihnen, den Monolithen kontrolliert und ohne Betriebsunterbrechung abzulösen.
Steht Ihr Unternehmen vor einer anstehenden System-Modernisierung oder droht Ihr aktuelles Rewrite-Projekt im Sande zu verlaufen?
Lassen Sie uns das Risiko minimieren. In meinem Legacy-Architecture-Audit analysiere ich Ihre bestehende Codebase, identifiziere die am besten geeigneten Schnittstellen für das Strangler-Muster und erarbeite mit Ihrem Team einen pragmatischen, risikofreien Migrations-Fahrplan.