Modernisierung oder Neuentwicklung? Kosten, Kriterien und wann der Neubau doch richtig ist

Irgendwann fällt in fast jedem Projekt mit einer alten PHP-Anwendung der Satz: "Das lohnt sich nicht mehr, das schreiben wir neu." Er klingt vernünftig, sauber, nach einem Neuanfang. In der Praxis ist die Neuentwicklung aber meistens die teuerste und riskanteste Option von allen. Ich arbeite seit 13 Jahren mit PHP und verbringe die meiste Zeit damit, gewachsene Anwendungen zu retten statt sie zu ersetzen. Dieser Beitrag fasst zusammen, was ich Geschäftsführern und IT-Leitern in genau dieser Lage sage: wo die Kosten des Neubaus wirklich liegen, warum der große Umstieg so oft scheitert, woran Sie erkennen, dass nur der Code das Problem ist, und in welchen Fällen der Neubau trotzdem die ehrliche Antwort ist.

Vorweg die Haltung, auf der alles andere aufbaut: Ein System, das seit acht oder zwölf Jahren im Produktivbetrieb läuft, ist kein Müll. Es ist der Beweis, dass die Fachlogik funktioniert. Jede Sonderregel bei der Rechnungsstellung, jeder Rabattfall, jede krude Ausnahme im Bestellprozess wurde irgendwann eingebaut, weil ein echter Geschäftsfall sie erzwungen hat. Das Problem ist fast nie diese Logik. Das Problem ist der Code drumherum: veraltete PHP-Version, keine Tests, globaler Zustand, SQL direkt in Templates. Diese Unterscheidung ist der Kern jeder ehrlichen Rechnung.

Warum der Vergleich fast nie fair geführt wird

Der Vergleich ist in der Regel unfair, weil zwei ungleiche Dinge gegenübergestellt werden. Auf der einen Seite steht die Modernisierung mit all ihrem sichtbaren Ballast: der hässliche Code, die Altlasten, die man täglich vor Augen hat. Auf der anderen Seite steht die Neuentwicklung als Idee, glänzend und frei von jedem konkreten Problem, weil sie noch nicht existiert.

Verglichen wird also gelebte Realität mit einer Fantasie. In der Fantasie gibt es keine vergessene Schnittstelle zu einem alten Warenwirtschaftssystem, keine Datenmigration mit 15 Jahren inkonsistenter Datensätze, keinen Mitarbeiter, der als Einziger weiß, warum ein bestimmter Cronjob nachts um drei laufen muss. Sobald diese Dinge im Neubau auftauchen, und das tun sie, verschiebt sich das Kostenbild. Dazu kommt der "Second System Effect": Wer das alte System kennt, kennt seine Schwächen genau und unterschätzt massiv, wie viel implizites Wissen darin steckt. Das zweite System soll endlich alles richtig machen und bekommt eine Architektur, die das eigentliche Ziel überwuchert.

Welche Kosten bei einer Neuentwicklung fast immer fehlen

Die versteckten Kosten einer Neuentwicklung liegen selten im Schreiben des neuen Codes. Sie liegen in allem, was drumherum passieren muss, während das alte System weiterläuft.

• Wissensarchäologie: Niemand kennt mehr alle Regeln. Sie stecken nur im Code. Ein Neubau zwingt Sie, jede dieser Regeln erneut zu erforschen und zu dokumentieren, bevor Sie sie überhaupt neu bauen können. Der Rabatt, der nur für Bestandskunden aus einer bestimmten Region gilt. Die Rundungslogik in der Rechnungserstellung, die vor Jahren wegen einer Steuerprüfung angepasst wurde. Die drei If-Abfragen, die einen konkreten Datenfehler abfangen.
• Doppelter Betrieb: Bis das neue System vollständig ist, müssen beide Systeme parallel gepflegt werden. Jeder dringende Bugfix im Alten muss auch im Neuen nachgezogen werden, jede gesetzliche Anpassung zweimal.
• Der bewegliche Zielpunkt: Während Sie neu bauen, entwickelt sich das alte System weiter, weil der Betrieb weiterläuft. Jede Änderung am Altsystem vergrößert den Abstand zum Neubau. Sie holen einen Vorsprung nie ein.
• Feature-Freeze: Während der oft ein bis zwei Jahre dauernden Neuentwicklung steht die Weiterentwicklung des Geschäfts faktisch still. Das Business zahlt viel und sieht lange nichts Neues. Das kostet politisches Kapital und Vertrauen, lange bevor es Geld kostet.
• Datenmigration: Alte Datenbanken sind selten sauber. Die Migration historischer Daten in ein neues, striktes Schema ist regelmäßig aufwendiger als die eigentliche Anwendungslogik.
• Der Big-Bang-Umstieg: Am Tag der Umstellung wird alles gleichzeitig scharf geschaltet. Genau hier gehen die Sonderfälle verloren, die beim Nachbauen übersehen wurden, und sie tauchen als frische Produktionsbugs wieder auf, einen Kundenanruf nach dem anderen.

