Rewrite oder Refactoring? Die teure Fehlentscheidung vermeiden

Der Wunsch nach einem kompletten Neuanfang ist verständlich. Der Code ist unübersichtlich, jede Änderung dauert zu lange, und niemand traut sich mehr, etwas anzufassen. In dieser Situation klingt ein sauberer Rewrite nach Befreiung. Doch die Entscheidung Rewrite oder Refactoring ist eine der teuersten, die Sie im Lebenszyklus einer Anwendung treffen. Und sie fällt erstaunlich oft falsch aus.

Der Grund ist ein Denkfehler: Ein System, das seit Jahren im Produktivbetrieb läuft, wird als Müll wahrgenommen. Dabei ist genau das Gegenteil wahr. Ein laufendes System ist der Beweis, dass die Fachlogik funktioniert. Das eigentliche Problem ist fast nie die Logik selbst, sondern der Code drumherum: die Architektur, die Abhängigkeiten, die fehlenden Tests.

Was ist der Unterschied zwischen Rewrite und Refactoring?

Ein Rewrite ersetzt die bestehende Anwendung durch eine komplett neue Codebasis. Ein Refactoring verbessert die Struktur des vorhandenen Codes schrittweise, ohne sein nach außen sichtbares Verhalten zu verändern.

Beim Rewrite fangen Sie technisch bei null an. Sie behalten die Anforderungen, werfen aber den Code weg. Beim Refactoring bleibt das System die ganze Zeit lauffähig und auslieferbar. Sie zerlegen einen 4000-Zeilen-Controller in Services, führen Dependency Injection ein, ersetzen direkte SQL-Strings durch Prepared Statements oder eine Query-Schicht. Der Nutzer merkt davon nichts. Genau das ist der Punkt.

Warum ist ein Rewrite meistens die teuerste Option?

Ein Rewrite ist meistens die teuerste Option, weil Sie über Jahre gewachsenes Fachwissen wegwerfen, das nirgends dokumentiert ist außer im alten Code selbst.

In einer über zehn Jahre gewachsenen PHP-Anwendung steckt eine enorme Menge impliziten Wissens. Jede seltsame if-Abzweigung, jeder Sonderfall in der Rechnungsberechnung, jeder Workaround für einen bestimmten Kunden ist die Antwort auf ein reales Problem, das irgendwann aufgetreten ist. Dieses Wissen ist der wahre Wert des Systems, und es steht in keinem Lastenheft.

Beim Rewrite passieren typischerweise drei Dinge:

• Der zweite System-Effekt. Das Team will endlich alles richtig machen und baut eine überkomplexe Architektur, die das eigentliche Ziel überwuchert.
• Der bewegliche Zielpunkt. Während Sie neu bauen, entwickelt sich das alte System weiter, weil der Betrieb ja weiterläuft. Sie holen einen Vorsprung nie ein.
• Der Big-Bang-Umstieg. Am Ende steht ein riskantes Go-live, bei dem zwei Systeme parallel korrekt funktionieren müssen. Genau hier gehen die Sonderfälle verloren, die Sie beim Nachbauen übersehen haben.

Die berühmteste Warnung dazu stammt von Joel Spolsky, der das komplette Neuschreiben von Code als "the single worst strategic mistake" bezeichnete. Das ist überspitzt, trifft aber den Kern: Sie zahlen den vollen Preis noch einmal für Funktionalität, die bereits existiert und bewiesenermaßen funktioniert.

Wann ist ein Refactoring die richtige Entscheidung?

Refactoring ist die richtige Entscheidung, wenn die Fachlogik trägt und nur die technische Umsetzung veraltet ist. Das ist der Normalfall bei Legacy-PHP.

Konkrete Anzeichen dafür, dass Sie refactoren und nicht neu bauen sollten:

• Das System bildet Ihr Geschäft korrekt ab, ist aber schwer wartbar.
• Die Probleme heißen: keine Tests, alte PHP-Version, globaler State, verwobene Zuständigkeiten, direkte Datenbankzugriffe im View.
• Die Datenbank und die Domänenmodelle sind grundsätzlich sinnvoll.
• Sie können einzelne Bereiche isolieren und nacheinander verbessern.

