PHP-Legacy modernisieren: Refactoring, Strangler Pattern oder Rewrite?

Das Baujahr einer PHP-Anwendung ist der schlechteste Ratgeber bei der Frage, ob du refaktorieren, schrittweise herauslösen oder neu bauen solltest. Refactoring passt, wenn wertvolle Geschäftslogik und die architektonische Basis erhalten werden können. Das Strangler-Fig-Vorgehen passt, wenn sich einzelne Fähigkeiten herauslösen lassen, während das System weiterläuft. Ein Rewrite ist erst dann sinnvoll, wenn sich die bestehende Basis nicht mehr sicher weiterentwickeln lässt und das erforderliche Verhalten zuvor erfasst und verifiziert wurde.

Was eine PHP-Anwendung wirklich zu Legacy macht

Nicht das Alter, sondern das Änderungsrisiko. Genuin problematisch wird ein System, wenn mehrere der folgenden Bedingungen zusammenkommen:

• Nicht mehr unterstützte Laufzeit: Die eingesetzte PHP-Version erhält keine Sicherheitskorrekturen mehr oder verhindert den Einsatz gepflegter Bibliotheken.
• Blockierte Abhängigkeiten: Frameworks, Pakete oder Erweiterungen sind aufgegeben, untereinander unvereinbar oder nur mit nicht dokumentierten Patches betreibbar.
• Unsichtbare Geschäftslogik: Wichtige Regeln stecken in Controllern, Datenbank-Triggern, Cronjobs, Tabellenkalkulationen oder dem Erfahrungswissen einzelner Personen.
• Fehlende Änderbarkeit: Schon kleine Anpassungen berühren viele Module, weil Zuständigkeiten, Datenzugriffe und Seiteneffekte eng gekoppelt sind.
• Schwache Testbarkeit: Das entscheidende Verhalten lässt sich weder automatisiert prüfen noch in einer realistischen Testumgebung reproduzieren.
• Fragiler Betrieb: Deployments, Rücknahmen, Datenkorrekturen und Störungsdiagnosen hängen von manuellen Schritten ab, die nur wenige Menschen kennen.
• Fehlende Beobachtbarkeit: Logs, technische Metriken und fachliche Kontrollsummen reichen nicht aus, um nach einer Änderung korrektes Verhalten nachzuweisen.

Eine ältere PHP-Anwendung mit guter Testabdeckung, klaren Modulgrenzen, reproduzierbaren Deployments und einem unterstützten Runtime-Pfad kann deutlich risikoärmer sein als ein junges, aber eng gekoppeltes System. Die praktische Definition lautet deshalb: Legacy ist die Lücke zwischen der Änderung, die das Geschäft braucht, und der Änderung, die das System sicher zulässt.

Sofort handeln musst du, wenn eine nicht mehr unterstützte Runtime öffentlich erreichbar ist, eine regulatorische oder vertragliche Anforderung auf der aktuellen Basis nicht erfüllbar ist, wiederkehrende Fehler Geldflüsse, Berechtigungen, Fristen oder personenbezogene Daten gefährden, oder nur noch eine Person das System sicher betreiben kann. Risikoreduktion heißt dann aber nicht automatisch Ersatz: Ein Runtime-Upgrade, ein isolierender Sicherheitsbaustein oder zusätzliche Beobachtbarkeit kann der richtige erste Schritt sein.

Verhalten sichern, bevor Code ersetzt wird

Michael Feathers verwendet Charakterisierungstests, um das tatsächliche Verhalten eines Systems zu dokumentieren, nicht das Verhalten, das man sich von ihm wünscht. Sichere damit zuerst die Pfade mit der größten Schadenswirkung ab:

• Geldbeträge, Rechnungen, Rabatte, Steuern und andere Berechnungen
• Identitäten, Rollen, Berechtigungen und Mandantengrenzen
• Statuswechsel und Prozesse, die nicht beliebig wiederholt werden dürfen
• Datenimporte, Exporte und externe API-Aufrufe
• Fristgebundene Jobs und zeitabhängige Regeln
• Manuelle Korrektur- und Wiederanlaufpfade

