PHP-Anwendung: modernisieren oder neu schreiben?

Eine gewachsene PHP-Anwendung steht selten zur Debatte, solange sie zuverlässig läuft. Sobald Änderungen aber Monate dauern, Sicherheitsupdates ausbleiben oder niemand mehr den Checkout anfassen will, taucht dieselbe Frage auf: alles neu schreiben oder die bestehende Anwendung modernisieren?

Die Antwort ist selten eine Frage des Geschmacks. Sie hängt davon ab, wie viel Geschäftswissen im bestehenden Code steckt, wie gut sich dieser Code ändern lässt und welches Risiko das Unternehmen tragen kann.

Warum die Frage oft am falschen Punkt beginnt

Ein Neuschreiben klingt sauber. Der alte Code hat sichtbare Probleme, und ein neues Projekt würde endlich nach aktuellen Standards entstehen. Diese Perspektive erklärt aber nicht, was das Unternehmen braucht.

Die entscheidende Frage lautet nicht, ob der bestehende Code schön ist. Sie lautet, welche Geschäftsregeln erhalten bleiben müssen und welche sich ändern sollen. Wer das nicht trennt, plant ein Projekt, dessen Umfang niemand kennt.

Was ein Neuschreiben still verwirft

In einer Anwendung, die acht bis zwölf Jahre im Einsatz ist, steckt mehr Geschäftslogik als in jedem Pflichtenheft. Sonderfälle für einzelne Kunden, Rundungsregeln bei Rechnungen, Ausnahmen im Versand, historisch gewachsene Rabatte. Solche Regeln sind selten dokumentiert. Sie existieren als Code, als Kommentar oder als Workaround, den seit Jahren niemand mehr angefasst hat.

Wer neu schreibt, übernimmt zunächst nur die Regeln, die jemand aktiv kennt. Der Rest verschwindet. Das fällt nicht am ersten Tag auf, sondern Wochen später, wenn eine Rechnung um zwei Cent abweicht oder eine Bestellung nicht mehr ausgelöst werden kann.

Ein Neuschreiben ist deshalb nicht nur eine technische Aufgabe. Es ist eine Rekonstruktion von Wissen, das im alten System bereits vorhanden ist.

Die Kostenprofile beider Wege

Ein Neuschreiben bündelt Kosten und Risiko in einem Projekt. Das Team baut monatelang, ohne dass Nutzer davon profitieren. Häufig läuft die alte Anwendung parallel weiter und wird weiter gepflegt. Der Umstellungstag ist der riskanteste Moment, weil Fehler dort erstmals in Produktion sichtbar werden.

Eine Modernisierung verteilt den Aufwand über mehrere Quartale. Die Anwendung bleibt lieferfähig, Releases finden weiter statt, und jede Änderung lässt sich einzeln prüfen. Der Preis dafür ist Geduld: Der sichtbare Fortschritt ist kleiner, und das Team braucht Disziplin, damit aus dem Vorhaben kein dauerhaftes Parallelprojekt wird.

Beide Wege können richtig sein. Sie haben nur unterschiedliche Fehlerarten. Ein gescheitertes Neuschreiben kostet Jahre. Eine gescheiterte Modernisierung kostet Vertrauen, weil sie nie zu Ende geführt wird.

Der riskanteste Moment eines Neuschreibens ist der Tag der Umstellung. Bei einer Modernisierung gibt es diesen Tag nicht.

Vier Prüfungen vor der Entscheidung

Bevor Sie zwischen beiden Wegen wählen, prüfen Sie vier Punkte. Sie sagen mehr über das Risiko aus als der Zustand des Codes.

Testabdeckung. Gibt es Tests für die Wege, über die Geld fließt? Rechnungen, Zahlungen, Erstattungen, Steuern, Versand. Eine Abdeckung von 30 Prozent kann ausreichen, wenn sie genau diese Pfade abdeckt. Sie kann nutzlos sein, wenn getestet wurde, was leicht zu testen war.