Der große Vorteil: Refactoring liefert kontinuierlich Wert. Sie können ein Legacy-Projekt schrittweise auf eine aktuelle PHP-Version heben, mit der statische Analyse und PHPStan Fehlerklassen ausschließen, kritische Pfade mit Tests absichern und schleichend ein Framework wie Symfony oder Laravel einführen. Ein bewährtes Muster hierfür ist der Strangler-Fig-Ansatz: Sie legen neue, saubere Komponenten um den alten Kern und leiten Funktionalität Stück für Stück um, bis der alte Code irgendwann verhungert. Das System bleibt dabei jederzeit produktiv.

Wann ist ein Rewrite trotzdem gerechtfertigt?

Ein Rewrite ist gerechtfertigt, wenn die technische Basis so grundlegend nicht mehr tragfähig ist, dass Reparatur teurer wäre als Neubau. Diese Fälle sind selten, aber real.

Ehrlicherweise gibt es Situationen, in denen Neuentwicklung die richtige Wahl ist:

• Die Sprachversion oder das Framework wird nicht mehr mit Sicherheitsupdates versorgt und ein Upgrade-Pfad existiert schlicht nicht mehr.
• Die Datenbankstruktur ist so verkorkst, dass die Daten selbst nicht mehr vertrauenswürdig sind.
• Das Geschäftsmodell hat sich fundamental geändert, und die alte Fachlogik ist kaum noch relevant.
• Es gibt keinen einzigen Menschen mehr, der das System versteht, und keine Möglichkeit, es sicher zu betreiben.

Wichtig: Selbst dann ist der schrittweise Ersatz meist dem Big Bang vorzuziehen. Ein Rewrite ist eine Frage des "Wie", nicht nur des "Ob".

Wie treffen Sie die Entscheidung strukturiert?

Treffen Sie die Entscheidung anhand von Kriterien, nicht aus dem Bauch heraus. Der Frust über schlechten Code ist ein legitimes Gefühl, aber ein schlechter Ratgeber für eine sechsstellige Investition.

Bewerten Sie mindestens diese Dimensionen ehrlich:

1. Fachlogik: Ist sie korrekt und wertvoll, oder tatsächlich überholt?
2. Datenqualität: Sind die Daten in der Datenbank sauber und migrierbar?
3. Sicherheit: Gibt es konkrete Lücken (SQL-Injection, veraltete Abhängigkeiten), und sind diese gezielt schließbar?
4. Wissen: Versteht noch jemand das System, oder droht Totalverlust?
5. Wartungskosten: Wie teuer ist eine Änderung heute wirklich?

Wenn die Fachlogik und die Daten tragen, spricht fast alles für Refactoring. Kippen mehrere dieser Punkte gleichzeitig ins Rote, verdient ein Teil-Rewrite eine ernsthafte Prüfung.

Ehrliches Fazit

Die Frage Rewrite oder Refactoring hat selten die Antwort, die man sich im Moment des Frusts wünscht. Ein System, das läuft, ist kein Müll. Es ist ein Aktivposten mit technischen Schulden. Und Schulden tilgt man in der Regel günstiger durch geplante Rückzahlung als durch Insolvenz und Neugründung. Prüfen Sie also zuerst, was der Code wirklich braucht, bevor Sie ihn abschreiben. Ein guter Praxis-Tipp: Nehmen Sie sich einen einzigen schmerzhaften Bereich vor, sichern Sie ihn mit Tests ab und refactoren Sie ihn sauber. Was Sie dabei über die Machbarkeit lernen, ist mehr wert als jede Schätzung auf dem Papier.

Genau bei dieser Entscheidung und der anschließenden schrittweisen Modernisierung unterstützt LegacyWerk, wenn Sie eine unabhängige Einschätzung statt eines vorschnellen Neubaus suchen.