Ihre Anwendung läuft. Sie verarbeitet Bestellungen, verwaltet Kundendaten, rechnet ab. Seit Jahren, zuverlässig, Tag für Tag. Und trotzdem steht in Ihrem Server-Log oder im Bericht Ihres Dienstleisters ein Satz, der sich wie ein Vorwurf liest: PHP 7.4 hat das End of Life erreicht. Bevor Sie jetzt an eine teure Neuentwicklung denken, sortieren wir, was das wirklich bedeutet und was nicht.
Was heißt PHP 7.4 End of Life konkret?
PHP 7.4 End of Life bedeutet, dass die PHP-Entwickler keine Updates mehr für diese Version veröffentlichen, auch keine Sicherheitspatches. Der aktive Support endete am 28. November 2021, der Sicherheitssupport am 28. November 2022. Seitdem ist PHP 7.4 offiziell tot.
Wichtig ist der Unterschied zwischen zwei Phasen. In der Phase des aktiven Supports werden Bugs und Sicherheitslücken behoben. In der anschließenden, meist einjährigen Phase des Sicherheitssupports gibt es nur noch Patches für kritische Sicherheitsprobleme. Danach ist Schluss. Für PHP 7.4 ist dieses "Danach" seit Ende 2022 der Zustand. Jede seither entdeckte Lücke im PHP-Kern bleibt in Ihrer Anwendung offen, dauerhaft.
Warum ist eine EOL-Version ein echtes Sicherheitsrisiko?
Eine PHP-Version ohne Sicherheitssupport ist ein bekanntes, öffentlich dokumentiertes Angriffsziel. Sobald eine Schwachstelle im PHP-Interpreter gemeldet wird, ist sie für alle einsehbar, aber für Ihre 7.4-Installation gibt es keinen Fix mehr.
Das betrifft nicht nur den PHP-Kern selbst. Der Effekt zieht sich durch Ihren gesamten Stack:
- Frameworks: Aktuelle Symfony- und Laravel-Versionen setzen längst PHP 8.1 oder höher voraus. Auf 7.4 bleiben Sie auf alten Framework-Ständen festgenagelt, die selbst kaum noch Sicherheitsupdates bekommen.
- Composer-Abhängigkeiten: Viele Bibliotheken veröffentlichen neue, gepatchte Versionen nur noch für aktuelle PHP-Versionen. Ihr
composer updateläuft irgendwann ins Leere. - Umgebung: Betriebssysteme und Hosting-Provider entfernen alte PHP-Pakete aus ihren Repositories. Wenn Ihr Server neu aufgesetzt werden muss, kann die Beschaffung einer lauffähigen 7.4-Umgebung selbst zum Problem werden.
Dazu kommt der geschäftliche Aspekt. Wer Kartenzahlungen abwickelt, muss PCI-DSS einhalten, und dort gilt eine nicht mehr unterstützte Softwarekomponente als Verstoß. Auch bei DSGVO-relevanten Daten wird der "Stand der Technik" schwer zu argumentieren, wenn die Laufzeitumgebung seit Jahren keine Patches mehr erhält.
Ist Ihr laufendes System jetzt wertlos?
Nein. Und das ist der Punkt, an dem viele Diskussionen in die falsche Richtung kippen. Ein System, das seit Jahren stabil im Produktivbetrieb läuft, ist kein technischer Schrott. Es ist der lebende Beweis, dass Ihre Fachlogik funktioniert.
Genau hier lohnt eine nüchterne Unterscheidung. Das eigentliche Problem einer alten PHP-Anwendung ist fast nie die Fachlogik. Die Berechnung Ihrer Staffelrabatte, die Logik Ihrer Rechnungsnummern, die Abbildung Ihrer Lagerprozesse: Das steckt oft voller Wissen, das über Jahre gewachsen und in vielen Detailfällen erprobt ist. Was veraltet, ist der Code drumherum, die Syntax, die Framework-Anbindung, die Datenbankschicht. Und das ist reparabel.
Warum ist Neuentwicklung meist die teuerste Option?
Eine komplette Neuentwicklung wirkt verlockend sauber, ist in der Praxis aber oft der teuerste und riskanteste Weg. Der Grund: Sie werfen mit dem alten Code auch das erprobte Verhalten weg und müssen jede fachliche Sonderregel neu entdecken, die sich über Jahre angesammelt hat.
Diese Sonderregeln sind selten dokumentiert. Sie leben im Code, in genau den Verzweigungen, die "damals wegen dieses einen Kunden" eingebaut wurden. Bei einer Neuentwicklung fallen sie zuerst durchs Raster und tauchen dann als Produktionsfehler wieder auf, oft Monate nach dem Go-live. In der Zwischenzeit müssen zwei Systeme parallel gepflegt werden. Eine schrittweise Migration hält dagegen das erprobte Verhalten am Leben und tauscht nur das Fundament aus.
Wie sieht ein realistischer Weg von PHP 7.4 aus?
Der pragmatische Weg ist eine schrittweise Migration statt eines großen Bruchs. In der Praxis hat sich diese Reihenfolge bewährt:
- Bestandsaufnahme: Welche PHP-Version läuft wo, welche Frameworks und Composer-Pakete sind im Einsatz, wo liegen die riskanten Stellen? Ohne dieses Bild ist jede Planung geraten.
- Sicherheitsnetz spannen: Automatisierte Tests für die kritischen Fachabläufe, zumindest für Rechnungsstellung, Zahlung und Datenexport. Diese Tests sind Ihre Absicherung, dass die Migration das Verhalten nicht verändert.
- Inkrementell hochziehen: Erst von 7.4 auf 8.1, dann weiter Richtung 8.3 oder 8.4. Werkzeuge wie Rector automatisieren einen großen Teil der Syntaxanpassungen, etwa bei Typdeklarationen oder entfernten Funktionen.
- Frameworks nachziehen: Symfony und Laravel jeweils Version für Version, nicht in einem Sprung. Jeder Schritt bleibt so überschaubar und einzeln testbar.
Der entscheidende Vorteil dieses Vorgehens: Nach jedem Schritt läuft Ihr System wieder vollständig. Sie sind nie in einem monatelangen Zustand, in dem nichts funktioniert. Und Sie behalten das, was wirklich wertvoll ist, nämlich Ihre über Jahre erprobte Fachlogik.
Was sollten Sie jetzt zuerst tun?
Verschaffen Sie sich zuerst Klarheit über Ihre Zielversion und den Zeithorizont. Ein kurzer Blick auf die EOL-Daten der aktuellen PHP-Versionen zeigt, wie viel Luft Sie beim Sprungziel haben: PHP 8.1 verliert seinen Sicherheitssupport Ende 2025, PHP 8.2 Ende 2026, PHP 8.3 und 8.4 reichen entsprechend weiter. Wer heute migriert, sollte mindestens auf 8.3 zielen, um nicht in zwei Jahren erneut unter Zeitdruck zu geraten.
Ein ehrlicher Praxis-Tipp: Migrieren Sie nicht ins Blaue. Schreiben Sie zuerst Tests für die drei, vier Abläufe, deren Ausfall Sie wirklich Geld oder Vertrauen kosten würde. Dieser eine Tag Vorarbeit verhindert die teuren Überraschungen im Live-Betrieb.
Wenn Sie vor genau dieser Ausgangslage stehen, ein laufendes 7.4-System, das Sie sicher und ohne Neuentwicklung ins Heute bringen wollen, ist das die Art von Aufgabe, bei der ich mit LegacyWerk unterstütze.
