Die Mail kommt meistens dienstags. „Wir stellen die Unterstützung für PHP 7.4 zum Datum X ein. Bitte stellen Sie Ihre Anwendung bis dahin auf eine aktuelle Version um.“ Manchmal steht ein Aufpreis für „Extended Support“ darunter, manchmal nur die Frist. Die Anwendung dahinter läuft seit acht, zehn, fünfzehn Jahren. Sie schreibt Rechnungen, verwaltet Aufträge, nimmt Bestellungen an. Und niemand im Haus weiß sicher, was passiert, wenn man im Panel auf „PHP 8.3“ klickt.
Ich bekomme diese Anfrage in genau dieser Form mehrmals im Monat. Hier ist, was ich den Anrufern sage.
Was die Frist tatsächlich bedeutet
PHP 7.4 hat seit dem 28. November 2022 keine Sicherheitsupdates mehr. PHP 8.0 seit November 2023, PHP 8.1 seit Ende 2025. Ihr Hoster hat diese Versionen bis jetzt aus Kulanz weiterbetrieben und hört damit auf, weil er die Betriebssysteme darunter nicht mehr gepatcht bekommt. Die Frist ist also nicht Willkür, sie ist das Ende einer Gnadenfrist, die schon länger lief.
Drei Dinge folgen daraus, und nur eines davon ist die Frist selbst:
- Sicherheit. Jede seit Ende 2022 gefundene Lücke im PHP-Interpreter ist in Ihrer Installation offen. Wer Kartenzahlungen abwickelt, hat damit ein PCI-DSS-Problem. Wer personenbezogene Daten verarbeitet, kann „Stand der Technik“ nicht mehr ernsthaft behaupten. Ihre Cyber-Versicherung liest die Bedingungen im Schadensfall genauer als beim Abschluss.
- Abhängigkeiten. Bibliotheken, Zahlungsanbieter-SDKs, Mail-APIs: Die aktuellen Versionen setzen PHP 8.1 oder höher voraus. Irgendwann stellt ein Zahlungsanbieter seine alte API ab, und dann ist die Frist nicht mehr vom Hoster, sondern vom Umsatz.
- Die Frist. Die ist das kleinste der drei Probleme, aber die einzige mit Datum. Deshalb löst sie das Projekt aus, das die anderen beiden auch lösen.
Was passiert, wenn Sie nichts tun
Der Hoster stellt um oder stellt ab. Im ersten Fall sehen Ihre Kunden eine weiße Seite oder eine Fehlermeldung mit mysql_connect() darin. Im zweiten Fall ist die Anwendung weg, bis jemand sie auf einem anderen Server wieder hochbekommt, was bei einer PHP-7-Anwendung ohne Dokumentation erfahrungsgemäß Tage dauert, nicht Stunden.
Das Szenario, das ich häufiger sehe und das teurer ist: Jemand klickt im Panel auf PHP 8, die Startseite geht, und alle atmen auf. Drei Wochen später fällt auf, dass der Rechnungsexport seither leere Dateien schreibt oder der Nachtimport still abbricht. PHP 8 wandelt viele frühere Warnungen in Abbrüche um und vergleicht Werte strenger. Genau die Sonderfälle, die niemand testet, trifft das zuerst.
Die drei realistischen Optionen
Option A: Umschalten und reparieren, was bricht
Sie stellen die PHP-Version um, sehen, was kaputtgeht, und lassen es reparieren. Klingt pragmatisch, ist es bei kleinen Anwendungen auch.
Woran es scheitert: Sie sehen nur, was laut kaputtgeht. Was leise kaputtgeht, den Vergleich 0 == "abc", der seit PHP 8 anders ausgeht, den Datumsstring, der plötzlich anders geparst wird, die Rundung im Rabatt, finden Sie erst in der Buchhaltung. Bei einer Anwendung, die Geld bewegt, ist das keine Option, sondern ein Glücksspiel mit Ihrem Namen drauf.
Option B: Zeit kaufen
Extended Support beim Hoster, oder ein Umzug zu einem Anbieter, der alte Versionen noch anbietet. Sie gewinnen sechs bis zwölf Monate.
Woran es scheitert: Die Monate vergehen, ohne dass jemand die Migration beauftragt, weil das akute Problem ja gelöst ist. Nach zwölf Monaten steht dieselbe Frist wieder an, die Extended-Support-Gebühr ist gezahlt, und die Anwendung ist ein Jahr älter. Als bewusste Brücke, mit beauftragter Migration im Hintergrund, ist Option B in Ordnung. Als Lösung ist sie die teuerste der drei.
Option C: Migration auf unterstütztes PHP, getestet, mit Festpreis
Eine Kopie der Anwendung, ein Sicherheitsnetz aus Tests um die Abläufe, die Geld kosten, wenn sie brechen, dann die Bruchstellen abarbeiten, Version für Version, bis alles auf PHP 8.3 oder 8.4 grün ist. Umschaltung erst danach, mit Rückweg.
Woran es scheitert: An einem zu großen Auftrag. Wer aus der Frist gleich eine Vollmodernisierung mit neuer Architektur macht, ist in drei Monaten noch nicht fertig, und die Frist war in sechs Wochen. Deshalb heißt mein Paket dafür Minimal-Migration: nur das, was nötig ist, damit das System auf einer unterstützten Version läuft. Aufräumen kann man danach, in Ruhe, wenn man will.
Die Reihenfolge, die ich empfehle
- Heute: Frist notieren und den Hoster anrufen. Fragen Sie nach einer Verlängerung oder nach Extended Support als Puffer. Die meisten Hoster gewähren vier bis acht Wochen, wenn ein Migrationsprojekt läuft. Fragen Sie außerdem, welche PHP-Versionen der Hoster künftig anbietet. Das legt Ihr Ziel fest.
- Diese Woche: Befund beauftragen. Ich lese Code, Datenbank und Deployment, lasse Rector und PHPStan mit den Regeln für die Zielversion laufen und bekomme die vollständige Liste der Bruchstellen. Sie bekommen sie als Dokument, mit Risiko-Einordnung und dem Festpreis für die Migration. Zwei bis drei Werktage.
- Danach: Minimal-Migration. Tests um die kritischen Pfade, Bruchstellen beheben, Abhängigkeiten anheben, Smoke-Tests, Übergabe mit Änderungsprotokoll und einer Anleitung für Ihren Hoster. Zwei bis sechs Wochen, je nach Größe.
- Umschaltung. In einer Randzeit, mit der alten Version als Rückweg für 48 Stunden. Danach ist die Frist erledigt.
- Optional: Werkstatt-Bereitschaft. Damit die nächste PHP-Version kein Projekt mehr ist, sondern ein Termin im Kalender. Monatliche Updates, Monitoring, eine Telefonnummer, die abgenommen wird.
Was Sie für den Befund brauchen
Sie müssen nichts vorbereiten. Ich brauche lesenden Zugriff auf den Quellcode, einen Datenbank-Dump oder das Schema, und die Zugangsdaten zum Hosting-Panel. Wenn Sie nicht wissen, wo der Quellcode liegt, ist das die erste Frage, die ich mit Ihnen kläre, und häufiger der Fall, als Sie denken.
Für wen dieser Weg nicht passt
Wenn die Anwendung ein Vereinsverzeichnis mit drei Seiten ist, ist eine Migration zum Festpreis überdimensioniert. Dann ist Option A mit einem Freelancer für einen Tag die richtige Wahl. Ich sage Ihnen das im kostenlosen Kurz-Check ehrlich, weil ich lieber eine Anfrage ablehne als ein Projekt betreue, das sich für Sie nicht rechnet.