Abhängigkeiten. Welche PHP-Version läuft, welche Framework-Version, welche Composer-Pakete sind verlassen? Werkzeuge wie composer outdated und composer audit liefern eine erste Liste. Entscheidend ist, ob für jedes Paket ein unterstützter Nachfolger existiert.

Deployments. Können Sie heute eine Änderung ausliefern und zurückrollen, ohne dass jemand manuell Dateien kopiert? Wenn das nicht wiederholbar ist, erschwert es beide Wege. Ein Neuschreiben ohne verlässliches Deployment reproduziert das Problem nur.

Wissensverteilung. Wie viele Personen können deployen, Fehler beheben und Zugänge verwalten? Wenn es eine ist, hat das Unternehmen zuerst ein Betriebsproblem, unabhängig von der Entscheidung.

Hybride Wege: Strangler und etappenweise Ablösung

Sie müssen nicht zwischen vollständiger Modernisierung und komplettem Neubau wählen. Der Strangler-Ansatz setzt eine neue Schicht vor die bestehende Anwendung und verschiebt Bereich für Bereich. Ein Routing-Layer leitet zuerst eine Route auf den neuen Code, später weitere. Der alte Code bleibt als Referenz erreichbar, bis ein Bereich vollständig ersetzt und geprüft ist.

Bei einer etappenweisen Ablösung ersetzen Sie einzelne Domänen, etwa den Kundenbereich, während der Rest weiterläuft. Während der Übergangszeit laufen beide Teile parallel, und Sie vergleichen Ergebnisse, bevor Sie den alten Pfad abschalten. Das funktioniert gut bei klar getrennten Modulen. Es funktioniert schlecht, wenn Datenmodelle und Geschäftslogik stark verwoben sind.

Der Vorteil dieser Wege: Sie erzeugen Erfahrung. Jede abgeschlossene Etappe zeigt, wie sich die Anwendung wirklich verhält, und macht die nächste Schätzung belastbarer.

Was eine seriöse Schätzung braucht

Eine Zahl ohne Grundlage ist eine Vermutung, die später teuer korrigiert wird. Eine belastbare Schätzung entsteht aus einer Bestandsaufnahme:

• Liste der geschäftskritischen Abläufe und ihrer technischen Pfade
• Module, Abhängigkeiten und bekannte Problemzonen
• Datenmodell und Migrationsbedarf
• externe Integrationen und ihre Vertragsbedingungen
• Zugänge, Infrastruktur und Deployment-Weg
• Teststrategie für die kritischen Pfade
• Cutover-Plan mit Rückfallweg

Auf dieser Basis lassen sich beide Varianten vergleichen, statt sie gegeneinander zu behaupten.

Wann ein Neuschreiben sinnvoll sein kann

Es gibt Fälle, in denen ein Neuschreiben die bessere Wahl ist. Wenn sich das Produkt grundlegend ändert, wenn die eingesetzte Technologie nicht mehr unterstützt wird und kein Migrationspfad existiert, oder wenn die Anwendung klein, gut getestet und vollständig verstanden ist. Auch dann gilt: schrittweise liefern, nicht in einem einzigen großen Schritt.

Für die meisten gewachsenen PHP-Anwendungen ist die Modernisierung jedoch der wirtschaftlichere Weg. Sie erhält das Geschäftswissen, beseitigt die größten Risiken zuerst und bleibt während der Arbeit lieferfähig.

Fazit

Die Entscheidung zwischen Modernisierung und Neuschreiben ist keine Glaubensfrage. Sie hängt davon ab, was der bestehende Code leistet, wie gut Sie ihn ändern können und wie viel Risiko das Unternehmen tragen kann.

Wenn Sie diese Grundlage klären wollen, beginnt der nächste Schritt mit einer PHP-Modernisierung oder einer breiteren Software-Modernisierung. Wie Sie die Risiken vorher erkennen, beschreibt der Beitrag technische Schulden erkennen.