Big-Bang-Rewrite vermeiden: Warum komplette Neuentwicklungen scheitern
"Das System ist so verkrustet, wir bauen einfach alles neu." Dieser Satz ist verständlich – und statistisch einer der teuersten Fehler in der Software-Modernisierung. Joel Spolsky nannte den kompletten Neubau bereits vor über 20 Jahren "den einen kardinalen Fehler, den erfolgreiche Softwarefirmen nie machen sollten". Die Gründe dafür haben sich seitdem nicht geändert.
Warum der Big Bang so verführerisch ist
Bestehender Code fühlt sich für Entwickler:innen, die ihn nicht geschrieben haben, fast immer schlechter an, als er ist. Historisch gewachsene Workarounds wirken wie schlechtes Design – dabei stecken darin oft jahrelang gesammelte Antworten auf reale Edge-Cases, an die heute niemand mehr denkt. "Wir bauen es einfach neu und sauber" klingt nach dem schnelleren Weg. In der Praxis ist es fast immer der langsamere.
Die drei Fallen des kompletten Neubaus
- Das unsichtbare Wissen im Altsystem. Jede Sonderregel, jeder Workaround im alten Code ist die Antwort auf ein reales Problem – einen Kunden, einen Rechtsfall, eine Grenzbedingung. Beim Neuschreiben werden diese Antworten unbewusst vergessen, bis sie in Produktion erneut auftauchen.
- Zwei Systeme parallel pflegen. Solange das neue System nicht fertig ist, muss das alte weiterlaufen – inklusive neuer Features und Bugfixes. Das Entwicklungsteam pflegt faktisch zwei Systeme gleichzeitig, was den vermeintlichen Geschwindigkeitsvorteil des Neubaus häufig komplett auffrisst.
- Der Cutover-Tag als Single Point of Failure. Nach Monaten ohne produktive Validierung soll das neue System an einem Stichtag alles auf einmal richtig machen. Jeder übersehene Edge-Case trifft gleichzeitig ein – unter maximalem Druck, mit minimaler Vorwarnzeit.
Ich beschreibe diese Dynamik ausführlicher in meinem Artikel Der Big-Bang-Mythos: Warum Rewrites scheitern.
Die Alternative: das Strangler-Fig-Pattern
Statt alles auf einmal zu ersetzen, umschließt du das Altsystem schrittweise – benannt nach der Würgefeige, die einen Wirtsbaum langsam übernimmt, bis dieser irgendwann nicht mehr gebraucht wird. Ein Routing-Layer entscheidet pro Funktion, ob die alte oder neue Implementierung zuständig ist. Nach jedem einzelnen Migrationsschritt ist das Gesamtsystem wieder vollständig lauffähig – nie ein monatelanger Schwebezustand.
Der praktische Ablauf ist im Leitfaden zur Zero-Downtime-Modernisierung im Detail beschrieben.
Wann ein kompletter Neubau doch die richtige Wahl ist
Es gibt legitime Ausnahmen: Wenn die zugrunde liegende Technologie nicht mehr wartbar oder gar nicht mehr lauffähig ist (z. B. End-of-Life-Plattformen ohne Sicherheitsupdates), wenn das Geschäftsmodell sich fundamental geändert hat und kaum noch Überschneidung mit dem Altsystem besteht, oder wenn das bestehende System so klein ist, dass ein Neubau tatsächlich in Tagen statt Monaten möglich ist. Der entscheidende Unterschied: Diese Entscheidung sollte auf einer nüchternen Analyse basieren – nicht auf dem Bauchgefühl "der Code fühlt sich alt an".
Eine einfache Entscheidungshilfe
- Kann ich das größte Problem isoliert lösen, ohne das ganze System anzufassen? → Refactoring/Strangler-Fig
- Gibt es dokumentiertes oder rekonstruierbares Fachwissen im Altsystem? → Migration statt Neubau
- Ist die Plattform selbst technisch am Ende (kein Support, keine Sicherheitsupdates mehr)? → Neubau kann nötig sein
- Ist das System klein genug, um es realistisch in wenigen Wochen neu zu bauen? → Neubau kann sich lohnen
Fazit
Ein Big-Bang-Rewrite verspricht einen sauberen Neuanfang – und liefert in der Praxis meist doppelte Wartungslast, verlorenes Fachwissen und ein riskantes Cutover-Wochenende. Das Strangler-Fig-Pattern erreicht dasselbe Ziel – ein modernes, wartbares System – mit deutlich geringerem Risiko und einem Team, das nie monatelang ohne sichtbaren Fortschritt arbeitet.
Stehst du vor der Entscheidung "refactorieren oder neu bauen"? Im Architecture & Code Health Audit bewerte ich dein System objektiv und zeige dir den risikoärmsten Weg zum Ziel.