Symfony 5.4 End of Life: Wie viel Zeit Sie wirklich haben

Symfony 5.4 end of life ist nicht das, was die meisten Artikel darüber behaupten. Suchen Sie heute danach, finden Sie zahlreiche Seiten, die angeben, der Sicherheitssupport sei im November 2025 ausgelaufen, berechnet nach dem üblichen Muster für Symfonys Long-Term-Support-Versionen. Das war einmal richtig. Es ist nicht mehr richtig.

2025 zahlte ein Unternehmen namens Ibexa, das seine eigene Content-Plattform auf Symfony 5.4 aufgebaut hat, dafür, das Sicherheitssupport-Fenster zu verlängern. Symfonys eigene Release-Seite listet Symfony 5.4 inzwischen mit Sicherheitsfixes bis Februar 2029, mehr als drei Jahre nach dem Datum, das sich fast jeder im Kalender markiert hatte. Bugfixes für 5.4 endeten trotzdem bereits im November 2024, es kommt also keine neue Funktionsentwicklung oder routinemäßige Fehlerbehebung mehr. Was sich geändert hat: Schwerwiegende Schwachstellen werden weiterhin behoben und für alle veröffentlicht, nicht nur für Ibexa.

Was End of Life für ein Framework wie Symfony bedeutet

Jede größere Symfony-Version folgt einem Release-Kalender, über den sich die meisten Unternehmer nie Gedanken machen müssen, bis die eigene Version darauf auftaucht. Alle sechs Monate erscheint eine neue Version. Jede vierte Version, alle zwei Jahre, wird als Long-Term-Support- bzw. LTS-Version markiert, gedacht für einen Produktivbetrieb über Jahre statt Monate. Symfony 5.4, 6.4 und 7.4 sind alle LTS-Versionen.

Eine LTS-Version erhält normalerweise etwa drei Jahre lang reguläre Bugfixes, wechselt dann für rund ein weiteres Jahr auf reine Sicherheitsfixes, bevor der Support vollständig endet. Support bedeutet hier etwas Konkretes: Symfonys eigenes Maintainer-Team hört auf, neu entdeckte Schwachstellen in dieser Version zu patchen. Taucht nach Support-Ende eine Sicherheitslücke in Symfony 5.4 auf, behebt sie offiziell niemand mehr, und sie bleibt in jeder Anwendung, die diese Version weiter betreibt, ausnutzbar, solange diese Anwendung läuft.

Das echte Symfony-5.4-End-of-Life-Datum

Hier weicht 5.4 vom üblichen Muster ab. Im November 2021 veröffentlicht, folgte die Version dem Standardplan bis zum planmäßigen Ende der Bugfixes im November 2024. Der Sicherheitssupport sollte etwa ein Jahr später auslaufen, um November 2025, genau die Zahl, die die meisten Migrationsleitfäden noch zitieren, einschließlich einiger, die Symfony mit anderen PHP-Frameworks vergleichen.

Ibexas Sponsoring veränderte die zweite Hälfte dieses Zeitplans. Ibexas DXP-Plattform hängt von Symfony 5.4 ab und benötigte mehr Vorlaufzeit, also finanzierte Ibexa eine Verlängerung der reinen Sicherheitsphase bis Februar 2029. Symfony veröffentlichte die daraus entstehenden Patches über Packagist auf dieselbe Weise wie immer, sodass jedes Projekt, das 5.4 einsetzt, nicht nur Ibexas eigene Kunden, von denselben Fixes profitiert.

Das ist eine echte gute Nachricht, wenn Ihre Anwendung noch auf Symfony 5.4 läuft. Sie haben rund drei Jahre mehr Sicherheitsabdeckung, als das allgemein wiederholte Datum vermuten lässt. Das ist jedoch kein Grund, die Planung Ihres Upgrades einzustellen. Symfonys eigene Ankündigung der Verlängerung sagte das direkt: Sie existiert, um bereits engagierten Nutzern Raum zu geben, eine ohnehin geplante Migration abzuschließen, nicht um ein dauerhafter Ersatz für das Upgrade zu werden.

Warum die zusätzliche Zeit die Entscheidung kaum ändert

Eine gesponserte Verlängerung ist naturgemäß die Entscheidung eines anderen, weiterhin dafür zu bezahlen. Ibexa hat diese finanziert, weil das eigene Produkt sie brauchte. Nichts verpflichtet Symfony oder einen künftigen Sponsor, sie über Februar 2029 hinaus erneut zu verlängern, und es gibt keine Garantie, dass ein anderes Unternehmen einspringt, falls Ibexas Unterstützung früher endet oder nicht erneuert wird. Darauf zu planen, dass „sie wurde einmal verlängert, also wird sie wahrscheinlich wieder verlängert", ist eine Wette auf das Budget eines anderen, keine Wartungsstrategie.

