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. Viele dieser Projekte verlaufen anders als geplant: Sie dauern deutlich länger, kosten mehr, oder sie werden nie fertig. Und sie sterben oft einen leisen, 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 dein 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: Dein 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 du das System neu baust, baust du unweigerlich alte, längst gelöste Bugs wieder ein. Du musst 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, lässt du 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 du eine einzige Zeile neuen Code schreibst, schaltest du einen Routing-Layer vor deine 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
Such dir eine klar abgegrenzte Domäne (z. B. das „Rechnungswesen“ oder die „Benutzerregistrierung“). Bau diese Funktionalität als eigenständigen, modernen Service neu auf. Wichtig: Schneide das System vertikal (vom UI/API bis zur Datenbank) und nicht horizontal.
Schritt 3: Das Routing umschalten
Sobald der neue Service bereit ist, konfigurierst du 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). Etabliere eine asynchrone Datensynchronisation mittels Change Data Capture (CDC) oder Messaging-Queues.
Sobald der neue Service stabil läuft und alle Daten migriert sind, löschst du den alten Code im Monolithen. Wiederhole diesen Prozess mit der nächsten Domäne.
Die Vorteile dieser Strategie in der Praxis
- Kontinuierlicher Business-Value: Du lieferst früh echten Mehrwert in Produktion, nicht erst nach Jahren.
- Minimales Release-Risiko: Wenn beim Umschalten einer einzelnen Route etwas schiefgeht, rollst du im Routing-Layer zurück. Das System bleibt lauffähig.
- Echte Feature-Velocity: Dein 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 dir, den Monolithen kontrolliert und neben dem laufenden Betrieb abzulösen.
Steht euer Unternehmen vor einer System-Modernisierung, oder droht euer aktuelles Rewrite-Projekt im Sande zu verlaufen?
Lass uns das Risiko klein halten. Im Architecture & Code Health Audit analysiere ich eure bestehende Codebase, identifiziere die am besten geeigneten Schnittstellen für das Strangler-Muster und erarbeite mit deinem Team einen pragmatischen, risikoarmen Migrations-Fahrplan.