Davor steht eine Inventur: Laufzeit und Deployment-Kette, Abhängigkeiten inklusive PHP-Erweiterungen, führende Datenquellen, Integrationen mit ihrem Verhalten bei verspäteten oder doppelten Nachrichten, und die Geschäftsregeln, die nur im Erfahrungswissen einzelner Personen stecken. Genau die Fälle, die „normalerweise nicht passieren“, werden in einer Neuentwicklung übersehen.

Logs und Metriken ergänzen die Tests. Fehlerrate, Latenz und Jobabbrüche zeigen die Betriebsqualität; fachliche Kontrollen wie Datensatzzahlen, Summen oder Statusverteilungen zeigen, ob zwei Implementierungen dasselbe Ergebnis erzeugen. Bei browserseitiger Performance müssen Labormessung und Felddaten getrennt bleiben, und die Messmethode braucht ein Datum. Unser Beitrag dazu, was ein Lighthouse-Wert von 100 belegt und was nicht, erklärt diese Grenze.

Refactoring: wenn die Basis noch trägt

Refactoring verbessert nach Martin Fowlers Definition die innere Struktur bestehenden Codes, ohne dessen beobachtbares Verhalten zu verändern. Es ist meistens die beste Option, wenn die vorhandene Geschäftslogik wertvoll, die technische Basis grundsätzlich tragfähig und das System ausreichend testbar ist. Es scheitert selten an der Technik, sondern am fehlenden Fokus: Wer nebenbei ein neues Framework, ein neues Datenmodell und neue Produktfunktionen einführt, kann die Ursache eines Fehlers kaum noch eingrenzen.

Strangler Fig: wenn eine Fähigkeit herausgelöst werden muss

Strangler Fig baut ausgewählte Fähigkeiten neu und lässt alten und neuen Teil während einer Übergangszeit nebeneinander arbeiten, bis der alte Pfad für den betreffenden Umfang nicht mehr gebraucht wird. Das passt, wenn sich Geschäftsfähigkeiten sinnvoll abgrenzen lassen und das System während der Veränderung weiterlaufen muss. Gemeinsam genutzte Datenbanken, verteilte Transaktionen und versteckte Seiteneffekte können eine saubere Trennung aber verhindern. Der Nutzen entsteht durch die bessere fachliche Grenze, nicht durch die Zahl der Deployments, ein herausgelöstes Modul darf also zunächst auch innerhalb einer modularisierten Anwendung entstehen. Lege Exit-Kriterien für den Altpfad fest, sonst wird die Übergangsbrücke zur nächsten Legacy-Schicht.

Rewrite: nur mit gesichertem Verhalten

Ein Rewrite ist gerechtfertigt, wenn die vorhandene Basis eine sichere Weiterentwicklung strukturell verhindert und sich das nicht wirtschaftlich in überschaubaren Schritten beseitigen lässt. Die Schwelle muss hoch sein, weil ein Rewrite zwei Unsicherheiten kombiniert: Das Team baut ein neues System und rekonstruiert gleichzeitig, was das alte wirklich leistet. Werde misstrauisch, wenn das Ziel vor allem „alte Technologie entfernen“ lautet, wenn die neue Lösung erst nach vollständiger Fertigstellung von echten Nutzern geprüft werden soll, wenn Datenmigration und Integrationen als spätere Umsetzungsdetails gelten oder wenn es weder Abbruchkriterien noch einen Plan für unabhängig nutzbare Teilergebnisse gibt.

Welche Option zu welcher Ausgangslage passt

Die Matrix ist kein Punktesystem. Sie macht sichtbar, welche Annahmen eine Option tragen und wo ein einzelnes Ausschlusskriterium wichtiger sein kann als mehrere positive Signale.

