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. Und sie beginnt oft mit einem Denkfehler.
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-Versionen, keine Tests, globaler Zustand, SQL direkt in Templates. Diese Unterscheidung ist der Kern jedes ehrlichen Kostenvergleichs.
Warum die Modernisierung vs Neuentwicklung Kosten selten fair verglichen werden
Der Vergleich wird in der Regel unfair geführt, 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 ja 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 dramatisch.
Welche Kosten bei einer Neuentwicklung fast immer unterschätzt werden
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.
- 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.
- Feature-Freeze: Während der oft ein bis zwei Jahre dauernden Neuentwicklung steht die Weiterentwicklung des Geschäfts faktisch still, oder Sie pflegen jede neue Anforderung zweimal.
- 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. Geht etwas schief, steht das Geschäft. Dieses Risiko ist real und teuer.
Die Neuentwicklung tauscht bekannte, sichtbare Probleme gegen unbekannte, unsichtbare ein. Und unbekannte Risiken lassen sich kaum seriös budgetieren.
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.
In der Praxis sieht ein solcher Weg oft so aus:
- 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, spürbar bessere Performance und behebt bekannte Schwachstellen.
- 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.
- 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.
- Strangler-Pattern anwenden: Alte Teile nach und nach durch neue ersetzen, während das System durchgehend produktiv bleibt. Der alte Code wird schrittweise "erwürgt", bis am Ende nichts mehr von ihm übrig ist.
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.
Wann ist eine Neuentwicklung trotzdem die richtige Entscheidung?
Eine Neuentwicklung ist sinnvoll, wenn die Fachlogik selbst überholt ist, nicht nur der Code. Wenn das, was die Software tut, nicht mehr zum Geschäft passt, hilft kein Refactoring.
Konkrete Fälle, in denen der Neubau die ehrlichere Wahl ist:
- Das Geschäftsmodell hat sich grundlegend geändert und die alte Logik bildet die neue Realität schlicht nicht mehr ab.
- Die Technologie ist nicht mehr nur alt, sondern ohne Sicherheitsupdates und ohne verfügbare Entwickler am Markt, etwa eine tote Framework-Version ohne jeden Migrationspfad.
- Die Anwendung ist klein und überschaubar genug, dass ein Neubau real in Wochen statt Jahren machbar ist.
Der entscheidende Test lautet: Wollen Sie das, was das System tut, behalten? Wenn ja, ist Modernisierung fast immer günstiger und sicherer. Wollen Sie etwas grundlegend anderes bauen, ist die Neuentwicklung ehrlich und richtig.
Modernisierung vs Neuentwicklung Kosten: die ehrliche Kurzfassung
Was ist bei einer alten PHP-Anwendung meistens günstiger, Modernisierung oder Neuentwicklung? In den meisten Fällen ist die Modernisierung günstiger und risikoärmer, weil sie die funktionierende Fachlogik bewahrt und nur den Code drumherum ersetzt. Eine Neuentwicklung erzwingt, jede bestehende Regel neu zu erforschen und einen riskanten Komplettumstieg zu stemmen.
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.
Ein ehrlicher Praxis-Tipp zum Schluss
Bevor Sie eine Entscheidung treffen, stellen Sie eine einzige Frage: Läuft das System, oder erfüllt es seinen Zweck nicht mehr? Läuft es und nervt nur der Code, dann ist die Modernisierung fast immer der günstigere Weg. Der teuerste Fehler ist, ein funktionierendes System wegzuwerfen, weil sein Code hässlich ist.
Wenn Sie diese Entscheidung gerade vor sich haben und einen unabhängigen Blick auf Ihren konkreten Fall brauchen, bei genau dieser Abwägung und der anschließenden Modernisierung unterstützt LegacyWerk.
