PHP 8.2 End of Life und Symfony 6.4: Welche Frist für Ihr Projekt wirklich zählt

Drei Fristen, ein Quartal

Wer ein gewachsenes Symfony-Projekt betreut, hat in diesen Wochen wahrscheinlich schon eine Mail vom Hoster oder eine Warnung im Dependency-Check gesehen. Das ist verständlich, denn gleich mehrere Supportzeiträume enden fast gleichzeitig. Einzeln wären sie gut planbar. Zusammen erzeugen sie den Eindruck, alles müsse bis Weihnachten erledigt sein.

Diesen Eindruck teile ich nicht. In den Projekten, die ich betreue, zeigt sich immer wieder: Die Fristen sind real, aber sie haben unterschiedliches Gewicht. Wer sie sauber auseinanderhält, kann das Dringende jetzt erledigen und den Rest ruhig in 2027 planen. Dieser Artikel sortiert die Termine und zeigt, welche Entscheidung tatsächlich ansteht.

Die Ausgangslage: Welche Termine gelten

PHP 8.2 erhält ab dem 31. Dezember 2026 keine Sicherheitsupdates mehr. Bekannt werdende Lücken in der Laufzeitumgebung werden danach offiziell nicht mehr geschlossen.

Symfony 6.4 LTS verlässt im November 2026 den Bugfix-Support. Sicherheitsupdates gibt es für 6.4 aber noch bis November 2027. Das ist ein wichtiger Unterschied: Das Framework bleibt noch ein Jahr abgesichert, nur funktionale Fehler werden nicht mehr behoben.

Dazu kommen die Hoster. Host Europe stellt am 9. November 2026 alle Domains, die dann noch auf PHP 8.2 laufen, automatisch auf PHP 8.4 um. Bis zum 7. Dezember lässt sich die alte Version im Kundenbereich noch einmal zurückschalten, danach wird PHP 8.2 auf der Classic-Hosting-Plattform endgültig deaktiviert. Ein Aussetzen der Umstellung ist laut Host Europe nicht möglich. Andere Anbieter gehen erfahrungsgemäß ähnlich vor, mit eigenen Terminen.

Wie viele Projekte sind betroffen?

Für professionelle Composer-Projekte liefern die Packagist-Daten das realistischste Bild. Laut der Auswertung von Brent Roose auf stitcher.io, Stand 1. Juli 2026, liefen 14 Prozent der Installationen auf PHP 8.2. Weitere 11 Prozent verteilten sich auf 8.1, 7.4 und 8.0. Zusammen sind das 25 Prozent, die zum Jahresende ohne offiziellen PHP-Support dastehen.

Auffällig ist auch die Paketseite: Laut derselben Auswertung verlangen nur 352 der 1.000 meistgenutzten Pakete eine PHP-Version, die noch Sicherheitsupdates erhält. Die Abhängigkeiten selbst erzwingen den Umstieg also selten. Der Anstoß muss aus dem Projekt kommen.

W3Techs, das alle Websites einschließlich Shared Hosting zählt, meldet für den 24. September 2026 einen PHP-8-Anteil von 64,2 Prozent. Innerhalb von PHP 8 lag Version 8.2 dort im Juli bei 31 Prozent. Diese Zahlen sind höher, weil sie viele unbetreute Installationen enthalten, zeigen aber dieselbe Richtung.

Optionen mit wirtschaftlicher Einordnung

Für ein Projekt auf PHP 8.2 und Symfony 6.4 gibt es im Kern drei Wege.

Nur PHP aktualisieren, Symfony 6.4 behalten. Die Anwendung wird auf PHP 8.3 oder 8.4 gehoben, das Framework bleibt auf 6.4. Das ist der kleinste Eingriff und schließt die dringendste Lücke, denn Symfony 6.4 erhält noch bis November 2027 Sicherheitsupdates. Der Aufwand hängt vor allem an den Drittanbieter-Bundles und an Deprecations, die PHP 8.3 und 8.4 sichtbar machen.

PHP und Symfony in einem Schritt anheben. Projekt auf PHP 8.4 und Symfony 7.4 LTS, das bis November 2028 Bugfixes und bis November 2029 Sicherheitsupdates erhält. Danach ist für mehrere Jahre Ruhe. Der Nachteil: Zwei Upgrades gleichzeitig vergrößern die Fehlerfläche und die Zeit bis Dezember ist für größere Projekte knapp.

Extended Support beim Hoster oder Dienstleister. Einige Anbieter verlängern die Bereitstellung alter PHP-Versionen gegen Aufpreis. Das kauft Zeit, löst aber nichts. Sinnvoll ist das nur als bewusst befristete Brücke, wenn ein Upgrade bereits geplant ist und nur der Termin nicht passt.

Die Unterscheidung zwischen diesen drei Gruppen ist der wichtigste Schritt, bevor über Aufwand gesprochen wird.

Entscheidungskriterien: Welcher Weg passt zu Ihrem Projekt?

Wie gut ist die Testabdeckung? Ohne automatisierte Tests zeigt sich ein PHP-Wechsel erst im Betrieb. Mit einer brauchbaren Testsuite lässt sich der Sprung auf 8.4 in einer Staging-Umgebung gefahrlos durchspielen. Fehlen die Tests, spricht vieles für den kleineren Schritt und gegen das gleichzeitige Symfony-Upgrade.

Wie viele Drittanbieter-Bundles hängen am Projekt? Die Symfony-Version selbst ist beim Upgrade selten das Problem. Aufwand entsteht bei Bundles, die nicht mehr gepflegt werden oder auf neuere Versionen hinterherhinken. Ein composer outdated und ein Blick auf die Wartungsaktivität der wichtigsten Pakete geben hier eine schnelle erste Einschätzung.

Wer hostet und wer kontrolliert die PHP-Version? Auf Shared Hosting bestimmt der Hoster den Termin. Auf eigenen Servern oder in Containern haben Sie die Kontrolle, sollten aber dieselbe Frist einhalten, wenn Sie Sicherheitsupdates wollen.

Wie lange soll das Projekt noch laufen? Ein System, das in zwei Jahren abgelöst wird, braucht kein Symfony 7.4. Ein System mit langer Perspektive profitiert davon, beide Upgrades bis 2027 sauber hintereinander abzuschließen.

Wer mehr Hintergrund zur grundsätzlichen Versionsstrategie sucht, findet ihn im Artikel Symfony LTS oder aktuelle Version.

Was jetzt zu tun ist

Bis zum 9. November bleiben rund sechs Wochen. Das reicht für eine Bestandsaufnahme der Abhängigkeiten, einen Testlauf auf PHP 8.4 in Staging und den eigentlichen Wechsel, wenn das Projekt nicht außergewöhnlich groß ist. Das Symfony-Upgrade auf 7.4 gehört dann in die Planung für 2027, mit ausreichend Abstand zum Bugfix-Ende und genug Puffer bis zum Sicherheitsende im November 2027.

Wer die beiden Fristen trennt, nimmt den Druck aus dem Dezember. Ich gehe gerade selbst die Projekte durch, die ich betreue, und prüfe bei jedem, welches Bundle den Wechsel auf 8.4 als Erstes ausbremst. Wie Sie das Upgrade im Budget 2027 verankern.

Dennis Schwenker-Sanders ist PHP- und Symfony-Entwickler und begleitet Agenturen und KMU im DACH-Raum bei Upgrades und der Modernisierung gewachsener Systeme. Mehr zur Zusammenarbeit als Symfony-Entwickler finden Sie auf der Leistungsseite.