Es gibt außerdem einen leiseren Preis dafür, auf 5.4 zu bleiben, der nichts mit dem Sicherheitskalender zu tun hat. Jeder Monat auf einer alten LTS-Version ist ein Monat, in dem der Abstand zur aktuellen Version weiter wächst: mehr veralteter Code, der irgendwann aufgeräumt werden muss, mehr Drittanbieter-Pakete, die den 5.4-Support eingestellt haben, und weniger Entwickler auf dem Markt, die sich noch erinnern, wie die ältere Version funktionierte. Dass die Sicherheitsuhr auf 2029 zurückgestellt wurde, setzt nichts davon zurück.

Wo das 6.4 und 7.4 einordnet

Wenn Sie abwägen, wann Sie von Symfony 5.4 wegziehen, geben die nächsten beiden LTS-Versionen den eigentlichen Zeitplan vor, an dem Sie sich orientieren sollten. Symfony 6.4, veröffentlicht im November 2023, erhält Bugfixes bis November 2026 und Sicherheitsfixes bis November 2027. Symfony 7.4, veröffentlicht im November 2025, ist die aktuelle LTS-Version, mit Bugfixes bis November 2028 und Sicherheit bis November 2029.

Ein Update von Symfony 5.4 auf 6.4 ist der kleinere der beiden Schritte, verschafft aber, von heute aus gerechnet, nur etwas mehr als ein Jahr zusätzliche Vorlaufzeit. Der direkte Sprung auf 7.4 verschafft bei vergleichbarem Migrationsaufwand die längste Vorlaufzeit, was in der Regel der bessere Tausch ist, sofern nichts Spezifisches in Ihrem Stack von 6.x abhängt. Wir haben einen ausführlichen Leitfaden dazu geschrieben, wie dieser Sprung von 5.4 gelingt, ohne dem Entwicklungsteam einen Feature-Freeze aufzuzwingen, da genau das die meisten Unternehmer beunruhigt, sobald sie das Wort Migration hören.

Was das bedeutet, wenn Sie heute Symfony 5.4 einsetzen

Sie befinden sich nicht in einer Notlage. Anders als bei einer Framework-Version, deren Sicherheitssupport tatsächlich ausgelaufen ist, erhält Symfony 5.4 weiterhin Patches und wird das noch Jahre lang tun. Das verändert die Lage von einer dringenden Notlösung vor einer Frist zu einer ordentlich zu planenden Aufgabe, was eine deutlich bessere Position ist, um Budget und Zeitplan zu verhandeln.

Es lohnt sich trotzdem, Februar 2029 als äußersten Rand eines Plans zu behandeln, nicht als Zieldatum. Eine Migration von 5.4 auf eine aktuelle LTS-Version betrifft veralteten Code, aktualisierte Abhängigkeiten und Konfigurationsänderungen in der gesamten Anwendung, und eine überstürzte Version dieser Arbeit, in den letzten Monaten vor einer Frist erledigt, kostet in der Regel mehr und birgt mehr Risiko als dieselbe Arbeit über einen normalen Projektzeitraum verteilt. Jetzt anzufangen, auch nur informell, mit einem ehrlichen Blick darauf, wie groß die Lücke für Ihre spezifische Anwendung tatsächlich ist, ist mehr wert als die zusätzlichen drei Jahre Vorlaufzeit für sich allein.

Herausfinden, auf welcher Version Sie tatsächlich sind

Dafür müssen Sie keinen Code lesen. Betreut ein Entwickler, eine Agentur oder ein Freelancer die Anwendung, fragen Sie direkt: „Auf welcher Symfony-Version sind wir, und ist das noch eine LTS-Version?" Eine kompetente betreuende Person sollte das innerhalb von Minuten beantworten können, da die Version in einer einzigen Datei steht, composer.json, im Projektstammverzeichnis.

Betreut aktuell niemand die Anwendung engmaschig, oder war die letzte Antwort vage, ist genau diese Wissenslücke etwas, dem man Aufmerksamkeit schenken sollte. Ein kurzes externes Review kann die Version bestätigen, prüfen, wie weit die übrigen Abhängigkeiten zurückgefallen sind, und Ihnen ein realistisches Bild geben, bevor Sie sich auf einen Projektzeitplan festlegen.

Eine klare Antwort zu Ihrem Zeitplan bekommen

Der erste nützliche Schritt ist herauszufinden, welche Symfony-Version Sie tatsächlich einsetzen und wie weit sie vom aktuellen Stand abgedriftet ist, denn sauber auf 5.4 zu sein und auf 5.4 mit einem Dutzend unbetreuter Bundles obendrauf zu sein, sind sehr unterschiedliche Projekte. Ein kurzes Tech-Stack-Review betrachtet genau das und liefert eine realistische Einschätzung statt einer Vermutung.

Wenn Sie Hilfe möchten, herauszufinden, wie ein Symfony-5.4-Upgrade für Ihre Anwendung tatsächlich aussieht, melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io. Wir haben Anwendungen bereits genau durch diese Migration geführt, und diejenigen, die gut verlaufen, sind die, die mit der Planung beginnen, während noch Zeit ist, es richtig zu machen, statt auf eine Frist zu warten, die die Entscheidung erzwingt.