Oft entsteht kein reines Ergebnis. Ein Programm kann zuerst die PHP-Laufzeit anheben, dann einen gut verstandenen Kern refaktorieren und eine einzelne, stark veränderliche Fähigkeit per Strangler Fig herauslösen. Ein gemischter Weg ist sinnvoll, wenn er Risiken trennt. Er ist problematisch, wenn er nur drei unklare Projekte gleichzeitig startet.

Das Runtime-Upgrade ist ein eigenes Arbeitspaket

Ein Versionssprung sollte nicht beiläufig in einem Architekturumbau verschwinden. Die offizielle PHP-Dokumentation stellt für jeden Versionswechsel einen Migrationsleitfaden bereit. Arbeite die Übergänge einzeln ab, statt mehrere Generationen von Änderungen in einem undurchsichtigen Fehlersuchraum zu vermischen. Die Zielversion wählst du dabei nicht nach dem höchsten Versionswert, sondern nach offiziellem Supportstatus und Passung zu Framework, Paketen, Erweiterungen und Betriebsumgebung: Wer heute auf 8.2 oder 8.3 modernisiert, braucht bereits eine Perspektive für den nächsten Schritt.

Den Plattformnachweis musst du in der tatsächlichen Zielumgebung führen. composer check-platform-reqs prüft die real vorhandene PHP-Laufzeit und die Plattformanforderungen der installierten Pakete und ignoriert dabei bewusst eine gesetzte config.platform-Simulation. config.platform kann bei der Abhängigkeitsauflösung ein Ziel nachbilden, beweist aber nicht, dass dieses Ziel die benötigte Runtime, Erweiterungen und Bibliotheken wirklich bereitstellt, und --ignore-platform-reqs unterdrückt die Anforderungen sogar absichtlich. Ein erfolgreicher Installationslauf mit einer dieser Abkürzungen ist keine Produktionsfreigabe.

Rollout, Rückweg und Übergabe

Vor jeder Auslieferung muss feststehen:

• Welche technische und fachliche Kennzahl zeigt, dass der Abschnitt korrekt arbeitet?
• Wer beobachtet die Auslieferung und wer darf bei einer Abweichung entscheiden?
• Welche Datenänderungen sind rückwärtskompatibel, welche nicht?
• Wie wird verhindert, dass alte und neue Verarbeitung denselben zustandsändernden Vorgang doppelt ausführen?
• Bis zu welchem Punkt kann auf den alten Pfad zurückgeschaltet werden?
• Wie werden während einer Rücknahme entstandene Daten abgeglichen?

Ein Backup allein ist kein Rücknahmeplan. Fowlers Beschreibung von Blue-Green Deployment macht die Einschränkung konkret: Eine schnelle Rückschaltung des Datenverkehrs setzt voraus, dass die Datenbank mit der alten Anwendungsversion kompatibel bleibt. Nachrichten, Dateien, Benachrichtigungen und Seiteneffekte bei Dritten brauchen eigene Abgleichs- oder Wiederherstellungsverfahren. Ändern sich öffentliche URLs oder sichtbare Nutzerwege, gehören Weiterleitungen, Canonicals, interne Links und Nachbeobachtung ebenfalls in den Rollout. Unser Leitfaden zum Website-Relaunch ohne Ranking-Verlust beschreibt diesen webseitigen Teil genauer.

Am Ende muss das übernehmende Team nicht nur den Code verstehen, sondern auch die Entscheidungen dahinter: Architektur, Datenverantwortung, Deployment- und Wiederanlaufwege, Alarmierungsgrenzen und die noch vorhandene Übergangsarchitektur. Prüfe die Dokumentation an einer realen Aufgabe: Kann das Team selbst ausliefern, einen Fehler eingrenzen und einen sicheren Rückweg ausführen? Auf unserer Seite verbindet die PHP- und Laravel-Entwicklung diese Tiefe mit einem realistischen Upgrade-Pfad. Wenn Produkt, Daten, Integrationen und Betrieb gemeinsam neu geordnet werden müssen, ist unsere individuelle Softwareentwicklung der breitere Rahmen.