PHP Migration: Legacy-Anwendungen vor dem Supportende modernisieren

Eine PHP-Migration steht selten im Jahresplan. Meist kommt sie mit einem Anlass: Der Entwickler, der die Anwendung gebaut hat, ist nicht mehr im Haus, oder für die eingesetzte PHP-Version endet der Sicherheitssupport. Dann stellt sich die Frage, was mit gewachsenem PHP Legacy Code geschehen soll und welcher Weg den Betrieb am wenigsten stört.
Ein Mann im Freizeit-Look steht auf einem großen Felsen und blickt über die Wolken in den Sonnenaufgang. Ein Symbolbild für PHP-Legacy-Modernisierung.
© bilanol

PHP End of Life: Wann ein Altsystem zum Risiko wird

Laut W3Techs laufen 35,9 Prozent aller Websites mit PHP noch auf Version 7 oder älter, also auf Versionen ohne Sicherheitsupdates (Stand September 2026).

Eine PHP-Migration ist die Überführung einer bestehenden PHP-Anwendung auf eine unterstützte PHP-Version, ein aktuelles Framework oder eine neue Architektur. Ziel ist, dass die Anwendung wieder Sicherheitsupdates erhält und wartbar wird, ohne dass Daten, Schnittstellen oder Geschäftsregeln verloren gehen. Je nach Zustand des Codes reicht der Weg vom schrittweisen Umbau bis zur vollständigen Neuentwicklung.

Das PHP End of Life folgt für jede Version einem festen Plan. PHP 7.4 erhielt im November 2022 das letzte Update, PHP 8.0 im November 2023, PHP 8.1 im Dezember 2025. PHP 8.2 End of Life ist der 31. Dezember 2026, PHP 8.3 folgt Ende 2027, PHP 8.4 Ende 2028. Nach dem PHP End of Life bleibt jede neu bekannte Lücke offen. Updates für Laufzeit und Framework gehören in den laufenden Betrieb, etwa in einen Wartungsvertrag.

Verwaiste Frameworks im PHP Legacy Code

Neben der Laufzeit altert auch das Framework. Stellt das Projekt die Pflege ein, hilft die neueste PHP-Version wenig, weil der Framework-Code keine Korrekturen mehr erhält. Häufig betroffen sind:

❗ Zend Framework 1 seit September 2016 ohne Support
❗ Zend Framework 2 seit März 2018 ohne Support
❗ CakePHP 2 seit Juni 2021 ohne Support
❗ Yii 1.1 mit Sicherheitsupdates nur bis Ende 2026
❗ CodeIgniter 3, dessen Nachfolger eine Neuentwicklung ist
❗ TYPO3 7 und 8 ohne kostenlosen Support
❗ eigene Frameworks einzelner Entwickler

Beim Zend Framework ist Laminas der offizielle Nachfolger, der Umstieg bleibt trotzdem ein Umbau der PHP-Anwendung. Bei eigenen Frameworks liegt das Risiko im Wissen: Verlässt die Person, die es gebaut hat, das Unternehmen, kann niemand mehr Änderungen sicher einschätzen.

Sicherheitslücken im PHP Legacy Code

Alter PHP Legacy Code enthält oft Schwachstellen, die aktuelle Frameworks von vornherein verhindern. Datenbankabfragen entstehen aus Texteingaben, Ausgaben landen ungefiltert im HTML, und Formulare haben keinen Schutz gegen untergeschobene Anfragen. Solche Lücken schließt kein Update der PHP-Version, weil sie in der Anwendung selbst liegen. Wo sie stecken, zeigt erst die Bestandsaufnahme vor der Übernahme.

Drei Wege der PHP-Migration

Für eine PHP-Migration gibt es drei Wege: den Bestand schrittweise sanieren, ein neues System neben dem alten wachsen lassen oder die Anwendung neu entwickeln. Welcher passt, entscheiden der Zustand des Codes, die Frage, ob der Betrieb unterbrochen werden darf, und das Budget. Die Abwägung folgt denselben Kriterien wie beim Modernisieren von Legacy-Software allgemein, bei PHP kommen das PHP End of Life jeder Version und die Framework-Wahl hinzu.

PHP Refactoring: den Bestand schrittweise sanieren

Beim PHP Refactoring bleibt die Architektur bestehen, während der Code Stück für Stück verbessert wird. Dieser Weg passt, wenn eine Version wie PHP 8.1 ihr PHP End of Life gerade erreicht hat und das Framework noch gepflegt wird. Auch eine PHP-8-Migration von Version 7 aus gelingt oft so, etwa bei einer älteren Laravel-Anwendung. Typische Arbeitsschritte sind:

Für Legacy Code Refactoring gilt eine feste Reihenfolge: Erst entstehen die Tests, dann die Änderungen. Sonst bleibt unbemerkt, was eine Änderung an anderer Stelle beschädigt. Die Migration einer PHP-Anwendung auf diesem Weg läuft über mehrere Monate neben dem Betrieb.

Strangler Fig Pattern: Neubau neben dem Altsystem

Das Strangler Fig Pattern ist nach der Würgefeige benannt, die ihren Wirtsbaum umwächst, bis sie ihn ersetzt. Neue Funktionen entstehen in einer modernen Anwendung, die neben dem Altsystem läuft und ihm Modul für Modul Arbeit abnimmt. Am Ende wird das alte System abgeschaltet, ohne dass es je einen Stichtag für die PHP-Migration gab. Der Weg passt, wenn die Anwendung keinen Ausfall verträgt.

Umsetzung mit vorgeschaltetem Proxy

Technisch steuert ein Proxy wie nginx oder Traefik, welche Adressen zum alten und welche zum neuen System führen. Für die Nutzer bleibt die Adresse gleich. Neue Funktionen entstehen nur noch im neuen System, bestehende Module ziehen nach ihrem Geschäftswert nacheinander um. Nach dem letzten Modul wird das Altsystem abgeschaltet.

Das Strangler Fig Pattern kostet mehr als ein Umbau im Bestand. Es senkt aber das Risiko, weil jeder Schritt einzeln zurückgenommen werden kann.

PHP Rewrite: Neuentwicklung mit Vorlage

Beim PHP Rewrite entsteht die Anwendung neu. Der vorhandene PHP Legacy Code dient als Beschreibung dessen, was sie können muss, übernommen wird er nicht. Diese Form der PHP-Migration passt, wenn das Framework keinen Migrationspfad mehr hat und der Code undokumentiert ist.

Risiken der Neuentwicklung

Eine Neuentwicklung ist der teuerste und längste Weg, weil das Altsystem währenddessen weiter gepflegt werden muss. Geschäftsregeln, die nur im alten Code stehen, gehen dabei leicht verloren. Ein PHP Rewrite braucht deshalb einen festen Funktionsumfang, bevor die erste Zeile entsteht.

Ein Legacy-PHP-Projekt übernehmen und modernisieren

Vor der eigentlichen PHP-Migration steht oft ein Wechsel des Dienstleisters. Ein Legacy-PHP-Projekt übernehmen heißt, zuerst den Bestand vollständig zu erfassen. Danach wird das Ziel-Framework gewählt, und schließlich werden Daten und Schnittstellen so geplant, dass angebundene Systeme während der Umstellung weiterlaufen.

Bestandsaufnahme vor der Übernahme

Eine Übernahme scheitert selten am Code, öfter an fehlenden Unterlagen. Bevor sich PHP Legacy modernisieren lässt, muss feststehen, was übernommen wird und wer darüber verfügt. Dazu gehören:

Fehlt ein Punkt, wird er vor der PHP-Migration nachgeholt. Das anschließende Code-Audit zeigt, welcher der drei Wege zum vorhandenen PHP Legacy Code passt. Was bis dahin am Altsystem anfällt, übernimmt die laufende PHP-Wartung.

Laravel oder Symfony: Welches Framework passt?

Als Ziel kommen vor allem zwei Frameworks in Frage. Laravel passt zu Anwendungen mit klaren Abläufen aus Erfassen, Anzeigen und Bearbeiten. Seine Datenbankschicht Eloquent spricht bestehende Tabellen ohne Umbau an, sodass Oberfläche und Logik zuerst umziehen und das Schema später folgt.

Symfony passt zu umfangreichen Fachmodellen und langen Laufzeiten, weil seine Versionen mit Langzeitsupport planbar sind. Bei einer CakePHP-Migration ist zu prüfen, ob der Sprung auf CakePHP 5 oder der Wechsel zu Laravel weniger Aufwand bedeutet. Eine Zend-Framework-Migration führt entweder zu Laminas oder zu einem Wechsel auf Symfony.

Daten und Schnittstellen stabil halten

Die schwierigste Phase einer Legacy-Migration ist selten der neue Code, sondern die Übernahme der Daten. Gewachsene Datenbanken haben fehlende Fremdschlüssel, gemischte Datentypen und Logik in gespeicherten Prozeduren. Migrationsskripte müssen umkehrbar und prüfbar sein, mit einem Abgleich von Zeilenzahlen und Prüfsummen. Diese Prüfschritte gehören zu jeder geordneten Datenmigration.

