Am 31. Dezember 2026 bekommt PHP 8.2 sein letztes Sicherheitsupdate. PHP 8.1 hat seins schon seit Anfang des Jahres hinter sich, von 7.4 und älter ganz zu schweigen. Viele Anwendungen, die heute zuverlässig laufen, stehen damit in wenigen Wochen auf einer Plattform, für die neu entdeckte Lücken nicht mehr geschlossen werden.
Das naheliegende Ziel ist PHP 8.5, erschienen im November 2025 und mit Sicherheitsupdates bis Ende 2029. Ob der Weg dorthin ein Wartungstermin oder ein Projekt über mehrere Wochen ist, steht nicht in der Versionsnummer. Es hängt an vier Dingen, die Sie klären sollten, bevor Sie einen Auftrag vergeben.
Wie viel Zeit bleibt Ihnen auf der aktuellen Version?
Die Versionsnummer finden Sie in fünf Minuten heraus, eine Anleitung steht in PHP-Version prüfen. Danach gilt für die Sicherheitsupdates:
- PHP 8.1: seit 31.12.2025 beendet
- PHP 8.2: endet am 31.12.2026
- PHP 8.3: bis 31.12.2027
- PHP 8.4: bis 31.12.2028
- PHP 8.5: bis 31.12.2029
Steht Ihre Anwendung auf 8.2 oder älter, ist das Upgrade für dieses Quartal fällig, nicht für irgendwann. Bei 8.3 haben Sie ein gutes Jahr. Planen sollten Sie trotzdem jetzt, denn die Zeit geht selten für die Umstellung selbst drauf. Sie geht für die Vorbereitung drauf.
Warum nicht 8.4, wenn das bequemer wäre? Weil derselbe Aufwand Ende 2028 wieder ansteht. Den Unterschied zwischen 8.4 und 8.5 merkt man im Code kaum, das teure Stück ist fast immer der Weg bis 8.4. Lässt eine wichtige Abhängigkeit 8.5 noch nicht zu, ist 8.4 eine vernünftige Zwischenstation. Dann sollte das aber als Entscheidung im Plan stehen und nicht als Zufall.
Ist das bei Ihnen ein Versionswechsel oder ein Projekt?
Die eigentliche Umstellung auf dem Server dauert Minuten. Die Vorbereitung kann Wochen dauern, und wovon das abhängt, lässt sich vorher ziemlich genau sagen.
Eher klein wird es, wenn:
- die Anwendung schon auf 8.2 oder 8.3 läuft
- alle Bibliotheken über Composer kommen und in den letzten zwölf Monaten aktualisiert wurden
- das Framework (Symfony, Laravel, Shopware) auf einer gepflegten Version steht
- es automatische Tests gibt, die mindestens Bestellung, Login und Zahlung abdecken
Eher groß wird es, wenn:
- der Startpunkt PHP 7.x oder älter ist, dann führt der Weg über mehrere Stufen, siehe PHP 5.6 auf PHP 8 migrieren
- zentrale Pakete nicht mehr gepflegt werden und ersetzt werden müssen
- das Framework selbst mit muss, weil seine alte Version auf neuem PHP nicht läuft
- es keine Tests gibt und niemand sicher sagen kann, welche Abläufe geschäftskritisch sind
- Cronjobs, Importskripte oder Schnittstellen existieren, die außer dem Server niemand kennt
Die Abhängigkeiten sind in der Praxis der häufigste Grund, warum ein Upgrade teurer wird als gedacht. Ein Paket, das PHP 8.5 nicht unterstützt, blockiert das ganze Vorhaben, egal wie sauber der eigene Code ist. Wie Sie das vorab einschätzen, habe ich in Haben Sie Ihre Abhängigkeiten im Griff? beschrieben.
Woran erkennen Sie ein Angebot, das den Betrieb nicht gefährdet?
Ein PHP-Upgrade scheitert selten an PHP. Es scheitert an einem übersehenen Cronjob, an einer Erweiterung, die auf dem neuen Server fehlt, oder an einer Warnung, die jemand stummgeschaltet statt behoben hat. Ob ein Dienstleister das im Griff hat, sehen Sie am Angebot. Darin sollte stehen:
- eine Bestandsaufnahme vor der ersten Codeänderung: Version, Framework, Pakete, PHP-Erweiterungen, Cronjobs, Schnittstellen, Umgebungsvariablen, Deployment
- eine Liste der Abhängigkeiten mit Einordnung: aktualisieren, vorerst behalten, ersetzen
- Stufen statt eines Sprungs, wenn der Abstand groß ist, und jede Stufe einzeln auslieferbar
- Tests für die Abläufe, an denen Umsatz hängt, bevor kritischer Code angefasst wird. Volle Testabdeckung ist dafür nicht nötig, mehr dazu in Testabdeckung bei PHP-Migrationen
- eine Testumgebung, die der Produktion entspricht, mit denselben Erweiterungen, Cronjobs und Anbindungen. Ein Entwickler-Laptop zählt nicht
- automatische Prüfungen bei jeder Änderung, also Tests und statische Analyse wie PHPStan
- ein Abnahmetest der echten Abläufe durch jemanden, der das Geschäft kennt, inklusive Fehlerfällen wie einem Zahlungsanbieter, der nicht antwortet
- ein Rückweg, der vor der Umstellung geprüft wurde, und eine Person, die über den Rückweg entscheidet. Wie das aussieht, steht in Rollback-Strategie für PHP-Migrationen
- Überwachung nach der Umstellung: Fehler, Warnungen, 5xx-Antworten, Laufzeiten, fehlgeschlagene Jobs
Hellhörig werden sollten Sie, wenn ein Angebot nur "Umstellung auf PHP 8.5" und eine Pauschale enthält, ohne dass vorher jemand in den Code geschaut hat. Dann ist der Preis geraten. Geraten ist er auch, wenn er auffällig niedrig ist, weil Testumgebung und Rückweg fehlen.
Was gehört nicht in dieses Projekt?
Der Wechsel auf eine neue PHP-Version lädt dazu ein, gleich mehr zu erledigen: das neue Feature, das seit Monaten wartet, ein Umbau der Datenbank, vielleicht der Wechsel auf ein anderes Framework. Ich rate davon ab. Wenn nach der Umstellung etwas hakt, muss klar sein, dass es am Upgrade liegt und nicht an fünf anderen Änderungen aus derselben Woche.
Ein gutes Upgrade ist am Tag der Umstellung langweilig. Neue Version ausliefern, Laufzeit umschalten, Hintergrundprozesse neu starten, Kerntests ausführen, Überwachung im Blick behalten. Erst wenn das ein paar Tage ruhig läuft, kommt das Nächste dran.
Danach haben Sie mehr als eine neue Versionsnummer. Pakete lassen sich wieder aktualisieren, statische Analyse findet mehr Fehler, und das nächste Upgrade ist Routine statt Projekt. Neu schreiben mussten Sie dafür nichts. Die Fachlogik, die seit Jahren funktioniert, bleibt, wie sie ist.
Ob Ihr Upgrade auf 8.5 ein Termin oder ein Projekt wird, lässt sich am Code ablesen, nicht an der Versionsnummer. Wenn Sie auf 8.2 oder älter stehen, wäre jetzt der Zeitpunkt, das herauszufinden. Ende Dezember ist es knapp.