Die Neuentwicklung tauscht bekannte, sichtbare Probleme gegen unbekannte, unsichtbare ein. Und unbekannte Risiken lassen sich kaum seriös budgetieren.

Warum Big-Bang-Neuentwicklungen so oft scheitern

Der komplette Neubau bei laufendem Betrieb hat eine bemerkenswert schlechte Erfolgsquote. Nicht weil die Entwickler schlecht sind, sondern weil das Vorhaben strukturell riskant ist. 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.

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 Zustand ist schlechter als vorher: zwei Codebasen, doppelte Wartung, ein Team, das an keiner von beiden Freude hat. Joel Spolsky hat das komplette Neuschreiben von Code als "the single worst strategic mistake" bezeichnet. 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.

Was Modernisierung konkret bedeutet und warum sie planbarer ist

Modernisierung heißt nicht, den alten Code zu verschönern. Sie heißt, die funktionierende Fachlogik zu bewahren und den Code drumherum Schritt für Schritt zu ersetzen. Der entscheidende Unterschied zur Neuentwicklung: Sie liefern kontinuierlich, statt einmal am Ende.

1. Fundament sichern: Zuerst die PHP-Version anheben und Abhängigkeiten über Composer verwalten. Allein der Sprung von PHP 7.x auf eine aktuelle 8.x-Version bringt Sicherheitsupdates und spürbar bessere Performance. Was Ihre Version heute bedeutet, steht pro Version auf einer eigenen Seite.
2. Sicherheitsnetz einziehen: Charakterisierungstests schreiben, die das aktuelle Verhalten festhalten, auch wenn dieses Verhalten unschön ist. So merken Sie sofort, wenn ein Umbau etwas kaputt macht.
3. Ränder ablösen: Neue Funktionen als eigenständige Module oder Services bauen, etwa mit Symfony oder Laravel, und über eine klare Schnittstelle an den Altbestand anbinden.
4. Nach dem Strangler-Fig-Muster ersetzen: Alte Teile nach und nach durch neue ersetzen, während das System durchgehend produktiv bleibt. Ein Router oder Reverse Proxy leitet die passenden Anfragen an die neuen Teile, alles andere bleibt vorerst beim Altsystem. Wie das im Detail funktioniert, steht im eigenen Beitrag.

Der große Vorteil: Sie können jederzeit aufhören. Nach jedem Schritt haben Sie ein besseres, sichereres System als vorher, ohne je das große Risiko eines Komplettumbaus einzugehen. Die Kosten sind über die Zeit verteilt und an sichtbaren Ergebnissen messbar. Genau diese Umkehrbarkeit fehlt dem Big Bang vollständig.

Woran Sie erkennen, dass nur der Code das Problem ist

In den meisten Fällen ist nicht das System kaputt, sondern nur seine technische Verpackung. Das ist eine gute Nachricht, denn diese Probleme lassen sich schrittweise lösen, ohne die bewährte Logik anzutasten. Typische Symptome, die nach Modernisierung statt Neubau rufen:

• Veraltete PHP-Version: Ein Upgrade von PHP 7.x auf 8.4 ist Arbeit, aber ein überschaubares, planbares Projekt, in weiten Teilen mit Rector automatisierbar.
• Kein Framework oder ein totes Framework: Alten Zend-1- oder Symfony-1-Code kann man kapseln und stückweise nach Symfony oder Laravel migrieren.
• Keine Tests: Fehlende Tests sind ein Grund, welche zu schreiben, kein Grund, neu zu bauen.
• Unübersichtliche Struktur: Ein 4000-Zeilen-Controller lässt sich in Services zerlegen, direkte SQL-Strings in eine Query-Schicht überführen. Die Fachlogik bleibt dabei erhalten, der Nutzer merkt nichts.

Merkregel: Wenn Sie den Satz "Es macht fachlich das Richtige, aber der Code ist eine Katastrophe" unterschreiben würden, ist Modernisierung fast immer der bessere Weg.

Wann eine Neuentwicklung trotzdem richtig ist

Eine Neuentwicklung ist sinnvoll, wenn die Fachlogik selbst überholt ist, nicht nur der Code. Diese Fälle sind selten, aber real, und sie verdienen eine ehrliche Antwort statt eines Reflexes in die eine oder andere Richtung:

• Das Geschäftsmodell hat sich grundlegend geändert. Wenn das System von einem Geschäft ausgeht, das es so nicht mehr gibt, kämpfen Sie gegen die Architektur an. Beispiel: ein reines Einzelplatzsystem, das mandantenfähig und mehrsprachig werden soll.
• Eine zentrale Abhängigkeit ist tot, ohne Migrationspfad. Ein kommerzielles Framework, das es nicht mehr gibt, eine Datenbank ohne Nachfolger, eine Bibliothek mit ungepatchten kritischen Lücken, für die es kein Update mehr gibt.
• Die Daten selbst sind nicht mehr vertrauenswürdig. Wenn die Datenbankstruktur so verkorkst ist, dass niemand den Inhalten traut, hilft kein Refactoring der Anwendung darüber.
• Sicherheit lässt sich nicht mehr herstellen. SQL-Injection an tausend Stellen durch fehlende Prepared Statements, und eine Absicherung wäre teurer als ein Neubau.
• Jede Änderung dauert unverhältnismäßig lange, und zwar nachdem gezielte Refaktorierung bereits versucht wurde und nicht mehr greift. Vorher ist dieser Punkt kein Argument.
• 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.

Entscheidend: Diese Punkte müssen fachlich oder existenziell sein. "Der Code gefällt mir nicht" gehört nicht dazu. Und selbst wenn der Neubau richtig ist, ist der schrittweise Ersatz dem Big Bang fast immer vorzuziehen. Ein Rewrite ist eine Frage des "Wie", nicht nur des "Ob".

Die Entscheidung strukturiert treffen: fünf Kriterien, fünf Fragen

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 fünf Dimensionen ehrlich:

• Fachlogik: Ist sie korrekt und wertvoll, oder tatsächlich überholt?
• Datenqualität: Sind die Daten sauber und migrierbar, oder traut ihnen niemand?
• Sicherheit: Gibt es konkrete Lücken, und sind sie gezielt schließbar?
• Wissen: Versteht noch jemand das System, oder droht Totalverlust?
• Wartungskosten: Wie teuer ist eine Änderung heute wirklich, in Stunden und in Risiko?

Wenn Fachlogik und Daten tragen, spricht fast alles für Modernisierung. Kippen mehrere dieser Punkte gleichzeitig ins Rote, verdient ein Teil-Neubau eine ernsthafte Prüfung. Bevor Sie Geld in die Hand nehmen, beantworten Sie dazu schriftlich:

• Was genau stört, die Fachlogik oder der Code drumherum?
• Haben wir eine gezielte Modernisierung überhaupt schon versucht?
• Gibt es eine harte Deadline von außen, etwa das Support-Ende einer Kernkomponente?
• Können wir das bestehende Verhalten mit Tests absichern, bevor wir etwas ändern?
• Was kostet ein Neubau realistisch, inklusive Parallelbetrieb, Feature-Freeze und der Wiederentdeckung aller Sonderfälle?

Die Entscheidungs-Matrix zu diesen fünf Kriterien gibt es als Download am Ende des Beitrags.

Die ehrliche Kurzfassung

Was ist bei einer alten PHP-Anwendung meistens günstiger, Modernisierung oder Neuentwicklung? In den meisten Fällen die Modernisierung, weil sie die funktionierende Fachlogik bewahrt und nur den Code drumherum ersetzt. Eine Neuentwicklung erzwingt, jede bestehende Regel neu zu erforschen, und stemmt am Ende einen riskanten Komplettumstieg. Rechnen Sie beide Wege nicht nach Bauchgefühl gegeneinander, sondern mit den echten Posten: doppelter Betrieb, Feature-Freeze und Datenmigration gehören auf die Rechnung der Neuentwicklung, sonst ist der Vergleich wertlos. Wie die Rechnung über zwei bis drei Jahre aussieht, steht im Beitrag zum ROI.

Ein Praxis-Tipp zum Schluss

Nehmen Sie sich zwei oder drei besonders schmerzhafte Änderungswünsche der letzten Monate und fragen Sie: Wären die mit sauberem, modernem Code drumherum trivial gewesen? Wenn ja, ist Ihr System gesund, nur seine Hülle ist alt. Dann nehmen Sie sich einen einzigen schmerzhaften Bereich vor, sichern ihn mit Tests ab und refactoren ihn sauber. Was Sie dabei über die Machbarkeit lernen, ist mehr wert als jede Schätzung auf dem Papier. Der teuerste Fehler bleibt, ein funktionierendes System wegzuwerfen, weil sein Code hässlich ist.

Wenn Sie diese Entscheidung gerade vor sich haben und eine unabhängige Einschätzung statt eines vorschnellen Neubaus suchen, ist das genau die Art von Frage, bei der ich mit LegacyWerk unterstütze, auch dann, wenn die Antwort im Einzelfall Neubau heißt.