Schnittstellen, die Apps oder Partnersysteme nutzen, bleiben bei der Migration von PHP-Anwendungen unverändert. Das neue System bedient dieselben Endpunkte mit denselben Antworten. Erst wenn alle Nutzer umgestellt haben, wird die alte Version abgeschaltet.

Was eine PHP-Migration kostet

Die Kosten einer PHP-Migration hängen am gewählten Weg und am Umfang des Codes. Der Umbau im Bestand ist am günstigsten, die Neuentwicklung am teuersten. Die Tabelle nennt grobe Richtwerte in Stunden für Analyse, Entwicklung, Tests und Inbetriebnahme, ohne Projektsteuerung und Parallelbetrieb.

Wegbis 10.000 Zeilenüber 100.000 Zeilen
Refactoring80 bis 160 Stunden800 bis 1.500 Stunden
Strangler Fig200 bis 400 Stunden1.500 bis 3.000 Stunden
Rewrite300 bis 500 Stundenab 2.000 Stunden

Für die Migration einer PHP-Anwendung mit rund 50.000 Zeilen liegen die Werte bei 300 bis 600 Stunden für den Umbau, 600 bis 1.200 für das Strangler Fig Pattern und 800 bis 1.800 für die Neuentwicklung.

Wann rechnet sich die Modernisierung?

Als Faustregel lohnt es sich, eine Legacy-Anwendung modernisieren zu lassen, wenn die laufenden Kosten des Altsystems die Kosten der Umstellung innerhalb von zwei bis drei Jahren übersteigen würden. Zu den laufenden Kosten zählen auch Funktionen, die wegen des alten Codes nicht gebaut werden, und die Suche nach Fachleuten für Frameworks, die kaum jemand beherrscht. Eine belastbare Zahl liefert erst die Aufwandsschätzung nach dem Audit.

Was das Aufschieben kostet

Wer die PHP-Migration verschiebt, spart kurzfristig und zahlt später. Mit jedem Jahr wächst der Abstand zur aktuellen Version und damit der Aufwand für den Umstieg. In Audits nach ISO/IEC 27001 und in Sicherheitsfragebögen von Kunden ist ein System nach dem PHP End of Life ein Befund, der erklärt werden muss.

TenMedia übernimmt PHP-Anwendungen auch dann, wenn andere sie gebaut haben, und beginnt mit einem Code-Audit, aus dem die Empfehlung für einen der drei Wege folgt. Bei einer Bestellverwaltung für die Mediendigitalisierung hat TenMedia das System im laufenden Betrieb übernommen, modernisiert und in eine hochverfügbare Umgebung migriert. Entwickelt wird im eigenen Team in Berlin, der Quellcode wird unverschlüsselt übergeben. Nach der PHP-Migration geht die Anwendung in einen regulären Wartungsvertrag über.

FAQs

Was passiert mit bestehenden Nutzerkonten und Passwörtern? keyboard_arrow_down keyboard_arrow_up
Konten werden übernommen, Passwörter bleiben dabei unlesbar. Moderne Frameworks erkennen ältere Hash-Verfahren und schreiben den gespeicherten Wert beim nächsten erfolgreichen Login automatisch auf das aktuelle Verfahren um. Nur bei sehr alten oder selbst gebauten Verfahren ist eine Neuvergabe unvermeidlich, dann mit Ankündigung an alle Betroffenen.
Woran lässt sich der Zustand einer Altanwendung vor Projektbeginn ablesen? keyboard_arrow_down keyboard_arrow_up
Vier Kennzahlen geben ohne tiefe Analyse ein belastbares Bild. Die Anzahl der Abhängigkeiten mit bekannten Schwachstellen zeigt die Sicherheitslage und lässt sich mit einem einzigen Befehl ermitteln. Der Anteil des Codes, der von automatischen Tests berührt wird, zeigt, wie riskant jede Änderung ist. Das Datum des letzten Releases der eingesetzten Bibliotheken zeigt, ob das Umfeld überhaupt noch gepflegt wird. Und die Zahl der Personen, die den Code je verändert haben, zeigt, wie viel Wissen darüber heute noch erreichbar ist. Alle vier lassen sich vor der Angebotseinholung erheben und schützen davor, den Umfang zu unterschätzen.
Wird das Altsystem während der Umstellung weiter betreut? keyboard_arrow_down keyboard_arrow_up
Ja, sonst entsteht während der Umstellung eine Lücke im Betrieb. TenMedia übernimmt auf Wunsch Sicherheitsupdates und Störungsbehebung am Altsystem, bis die neue Anwendung produktiv ist. Dieser Parallelbetrieb wird getrennt kalkuliert und gehört von Anfang an in die Planung einer PHP-Migration.