Symfony 6.4 Bugfixes enden im November 2026: Wie viel Zeit Sie wirklich haben

Symfony 6.4 End of Life liegt näher, als die meisten Teams, die darauf laufen, annehmen. Bugfixes für die Version enden im November 2026, wenige Wochen von jetzt an. Sicherheitsfixes folgen ein Jahr später, im November 2027. Läuft Ihre Anwendung auf 6.4, sind beide Daten auf unterschiedliche Weise wichtig, und sie zu verwechseln ist der Weg, wie aus einem geplanten Upgrade ein Notfall-Upgrade wird.

Die zwei Fristen, und warum sie nicht dasselbe sind

Symfony 6.4 erschien im November 2023 als Long-Term-Support-Release, gedacht für einen Produktivbetrieb über Jahre statt Monate. Jedes LTS-Release folgt demselben zweistufigen Zeitplan. Rund drei Jahre nach dem Release erhält es reguläre Bugfixes zusammen mit neuen Patch-Releases. Danach wechselt es für etwa ein weiteres Jahr auf reinen Sicherheitssupport, in dem Symfonys Maintainer neu entdeckte Schwachstellen weiterhin patchen, aber alles andere nicht mehr beheben.

Für 6.4 schließt das Bugfix-Fenster im November 2026. Von diesem Zeitpunkt an bleibt jeder nicht sicherheitsrelevante Bug im Framework selbst unbehoben, sofern Sie ihn nicht selbst patchen. Der Sicherheitssupport läuft dann bis November 2027, danach pflegt offiziell niemand mehr die Version. Eine nach diesem Datum gefundene, ungepatchte Schwachstelle bleibt ausnutzbar, solange Ihre Anwendung auf dieser Version weiterläuft.

Keine der beiden Fristen erzwingt einen sofortigen Rewrite. Viele Anwendungen laufen eine Weile ohne Probleme auf einer Version jenseits ihrer Bugfix-Grenze, weil die meisten relevanten Bugs in einem ausgereiften Framework bereits gefunden wurden. Die Sicherheitsfrist ist diejenige, die eine ernsthafte Planung wert ist, denn ab diesem Punkt bleiben neue Schwachstellen vollständig ohne offiziellen Patch.

PHP ist bereits Teil dieses Problems

Symfony 6.4 setzt mindestens PHP 8.1 voraus, und PHP 8.1 selbst erreichte am 31. Dezember 2025 sein End of Life. Läuft Ihre 6.4-Anwendung noch auf 8.1, sind Sie bereits über den Punkt hinaus, an dem die Sprach-Runtime unter dem Framework Sicherheitspatches erhält, unabhängig davon, was 2026 und 2027 mit Symfony selbst passiert.

PHP 8.2 ist nicht viel weiter dahinter. Der eigene Sicherheitssupport endet am 31. Dezember 2026, im selben Monat, in dem Symfony 6.4s Bugfixes enden. PHP 8.3 folgt demselben Muster ein Jahr später, mit Sicherheitssupport bis 31. Dezember 2027, und PHP 8.4 bis 31. Dezember 2028. Eine veraltende PHP-Version unter einem veraltenden Symfony zu stapeln verstärkt die Angriffsfläche, statt sie zu verteilen, und das ist ein häufigeres Setup, als Teams zugeben, bis jemand tatsächlich nachsieht.

Symfony 7.4 setzt PHP 8.2 oder höher voraus, aber auch PHP 8.2s eigenes Sicherheitsfenster schließt Ende 2026, daher lohnt es sich, das Symfony-Upgrade mit einem Sprung auf PHP 8.3 oder 8.4 im selben Projekt zu verbinden, statt beim bloßen Minimum des Frameworks stehen zu bleiben. Beide Versionssprünge zusammen zu erledigen ist weniger Aufwand, als sie als zwei separate Migrationen Monate voneinander getrennt zu behandeln, und bedeutet, dass Sie nicht innerhalb eines Jahres erneut über ein PHP-End-of-Life diskutieren.

Warum jetzt zu 7.4 zu wechseln besser ist, als auf die Frist 2027 zu warten

Symfony 7.4, veröffentlicht im November 2025, ist die aktuelle LTS-Version. Ihre Bugfixes laufen bis November 2028 und ihre Sicherheitsfixes bis November 2029, was rund zwei Jahre mehr Abdeckung bringt, als bis zur eigenen Frist auf 6.4 zu bleiben. Sie setzt außerdem PHP 8.2 oder höher voraus, sodass ein Wechsel zu 7.4 zusammen mit aktuellem PHP beide Probleme in einem Projekt löst statt in zwei getrennten später.

