Die Frage kommt fast immer in derselben Form: "Sollen wir das alte System noch anfassen oder gleich neu bauen?" Dahinter steckt eine Kostenfrage, die selten sauber gerechnet wird. Stattdessen entscheidet oft das Bauchgefühl — und das Bauchgefühl sagt bei zehn Jahre altem PHP-Code meistens: wegwerfen. Das ist in den meisten Fällen die teuerste und riskanteste Entscheidung, die Sie treffen können.
Ein System, das seit Jahren im Produktivbetrieb läuft, ist kein Müll. Es ist der Beweis, dass Ihre Fachlogik funktioniert. Jede Sonderregel für den Rechnungslauf, jeder Edge Case im Import, jede stille Ausnahme, die irgendwann ein Kunde gemeldet hat — all das steckt im Code und wurde über Jahre gehärtet. Genau dieses Wissen werfen Sie bei einer Neuentwicklung als Erstes weg.
Warum die Neuentwicklung fast nie den besten ROI der Modernisierung liefert
Ein Neubau wirkt attraktiv, weil er auf dem Papier sauber ist. In der Praxis bezahlen Sie ihn dreifach: einmal für die Entwicklung des neuen Systems, einmal für das Nachbauen jahrelang gewachsener Fachlogik, die niemand vollständig dokumentiert hat, und einmal für den Parallelbetrieb, bis das Neue wirklich alles kann, was das Alte konnte.
Der teuerste Posten ist dabei unsichtbar: die Fachlogik, die nur im alten Code existiert. Kein Lastenheft beschreibt sie vollständig. Sie merken erst nach dem Go-live, dass die alte Anwendung bei negativen Beträgen anders gerundet hat, dass ein bestimmter Kundentyp eine Ausnahmebehandlung brauchte, dass der nächtliche Cronjob eine Reihenfolge voraussetzte. Diese Lücken kosten Sie nach dem Launch echtes Geld — in Form von Fehlern beim Kunden.
Hinzu kommt das Risiko. Während der Neubau läuft, muss das alte System weiter gepflegt werden. Sie haben also zwei Codebasen und ein eingefrorenes Featureset, oft über Monate. Neuentwicklungen von Kernsystemen sind nicht ohne Grund für lange Laufzeiten und Budgetüberschreitungen bekannt.
Das eigentliche Problem ist selten die Fachlogik, sondern der Code drumherum
Wenn Legacy-Anwendungen schmerzen, liegt es fast nie an dem, was sie fachlich tun. Es liegt an dem, wie sie es tun. Typische Kostentreiber, die sich gezielt beheben lassen:
- Vermischung von Logik und Ausgabe: SQL-Abfragen und Geschäftsregeln stecken direkt im HTML-Template. Jede Änderung ist ein Risiko, weil nichts isoliert testbar ist.
- Keine oder veraltete Dependency-Verwaltung: Kein Composer, manuell eingecheckte Bibliotheken, keine Update-Strategie.
- Nicht mehr unterstützte PHP-Versionen: Anwendungen auf PHP 5.6 oder 7.x erhalten keine Sicherheitsupdates mehr. Das ist kein Komfortthema, sondern ein Haftungsthema.
- Fehlende Tests: Ohne automatisierte Tests ist jede Änderung teuer, weil sie manuell abgesichert werden muss.
- Sicherheitslücken: SQL-Injection durch direkt konkatenierte Queries, fehlendes CSRF-Handling, im Klartext gespeicherte Passwörter.
Das Entscheidende: Diese Probleme betreffen die Hülle, nicht den Kern. Sie lassen sich schrittweise beheben, während das System weiterläuft und Umsatz macht. Genau hier entsteht der Hebel für den ROI der Modernisierung.
Wie berechnet man den ROI einer Legacy-Modernisierung?
Wie berechnet man den ROI einer Legacy-Modernisierung? Stellen Sie den laufenden Kosten des Ist-Zustands die einmaligen Kosten der Modernisierung gegenüber und rechnen Sie beides über einen realistischen Zeitraum von zwei bis drei Jahren.
Die laufenden Kosten des Nichtstuns werden fast immer unterschätzt. Sie bestehen aus mehreren Posten, die Sie für Ihr eigenes System beziffern können:
- Entwicklungsgeschwindigkeit: Wie lange dauert heute ein durchschnittliches Feature — und wie lange dürfte es in einer sauberen Codebasis dauern? Die Differenz zahlen Sie jeden Monat.
- Fehler- und Ausfallkosten: Wie oft gibt es Produktionsfehler, und was kostet ein Ausfall an Umsatz und Personalzeit?
- Abhängigkeit von einzelnen Personen: Was passiert, wenn der eine Entwickler geht, der das System noch versteht? Dieses Risiko hat einen Preis, auch wenn er selten aufgeschrieben wird.
- Sicherheits- und Compliance-Risiko: Eine veraltete PHP-Version oder eine bekannte Lücke kann im Schadensfall ein Vielfaches der Modernisierungskosten verursachen.
Auf der anderen Seite stehen die Investitionskosten der Modernisierung. Der Trick ist, diese nicht als einen großen Block zu sehen, sondern in Etappen mit jeweils eigenem Nutzen.
Warum schrittweise Modernisierung den ROI der Modernisierung schneller sichtbar macht
Ein großer Vorteil gegenüber dem Neubau: Sie müssen nicht Jahre auf den Return warten. Eine schrittweise Modernisierung liefert nach jeder Etappe messbaren Nutzen. Eine bewährte Reihenfolge:
- Stabilisieren: PHP-Version auf einen unterstützten Stand heben, Composer einführen, die gröbsten Sicherheitslücken schließen. Das senkt sofort das Risiko.
- Absichern: Charakterisierungstests um die kritischen Abläufe legen, damit spätere Änderungen nicht unbemerkt etwas zerstören. Ab hier sinken die Kosten jeder Änderung.
- Entkoppeln: Fachlogik aus Templates und Controllern herauslösen, Datenzugriff kapseln. Schrittweise können Sie ein Framework wie Symfony oder Laravel einführen, ohne alles neu zu schreiben — etwa über das Strangler-Fig-Muster, bei dem neue Teile das Alte nach und nach ersetzen.
Der entscheidende Punkt ist, dass Sie nach Schritt eins bereits ein sichereres System haben, nach Schritt zwei ein änderbares, und erst danach die Struktur verbessern. Jede Etappe zahlt für sich. Wenn das Budget dazwischen pausiert, steht das System trotzdem besser da als vorher.
Wann ist eine Neuentwicklung doch die richtige Wahl?
Wann lohnt sich ein Neubau statt einer Modernisierung? Wenn die Fachlogik selbst überholt ist, das Geschäftsmodell sich grundlegend geändert hat oder die zugrunde liegende Technologie keinerlei Migrationspfad mehr bietet — dann kann ein Neubau günstiger sein.
Ehrlichkeit gehört dazu: Nicht jedes Altsystem ist rettenswert. Wenn Sie eine Anwendung modernisieren würden, deren fachliche Anforderungen heute völlig anders wären, konservieren Sie das falsche Wissen. Der Unterschied ist die richtige Frage: Funktioniert die Fachlogik noch, oder ist sie überholt? Im ersten Fall — und das ist die Mehrheit — gewinnt die Modernisierung fast immer beim ROI.
Ein ehrlicher Praxis-Tipp zum Schluss
Bevor Sie über Neubau oder Modernisierung entscheiden, rechnen Sie ein Quartal lang mit: Wie viele Stunden fließen in Fehlerbehebung, wie lange dauern Features wirklich, wie oft gibt es Sicherheits- oder Ausfallschrecken? Diese Zahlen sind die Grundlage jeder ehrlichen ROI-Rechnung — und sie überraschen die meisten Teams. Meist ist die Antwort nicht "alles neu", sondern "das Richtige zuerst reparieren".
Bei genau dieser Bestandsaufnahme und der schrittweisen Modernisierung gewachsener PHP-Anwendungen unterstützt LegacyWerk — ehrlich auch dann, wenn im Einzelfall der Neubau die bessere Rechnung ergibt.
