PHP 8.6 soll am 19. November 2026 erscheinen. Zum Redaktionsschluss dieses Artikels (11. Oktober 2026) liegt der dritte Release Candidate vom 8. Oktober vor, zwei weitere sind angesetzt. Sechs Wochen später, am 31. Dezember 2026, bekommt PHP 8.2 sein letztes Sicherheitsupdate.
Wer eine ältere PHP-Anwendung verantwortet, fragt sich jetzt verständlicherweise, ob man direkt auf 8.6 gehen sollte. Meine Antwort ist meistens: Nutzen Sie 8.6 als Planungspunkt, nicht als Termin. Dieser Artikel zeigt, wie Sie den eigenen Abstand dazu messen und welche Reihenfolge den Betrieb schützt.
Warum PHP 8.6 ein guter Anlass zum Planen ist
Nach der üblichen Regel des PHP-Projekts (zwei Jahre aktive Pflege, danach zwei Jahre Sicherheitsupdates) würde PHP 8.6 bis Ende 2030 mit Sicherheitsupdates versorgt. Offiziell ist das noch nicht, die Tabelle auf php.net führt 8.6 erst nach dem Release. Zum Vergleich:
- PHP 8.1: seit 31.12.2025 ohne Sicherheitsupdates
- PHP 8.2: bis 31.12.2026
- PHP 8.3: bis 31.12.2027
- PHP 8.4: bis 31.12.2028
- PHP 8.5: bis 31.12.2029
Mit 8.6 ist die Richtung der Plattform für die nächsten Jahre bekannt, auch welche alten Funktionen als veraltet markiert werden. Daran lässt sich der eigene Code messen. Daraus folgt keine Pflicht, sofort umzustellen. Für viele Systeme ist 8.4 oder 8.5 das realistische nächste Ziel. Bei geschäftskritischen Anwendungen rate ich ohnehin, die ersten Patch-Releases abzuwarten und vor allem, bis Framework und wichtige Pakete 8.6 offiziell unterstützen.
Der Ausgangspunkt zählt mehr als die Zielversion
Wie aufwendig ein Upgrade wird, hängt an drei Schichten, die man getrennt betrachten sollte:
- Was PHP 8.6 selbst ändert. Das ist überschaubar: vor allem Deprecations, einige neue Exceptions, geänderte Session-Voreinstellungen.
- Was sich seit Ihrer aktuellen Version angesammelt hat. Wer von 7.4 kommt, trägt die Brüche von PHP 8.0 mit, etwa strengere Typprüfungen bei internen Funktionen und geänderte Vergleiche zwischen Zahlen und Strings, dazu alles aus 8.1 bis 8.5. Von PHP 5.x aus sind es noch einmal deutlich mehr Stufen, siehe PHP 5.6 auf PHP 8 migrieren. Das ist nicht die Schuld von 8.6.
- Was an der Anwendung selbst hängt: Framework-Version, ungepflegte Composer-Pakete, PHP-Erweiterungen, Hosting-Vorgaben, Cronjobs, Schnittstellen und Wissen, das nur einzelne Entwickler haben.
Ist der Abstand groß, lohnt es sich, die Kompatibilität stufenweise herzustellen: Code und Tests zuerst gegen eine Zwischenversion laufen lassen, Probleme beheben, dann die nächste Version. Das passiert in der CI oder auf einer Testumgebung. Jede Zwischenversion in Produktion zu bringen ist nicht nötig, eine oder zwei produktive Stationen reichen oft. Container helfen, Umgebungen reproduzierbar zu machen, inkompatiblen Code reparieren sie nicht. Und ein neues Framework bringt seine eigene Migration mit, statt die alte zu ersetzen.
Risiken nach Folgen und Wahrscheinlichkeit ordnen
Eine Liste aller Auffälligkeiten hilft bei der Entscheidung wenig. Nützlicher ist eine Ordnung danach, was im Betrieb passiert, wenn ein Punkt übersehen wird. Ob ein Risiko bei Ihnen schwer wiegt, hängt davon ab, ob Ihre Anwendung die betroffene Funktion überhaupt nutzt. Die Einstufung in der Tabelle gilt also nur unter dieser Bedingung.
| Risikobereich | Belege sammeln | Mögliche Folgen | Empfehlung |
|---|---|---|---|
| Laufzeit und Support | PHP-Version je Server, Support-Ende, Vorgaben des Hosters, Deployment-Weg | keine Sicherheitsupdates, Abschaltung durch den Hoster, Audit-Befund | Zielversion und Termin festlegen, Grenzen des Hostings früh klären |
| Framework, Pakete, Erweiterungen | composer.lock, Ausgabe von composer why-not php 8.6, installierte Erweiterungen, Pflegestatus | ein einzelnes Paket blockiert das ganze Upgrade | je Paket entscheiden: aktualisieren, ersetzen oder vorerst halten |
| Kritische Abläufe ohne Tests | Liste der Abläufe, an denen Umsatz oder Pflichten hängen, vorhandene Tests | Fehler fallen erst beim Kunden auf | Abläufe vor jeder Codeänderung mit Tests absichern |
| Sessions, Login, Zahlungs-Callbacks, Cronjobs, Importe und Exporte | Session-Konfiguration, eigene Session-Handler, Rücksprünge von Zahlungsanbietern, Crontab, Dateiformate | abgebrochene Bestellungen, unerwartete Abmeldungen, stille Datenfehler in nächtlichen Jobs | gezielt auf einer Testumgebung mit echten Abläufen prüfen |
| Verhaltensänderungen und neue Exceptions | Warnungen im Log, statische Analyse, Testlauf auf der Zielversion | Abbruch mitten im Ablauf statt einer Warnung | heutige Warnungen als künftige Fehler behandeln |
| Deprecations | Deprecation-Log, Läufe von PHPStan oder Rector | kurzfristig meist keine, später Bruch bei Entfernung | erfassen, nach Nutzung bündeln, schrittweise abbauen |
| Neue Sprachfeatures | entfällt | kein Risiko, wenn man sie nicht nutzt | optional, nach dem Upgrade |
Schwere und Aufwand sind zwei verschiedene Achsen. Eine geänderte Session-Einstellung lässt sich oft mit einer Zeile Konfiguration beheben, kann aber ohne diese Zeile den Bezahlvorgang lahmlegen. Umgekehrt können tausende Deprecation-Hinweise Wochen an Arbeit bedeuten und trotzdem heute keinen einzigen Kunden stören. Wer nach Aufwand priorisiert, macht das Falsche zuerst.
Was PHP 8.6 an älterem Code konkret ändert
Die folgenden Punkte stammen aus der UPGRADING-Datei von PHP 8.6.0 RC3. Bis zum Release kann sich Einzelnes noch ändern.
Session-Voreinstellungen. Drei Standardwerte ändern sich: session.use_strict_mode wird 1, session.cookie_httponly wird 1 und session.cookie_samesite steht auf Lax. Wer diese Werte bereits selbst setzt, merkt davon nichts. Wer sich auf die alten Defaults verlassen hat, kann zwei Effekte erleben. JavaScript kommt nicht mehr an das Session-Cookie, und bei Rücksprüngen per POST von einer fremden Domain, wie sie manche Zahlungsanbieter oder Single-Sign-on-Lösungen nutzen, wird das Cookie nicht mehr mitgeschickt. Dann hat der Kunde bezahlt und landet ohne Sitzung auf einer Fehlerseite. Eigene Session-Handler ohne validateId() und create_sid() erzeugen außerdem Deprecation-Hinweise, und mit Strict Mode werden unbekannte Session-IDs abgewiesen.
Strengere Prüfung von Argumenten. Mehrere Funktionen werfen jetzt einen ValueError, wo sie bisher still weitergemacht oder nur gewarnt haben. Dazu gehören array_filter() mit ungültigem Modus, number_format() mit Dezimalstellen außerhalb des Integer-Bereichs und eine Reihe von Dateifunktionen wie file_exists() oder filesize(), wenn der Dateiname NUL-Bytes enthält. Typisch betroffen sind Dateinamen aus Uploads oder Importen, die ungeprüft weitergereicht werden. Bisher stand eine Warnung im Log, ab 8.6 bricht der Ablauf ab.
Veraltete Aliase und Funktionen. is_double(), is_long(), is_integer() und doubleval() sind als veraltet markiert, Ersatz sind is_float(), is_int() und floatval(). Die alten Cast-Schreibweisen wie (integer) oder (boolean) wurden übrigens schon mit PHP 8.5 als veraltet markiert. Entfernt ist davon nichts, es gibt Hinweise im Log. Bei spl_object_hash() lohnt mehr Sorgfalt: Der empfohlene Ersatz spl_object_id() liefert eine Zahl statt einer 32-stelligen Zeichenkette. Wo der Wert gespeichert, in Cache-Schlüssel eingebaut oder mit Strings verglichen wird, muss man jede Stelle einzeln ansehen.
Mbregex. Die regulären Ausdrücke der mbstring-Erweiterung (mb_ereg(), mb_split() und verwandte Funktionen) sind veraltet, weil die zugrunde liegende Bibliothek Oniguruma nicht mehr gepflegt wird. Ein mechanischer Tausch gegen preg_* ist riskant. Syntax und Zeichensatz-Behandlung unterscheiden sich, gerade bei Daten, die nicht in UTF-8 vorliegen. Hier gehören echte Daten in den Test.
CSV und ArrayIterator. Die CSV-Methoden von SplFileObject (fgetcsv(), fputcsv(), setCsvControl(), getCsvControl()) sind veraltet. Das trifft Importe und Exporte, also Abläufe, die oft nachts laufen und selten jemand beobachtet. Bei jedem Ersatz sollten Trennzeichen, Escape-Verhalten und Zeilenenden mit echten Dateien verglichen werden. Bei ArrayIterator sind unter anderem die Sortiermethoden, getFlags(), setFlags() sowie serialize() und unserialize() betroffen.
Objekte, die wie Arrays behandelt wurden. Ein Objekt an array_walk() oder als Daten an http_build_query() zu übergeben, ist veraltet, ebenso Objekte in mb_convert_variables(). Älterer Code baut so gern Query-Strings für API-Aufrufe aus Objekten. Der in UPGRADING genannte Ersatz get_object_vars() berücksichtigt die Sichtbarkeit der Eigenschaften am Aufrufort, das Ergebnis kann also anders aussehen als bisher.
Daneben bringt 8.6 neue Sprachmittel wie Partial Function Application und clamp() sowie Beschleunigungen etwa bei json_encode(). Das ist angenehm, als Begründung für eine Modernisierung trägt es aber nicht.
Wie ein Projekt in Etappen abläuft
- Inventur. PHP-Version auf allen Servern, Framework, Composer-Pakete, Erweiterungen, Hosting und Deployment, Cronjobs, Schnittstellen und wer was verantwortet. Ergebnis ist eine Liste, die auch Dinge enthält, die nur auf dem Server stehen. Wie Sie die Version selbst prüfen, steht in PHP-Version prüfen.
- Risikobewertung. Belegte Befunde, Blocker, offene Annahmen und eine priorisierte Arbeitsliste nach dem Muster der Tabelle oben. Annahmen sollten als Annahmen markiert sein, sonst werden sie später für Fakten gehalten.
- Verhalten absichern. Charakterisierungstests für die kritischen Abläufe halten fest, was der Code heute tut, auch wenn das niemand dokumentiert hat. Volle Testabdeckung braucht es dafür nicht, mehr dazu in Testabdeckung bei PHP-Migrationen.
- Migration vorbereiten. Code- und Paketänderungen, Stufe für Stufe, auf einer Testumgebung mit repräsentativen Daten und denselben Erweiterungen und Cronjobs wie in Produktion. Welche Pakete dabei bremsen, zeigt Haben Sie Ihre Abhängigkeiten im Griff?.
- Ausrollen. Überwachung von Fehlern, Laufzeiten und fehlgeschlagenen Jobs, ein vorher geprüfter Rückweg und Kontrollen nach der Umstellung. Details in Rollback-Strategie für PHP-Migrationen.
Pflegen, schrittweise modernisieren oder ersetzen
Reine Pflege, also Version anheben und Hinweise abbauen, passt, wenn Framework und Pakete gepflegt sind, die Fachlogik stabil ist und die Anwendung keine großen Änderungen mehr vor sich hat. Sie wird teuer, wenn jedes Upgrade an derselben ungepflegten Bibliothek hängt.
Schrittweise Modernisierung ist eine Option, wenn die Anwendung weiterentwickelt werden soll und einzelne Bereiche das Tempo bremsen. Man baut dann Teil für Teil um und lässt den Rest laufen, wie in Schrittweise statt Big Bang beschrieben. Das klappt nur, wenn sich die Bereiche sauber trennen lassen.
Ersetzen ist sinnvoll, wenn die Belege dafür sprechen: eine Komponente, deren Basis nicht mehr gepflegt wird, die kaum eigene Fachlogik enthält und für die es eine passende Alternative gibt. Die ganze Anwendung neu zu schreiben, ist selten der erste Schritt. Woran man den Unterschied erkennt, steht in Wann sollte man Legacy-Software ersetzen?.
Fazit
PHP 8.6 bringt für ältere Anwendungen überschaubar viel Neues. Die größeren Posten sind meistens die Versionen davor und der Zustand von Paketen, Tests und Betrieb. Wer jetzt plant, sollte deshalb zuerst den eigenen Ausgangspunkt kennen und danach die Zielversion wählen, 8.4, 8.5 oder 8.6, je nachdem was Pakete und Hosting erlauben.
Eine brauchbare erste Einschätzung liefert vier Dinge: eine Inventur, eine nach Folgen geordnete Risikoliste, die realistischen Wege und eine Empfehlung für den nächsten Schritt, die sich auf Befunde stützt. Wenn Sie zuerst nur eine Einordnung möchten, ist der kostenlose Kurz-Check der passende Einstieg. Soll ein Blick in Code und Abhängigkeiten dazukommen, ist das der Befund. Beides verpflichtet Sie nicht zu einer Modernisierung.
Stand und Quellen
Stand: 11. Oktober 2026, PHP 8.6.0 RC3. Die Support-Daten für 8.6 sind aus der Release-Regel abgeleitet und noch nicht offiziell veröffentlicht.