Mit der Migration von 6.4 auf 7.4 bis kurz vor November 2027 zu warten, ist der Standardweg, den Teams meist einschlagen, vor allem, weil noch nichts sichtbar kaputt ist. Der Aufwand dafür schrumpft durch Warten jedoch nicht. Das Deprecation-Log zu bereinigen, die verfügbaren Upgrade-Tools auszuführen und Drittanbieter-Bundles auf 7.x-Kompatibilität zu prüfen, dauert ungefähr die gleiche Anzahl Entwicklertage, ob Sie jetzt starten oder in achtzehn Monaten. Jetzt zu starten bedeutet nur, diese Arbeit nach einem normalen Zeitplan statt gegen eine Frist zu erledigen, mit Zeit, Probleme zu erkennen, bevor sie dringend werden. Die konkreten Schritte für genau diesen Sprung behandeln wir in unserem Leitfaden für das Upgrade von Symfony 6.4 direkt auf 7.4, und die breitere Entscheidung zwischen LTS-Versionen in unserem Überblick, welche Symfony-LTS zu welchem Projekt passt.

Fühlt sich ein Sprung über zwei Hauptversionen auf einmal nach mehr Veränderung an, als Ihr Team aktuell aufnehmen möchte, deckt unser Symfony-Upgrade-Leitfaden den allgemeinen Weg von einem älteren Symfony-Release zu einem aktuellen ab, unabhängig davon, von welcher spezifischen LTS-Version Sie starten.

Was es wirklich kostet, über November 2027 hinaus auf 6.4 zu bleiben

Die Kosten sind kein sofortiges Versagen. Anwendungen hören nicht auf zu laufen, weil das Support-Fenster einer Framework-Version schließt. Was sich ändert, ist, wer dafür verantwortlich ist, Schwachstellen zu finden und zu patchen, sobald Symfonys Maintainer aufhören, was in der Praxis bedeutet, dass das niemand tut, außer Sie zahlen für eine gesponserte Verlängerung, so wie Ibexa es für Symfony 5.4 getan hat, oder Sie patchen es selbst mit dem Quellcode in der Hand.

Es gibt außerdem einen schleichenden Preis, der nichts mit Sicherheit zu tun hat. Bundles und Drittanbieter-Pakete stellen den Support für ältere Symfony-Versionen nach und nach ein, sobald ihre eigenen Maintainer weiterziehen, sodass Sie mit jedem Monat auf 6.4 weniger kompatible Paket-Updates erhalten und der eventuelle Sprung auf eine aktuelle Version größer wird. Eine ein Jahr im Voraus geplante Migration ist normale Entwicklungsarbeit. Dieselbe Migration überstürzt durchzuführen, nachdem ein Sicherheitsvorfall die Entscheidung erzwingt, kostet mehr und birgt mehr Risiko, weil die Beteiligten reagieren statt zu planen.

Prüfen, wo Ihre Anwendung tatsächlich steht

Sie müssen dafür nicht selbst den Code öffnen. Zwei Zahlen klären das: die Symfony-Version in composer.json im Projektstammverzeichnis und die PHP-Version, auf der die Anwendung tatsächlich in Produktion läuft, was nicht immer dasselbe ist wie auf dem Laptop eines Entwicklers. Betreut ein Entwickler, eine Agentur oder ein Freelancer die Anwendung, sollten beide Zahlen innerhalb von Minuten zu bestätigen sein.

Fällt die Antwort vage aus, oder hat niemand eine der beiden Zahlen kürzlich geprüft, ist genau diese Lücke selbst eine Information. Es ist ein gängiger Weg, wie eine 6.4-Anwendung auf PHP 8.1 unbemerkt bleibt, bis beide Fristen nah genug sind, um eine Entscheidung unter Druck zu erzwingen.

Zwei weitere Zahlen sind es wert, gleichzeitig erfragt zu werden. Die erste ist, wie viele Einträge die eingebaute Deprecation-Prüfung des Frameworks für die aktuelle Codebasis ausgibt, da diese Zahl ein grober Indikator dafür ist, wie viel Aufräumarbeit die spätere 7.x-Migration erfordert. Die zweite ist, von wie vielen Drittanbieter-Bundles das Projekt abhängt und ob deren Maintainer bereits eine mit Symfony 7 kompatible Version veröffentlicht haben. Eine kurze Liste gut gepflegter Bundles macht das Upgrade unkompliziert. Eine lange Liste mit Paketen, die seit zwei Jahren niemand angerührt hat, ist das eigentliche Warnsignal, und es lohnt sich, das jetzt zu wissen statt mitten in der Migration zu entdecken.

Eine klare Antwort zu Ihrem Zeitplan bekommen

Der erste nützliche Schritt ist herauszufinden, wo Ihre Anwendung heute genau steht: welche Symfony-Version, welche PHP-Version, und wie weit die übrigen Abhängigkeiten vom aktuellen Stand abgedriftet sind. Ein kurzes Tech-Stack-Review betrachtet genau das und macht aus einem vagen „wir sollten irgendwann mal upgraden" ein realistisches Projekt mit einem echten Zeitplan.

Möchten Sie Hilfe dabei, einzuschätzen, wie eine Migration von Symfony 6.4 auf 7.4 für Ihre spezifische Anwendung aussieht, melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io. Wir haben Anwendungen bereits genau durch diesen Upgrade-Pfad geführt, und die, die reibungslos verlaufen, sind durchweg die, die mit der Planung begonnen haben, während November 2027 noch weit genug weg war, um die Arbeit richtig zu machen.