PHP 7.4 End-of-Life: Warum Warten teuer wird

Wer heute noch produktiv auf PHP 7.4 läuft, arbeitet seit dem 28. November 2022 ohne offizielle Sicherheitsupdates. Das ist kein Risiko für irgendwann. Es ist längst eingetreten. Trotzdem stoßen wir in Kundenprojekten regelmäßig auf gewachsene Anwendungen, die genau dort stehengeblieben sind, oft mit dem Satz "läuft doch".

Läuft es auch. Bis es das nicht mehr tut. Und dann meist zum ungünstigsten Zeitpunkt.

Was End-of-Life bei PHP wirklich heißt

PHP 7.4 hatte den damals üblichen Lebenszyklus: zwei Jahre aktive Pflege mit Bugfixes, danach ein Jahr, in dem nur noch kritische Sicherheitslücken geschlossen wurden. Dieses letzte Jahr lief Ende November 2022 aus. (Neuere Versionen ab PHP 8.1 haben inzwischen einen längeren Zyklus von vier Jahren, aber das hilft einem 7.4-Projekt nicht weiter.)

Praktisch heißt das: Wird morgen eine schwere Lücke im PHP-Kern oder in einer der mitgelieferten Erweiterungen gefunden, gibt es vom PHP-Projekt keinen Patch mehr. Manche Linux-Distributionen und Managed-Hoster liefern über eigene Backports noch eine Weile Sicherheitspatches für alte PHP-Versionen. Das verschafft Ihnen Zeit, aber keine Zukunft: Vom aktuellen PHP-Ökosystem sind Sie trotzdem abgeschnitten, und irgendwann endet auch dieser Backport-Support. Verlassen sollte man sich darauf nicht.

Wo das Geld tatsächlich verloren geht

Das Argument "läuft doch" blendet aus, dass eine veraltete Version an mehreren Stellen gleichzeitig kostet, nur eben nicht sofort sichtbar.

Beim Thema Haftung wird es schnell konkret. Kommt es zu einem Datenleck über eine bekannte, aber ungepatchte Lücke, steht die DSGVO-Frage nach dem Stand der Technik im Raum. Eine seit Jahren abgekündigte PHP-Version lässt sich vor einer Aufsichtsbehörde schwer als angemessene Schutzmaßnahme verkaufen.

Dann das Hosting. Immer mehr Managed-Hoster schalten alte PHP-Interpreter ab, teils mit wenigen Wochen Vorlauf. Wir haben mehr als einen Kunden erlebt, der von so einer Mail überrascht wurde und dann unter Zeitdruck migrieren musste, statt in Ruhe zu planen. Das ist die teuerste Variante.

Das Ökosystem zieht ebenfalls davon. Neue Versionen von Composer-Paketen und Frameworks setzen inzwischen PHP 8.1 oder höher voraus. Wer auf 7.4 festhängt, kann seine Abhängigkeiten nicht mehr aktualisieren und sammelt still weitere veraltete Bibliotheken an. Das Problem wächst also, während man nichts tut.

Und schließlich die Leistung. PHP 8 ist durch den JIT-Compiler und viele kleine Optimierungen spürbar schneller als 7.4. Auf derselben Hardware bedeutet das entweder niedrigere Serverkosten oder mehr Luft bei Lastspitzen. Diesen Vorteil verschenkt man mit jeder Woche.

Woran Sie erkennen, dass es dringend wird

Besonders eilig ist es, wenn einer dieser Punkte auf Sie zutrifft:

• Die Anwendung verarbeitet personenbezogene Daten oder Zahlungen.
• Ihr Hoster hat die Abschaltung alter PHP-Versionen bereits angekündigt.
• Sicherheitsrelevante Composer-Updates lassen sich nicht mehr einspielen, weil sie PHP 8 verlangen.
• Es gibt keine Tests, die ein Upgrade absichern würden.

Der letzte Punkt klingt widersprüchlich, ist aber der wichtigste. Fehlende Tests machen die Migration nicht überflüssig, sie machen sie riskanter. Deshalb bauen wir bei jeder Migration zuerst eine minimale Testabdeckung für die kritischen Abläufe auf, bevor wir die Version anfassen. Erst das Netz, dann der Sprung.

Muss es gleich PHP 8 sein?

Ja. Ein Zwischenstopp auf PHP 8.0 oder 8.1 bringt nichts, weil auch diese Versionen ihr Support-Ende schon erreicht haben. Sinnvolles Ziel ist eine aktuell gepflegte 8.x-Version.

Und der Sprung von 7.4 dorthin ist gut planbar. Die meisten Breaking Changes betreffen klar umrissene Muster, die sich systematisch aufspüren lassen. Vieles davon läuft heute nicht mehr in Handarbeit: Werkzeuge zur statischen Analyse finden die kritischen Stellen, und Automatisierungs-Tools schreiben einen Großteil der mechanischen Änderungen selbst um. Welche Muster das sind, gehen wir in der PHP-8-Checkliste im Detail durch.

Der ehrliche Rat

PHP 7.4 ist kein "läuft noch", sondern ein aufgeschobenes Risiko mit steigender Rechnung. Der richtige Moment für die Migration ist nicht der Tag, an dem der Hoster abschaltet oder jemand die Lücke findet. Es ist der ruhige Moment davor, mit Plan und Testnetz.

Wenn Sie nicht einschätzen können, wie groß der Aufwand für Ihr konkretes Projekt ist, schauen wir uns das kostenlos an und nennen Ihnen einen realistischen Rahmen. Das ist ehrlicher, als selbst zu raten.

Weiterführende Quellen

• Unterstützte PHP-Versionen und ihre End-of-Life-Daten auf php.net
• Offizieller Migrationsleitfaden von PHP 7.4 auf 8.0
• Im Ratgeber weiterlesen: PHP 8 Breaking Changes: Die Migrations-Checkliste