Irgendwann kommt in fast jedem Legacy-Projekt der Satz: "Das schreiben wir neu, von Grund auf, sauber." Er klingt nach Befreiung. Nach dem Ende der Workarounds, der PHP-5-Reste, der Klasse mit 4.000 Zeilen. Und trotzdem ist es meist die falsche Entscheidung. Der komplette Neubau bei laufendem Betrieb, der berühmte Big Bang, hat eine bemerkenswert schlechte Erfolgsquote. Nicht weil die Entwickler schlecht sind. Sondern weil das Vorhaben strukturell riskant ist.
Ich arbeite seit 13 Jahren mit PHP und verbringe die meiste Zeit damit, gewachsene Anwendungen zu retten statt sie zu ersetzen. Deshalb hier eine ehrliche Einordnung, warum der Big Bang Rewrite so oft scheitert und was in der Praxis besser funktioniert.
Warum scheitert ein Big Bang Rewrite so oft?
Ein Big Bang Rewrite scheitert meist, weil das alte System jahrelang implizites Wissen angesammelt hat, das nirgends dokumentiert ist. Jede seltsame if-Bedingung, jeder Sonderfall in der Rechnungslogik, jede scheinbar unnötige Prüfung ist in der Regel die Narbe eines echten Produktionsproblems.
Wenn Sie neu anfangen, starten Sie nicht bei null. Sie starten im Minus. Denn das laufende System erledigt bereits tausend Dinge korrekt, die niemand mehr bewusst kennt. Der Neubau muss all das wiederentdecken, oft erst dann, wenn ein Kunde sich beschwert, dass seine Umsatzsteuer im EU-Ausland plötzlich falsch berechnet wird.
Dazu kommt ein zweites Problem: Während Sie neu bauen, steht die alte Anwendung nicht still. Das Business braucht weiter Features, Bugfixes, gesetzliche Anpassungen. Sie pflegen also zwei Systeme gleichzeitig und jede Änderung am Altsystem vergrößert den Abstand zum Neubau. Das ist ein Rennen gegen ein sich bewegendes Ziel.
Das laufende System ist kein Müll, sondern der Beweis, dass die Logik stimmt
Eine Anwendung, die seit acht oder zehn Jahren im produktiven Einsatz ist, ist kein Sanierungsfall. Sie ist der Beweis, dass die Fachlogik funktioniert. Menschen verdienen damit ihr Geld, wickeln Bestellungen ab, erstellen Rechnungen. Das ist enorm viel wert und es ist genau das, was ein Rewrite zuerst aufs Spiel setzt.
Wichtig ist die Unterscheidung: Das Problem ist fast nie die Fachlogik. Das Problem ist der Code drumherum. Die Fachlogik, wie ein Rabatt berechnet wird oder wann ein Auftrag als bezahlt gilt, ist meist korrekt und wertvoll. Was weh tut, ist die Umgebung: veraltete PHP-Version, SQL-Strings direkt im Controller, keine Tests, globaler Zustand, ein selbstgebautes Framework von 2013.
Das ist eine gute Nachricht, denn Code-Umgebung lässt sich schrittweise verbessern, ohne die bewährte Logik anzufassen. Genau hier setzt die Alternative zum Big Bang an.
Was kostet ein gescheiterter Rewrite wirklich?
Die Kosten eines gescheiterten Rewrites sind fast immer höher als die reine Entwicklungszeit, weil parallel das Altsystem weitergepflegt werden muss und das Business monatelang keine sichtbaren Verbesserungen bekommt. Die typischen versteckten Kosten:
- Doppelte Wartung: Zwei Codebasen, die beide funktionieren müssen, über viele Monate hinweg.
- Feature-Freeze in der Wahrnehmung: Das Business zahlt viel und sieht lange nichts Neues. Das kostet politisches Kapital und Vertrauen.
- Wissensverlust: Sonderfälle, die im Altsystem sauber gelöst waren, tauchen im Neubau als frische Produktionsbugs wieder auf.
- Migrationsrisiko am Ende: Der riskanteste Moment ist der große Umschalttag. Datenmigration, unentdeckte Abhängigkeiten und Edge Cases treffen alle gleichzeitig auf.
In der Praxis wird ein Rewrite selten sauber abgebrochen. Er versandet. Das Budget ist weg, der Neubau ist zu 70 Prozent fertig und niemand traut sich umzuschalten. Am Ende laufen beide Systeme und der ursprüngliche Zustand ist schlechter als vorher.
Wann ist eine Neuentwicklung trotzdem sinnvoll?
Eine komplette Neuentwicklung ist dann sinnvoll, wenn sich das Geschäftsmodell selbst grundlegend geändert hat und die alte Fachlogik nicht mehr passt, nicht wenn nur der Code hässlich ist. Hässlicher Code allein rechtfertigt keinen Neubau.
Gute Gründe für einen echten Neubau können sein:
- Die fachlichen Anforderungen haben sich so stark verschoben, dass die alte Domänenlogik im Kern falsch ist, nicht nur alt.
- Eine tragende Abhängigkeit ist endgültig tot und ohne jeden Migrationspfad, etwa ein kommerzielles Framework, das es nicht mehr gibt.
- Das System ist klein genug, dass ein Neubau in Wochen und nicht in Jahren machbar ist.
Sobald ein Rewrite länger als ein paar Monate dauern würde, steigt das Risiko überproportional. Dann ist die schrittweise Modernisierung fast immer die klügere Wahl.
Die Alternative: modernisieren statt neu bauen
Die sichere Alternative zum Big Bang ist die inkrementelle Modernisierung, bei der das System jederzeit lauffähig bleibt und in kleinen, überprüfbaren Schritten verbessert wird. Statt eines riskanten Umschalttags gibt es viele kleine, reversible Schritte. Ein bewährter Ablauf:
- Charakterisierungstests schreiben: Erst das aktuelle Verhalten in Tests festhalten, auch das vermeintlich falsche. So merken Sie sofort, wenn eine Änderung etwas kaputt macht.
- PHP- und Framework-Version anheben: Ein Sprung auf eine aktuelle, unterstützte PHP-Version bringt Sicherheit und Performance, ohne die Fachlogik anzutasten.
- Fachlogik von Infrastruktur trennen: Die wertvolle Domänenlogik aus Controllern und SQL-Strings herauslösen, damit sie testbar und wiederverwendbar wird.
- Nach dem Strangler-Fig-Muster ersetzen: Neue Teile hinter der bestehenden Anwendung aufbauen und Stück für Stück Routen umleiten. Das Altsystem schrumpft, während das Neue wächst.
Der entscheidende Unterschied: Bei jedem Schritt läuft das System in Produktion und liefert weiter Wert. Sie können jederzeit anhalten, ohne dass etwas kaputt ist. Genau diese Reversibilität fehlt dem Big Bang komplett.
Ein ehrlicher Praxis-Tipp zum Schluss
Bevor Sie einen Neubau beschließen, stellen Sie eine einzige Frage: Wollen Sie die Fachlogik wirklich ändern oder stört Sie nur der Code, in dem sie steckt? In den allermeisten Fällen ist es Letzteres. Und Code lässt sich sanieren, ohne das über Jahre bewährte Verhalten wegzuwerfen.
Behandeln Sie das laufende System mit Respekt. Es hat sich seinen Platz verdient. Der teuerste Fehler ist, Funktionierendes wegzuwerfen, um es aufwendig und fehleranfällig neu zu erfinden. Wenn Sie vor genau dieser Entscheidung stehen und eine ehrliche Einschätzung suchen, ob Modernisierung oder Neubau der richtige Weg ist, ist das genau die Art von Frage, bei der ich mit LegacyWerk unterstütze.
