Symfony 6.4: Bugfix-Support endet im November 2026, so planen Sie das Upgrade auf 7.4
Symfony 6.4 ist die aktuelle LTS-Version. Das bedeutet: der längste Support-Zeitraum im Symfony-Zyklus. Trotzdem tickt die Uhr bereits. Ab November 2026 endet der Bugfix-Support. Symfony 6.4 EOL ist kein fernes Problem für übernächstes Jahr. Es ist eine Frist, die in wenigen Monaten greift.
Das betrifft viele Unternehmen. Symfony 6.4 ist seit November 2023 die Standardwahl für neue Projekte. Gerade weil es als LTS-Version galt. Wer sich damals für Stabilität entschieden hat, steht jetzt vor der nächsten Entscheidung.
Dieser Artikel erklärt den Unterschied zwischen Bugfix- und Security-Support. Er zeigt den Upgrade-Pfad auf Symfony 7.4 LTS. Und er gibt eine realistische Einschätzung, wie lange so ein Upgrade dauert.
Was genau bedeutet Symfony 6.4 EOL?
Symfony veröffentlicht alle sechs Monate eine neue Minor-Version. Jede vierte davon bekommt den Status Long Term Support, kurz LTS. 6.4 wurde im November 2023 veröffentlicht. Es ist die aktuelle LTS-Reihe. Die nächste, Symfony 7.4, erschien im November 2025.
Für LTS-Versionen gilt bei Symfony ein fester Zeitplan. Drei Jahre Bugfix-Support. Danach ein weiteres Jahr nur noch mit Sicherheitsfixes. Der Unterschied zwischen beiden Phasen ist entscheidend.
Bugfix-Support bedeutet: Gemeldete Fehler werden korrigiert, auch wenn sie kein Sicherheitsrisiko sind. Ein falsch gerendertes Formularfeld zum Beispiel. Oder eine Inkonsistenz im Validator. All das fließt noch in neue Patch-Releases ein.
Security-Support ist enger gefasst. Nur noch Sicherheitslücken werden geschlossen. Alles andere bleibt, wie es ist. Selbst wenn ein Bug den Betrieb stört.
Für Symfony 6.4 heißt das konkret: Bugfix-Support bis November 2026. Danach, bis November 2027, gibt es nur noch Patches für Sicherheitslücken. Ab November 2027 ist komplett Schluss. Keine Patches, keine Sicherheitsfixes, kein offizieller Support mehr.
Das ist derselbe Mechanismus, den auch andere Frameworks nutzen. Wer schon einmal eine veraltete Symfony-Version abgelöst hat, kennt das Muster. Erst wird der Support dünner. Dann endet er ganz. Läuft Ihr Projekt noch auf Symfony 2 oder 3? Den Umstieg auf eine aktuelle LTS-Version haben wir bereits beschrieben. Die Logik dahinter ist dieselbe wie beim Schritt von 6.4 auf 7.4. Nur mit mehr Zwischenstationen.
Welche Konsequenzen hat das für Ihr Projekt?
Ein Jahr Sicherheitsfixes klingt nach Zeit. In der Praxis ist es weniger, als es scheint.
Normale Bugs werden nicht mehr behoben
Sobald der Bugfix-Support endet, bleiben gemeldete Fehler offen, die keine Sicherheitslücke sind. Ein Rendering-Fehler in einem Formular etwa. Oder eine Inkonsistenz im Validator. Solche Fehler werden nicht mehr korrigiert. Sie müssen sie selbst umschiffen oder patchen.
Abhängigkeiten ziehen nach
Pakete wie Doctrine oder API Platform richten sich nach der aktuell unterstützten Symfony-Version. Neue Major-Releases dieser Pakete verlangen oft ein aktuelleres Symfony. Wer auf 6.4 verharrt, bekommt irgendwann keine Updates mehr für seine Abhängigkeiten. Auch wenn Symfony selbst noch Sicherheitsfixes liefert.
Nach November 2027 ist das Risiko real
Ab dem vollständigen End of Life bleibt jede neu entdeckte Lücke offen. Angreifer scannen das Internet gezielt nach Anwendungen mit bekannten, unbehobenen Schwachstellen. Eine Symfony-Installation ohne Support ist ein dokumentiertes und leicht zu findendes Ziel.
Für Unternehmen mit Kundendaten kommt die DSGVO dazu. Eine Aufsichtsbehörde fragt nach einem Vorfall, warum das System nicht auf einer unterstützten Version lief. Eine gute Antwort darauf gibt es nicht.
PHP-Versionen und Hosting ziehen mit
Auch die PHP-Welt bewegt sich weiter. Neue PHP-Versionen verlangen zunehmend ein aktuelles Symfony. Und Hosting-Anbieter stellen ältere PHP-Versionen irgendwann ab. Wer mit Symfony 6.4 stehen bleibt, riskiert zwei End-of-Life-Probleme gleichzeitig. Statt sie nacheinander zu lösen.
Der Upgrade-Pfad von Symfony 6.4 auf 7.4
Die gute Nachricht zuerst: Symfony ist für genau diesen Fall gebaut. Der Umstieg von einer LTS-Version auf die nächste folgt einem klaren Muster.
Schritt 1: Deprecations bereinigen
Jede Symfony-Minor-Version markiert Code, der in der nächsten Major-Version entfernt wird, als veraltet. Prüfen Sie vor dem Upgrade, welche Deprecation-Warnungen Ihre Anwendung unter 6.4 noch ausgibt. Symfony liefert dafür eigene Werkzeuge mit, etwa den Deprecation-Helper in der PHPUnit-Bridge. Wer diese Warnungen vorab abarbeitet, vermeidet die meisten Überraschungen.
Schritt 2: Umstieg auf Symfony 7.0
Symfony 7.0 entfernt nur Code, der bereits unter 6.4 als veraltet markiert war. Haben Sie Schritt 1 sauber erledigt, ist dieser Schritt in den meisten Projekten überschaubar. Composer-Abhängigkeiten werden angehoben. Die Testsuite läuft. Auffällige Stellen werden korrigiert.
Schritt 3: Schrittweise bis Symfony 7.4
Zwischen 7.0 und 7.4 liegen mehrere Minor-Versionen. Jede davon bringt neue Funktionen, aber auch neue Deprecations. Springen Sie nicht direkt auf 7.4. Gehen Sie stufenweise vor: erst 7.1, dann 7.2, und so weiter. So bleibt jeder Schritt klein genug, um Fehler schnell einzugrenzen.
Bei größeren oder gewachsenen Projekten zeigen sich an dieser Stelle oft technische Schulden. Sie haben sich über mehrere Symfony-Versionen angesammelt. Das verlangsamt das Upgrade, macht es aber nicht unmöglich. Die technischen Details erklären wir in unserem Artikel zur Symfony 7 Migration.
Schritt 4: Testen, Monitoring, Go-Live
Vor dem produktiven Einsatz läuft das Upgrade in einer Testumgebung. Sie sollte der Produktion möglichst genau entsprechen. Nach dem Go-Live lohnt sich erhöhte Aufmerksamkeit bei den Fehler-Logs. Die ersten Tage nach einem Framework-Upgrade zeigen zuverlässig, ob etwas übersehen wurde.
Wie lange dauert ein Symfony-Upgrade in der Praxis?
Das hängt stark vom Projekt ab. Eine schlanke Anwendung mit aktueller Codebasis und guter Testabdeckung ist oft in wenigen Tagen fertig. Ein gewachsenes Projekt, das seit Symfony 3 oder 4 mehrfach migriert wurde, braucht deutlich länger. Besonders, wenn die Deprecations nie konsequent bereinigt wurden. Hier sind mehrere Wochen keine Seltenheit.
Drei Dinge sind entscheidend: die Anzahl eigener Bundles, der Umfang der Testsuite. Und wie viele alte Deprecation-Warnungen bislang ignoriert wurden. Wer das nicht selbst einschätzen kann, bekommt bei uns eine realistische Aufwandsschätzung. Bevor ein Auftrag beginnt.
Die Kosten reichen von einem niedrigen vierstelligen Betrag für kleine Anwendungen bis zu deutlich mehr. Je nach Größe und Komplexität des Projekts. Pauschale Preise helfen hier wenig. Sinnvoll ist eine kurze Bestandsaufnahme, aus der sich der tatsächliche Aufwand ableiten lässt. Statt vorab zu raten.
Lohnt sich das Upgrade auch ohne akuten Druck?
Ja. Wer bis November 2026 wartet, upgradet unter Zeitdruck. Wer jetzt beginnt, kann das Projekt in Ruhe planen. Tests aufbauen. Die Deprecations in kleinen Schritten abarbeiten. Statt alles in den letzten Wochen zu erledigen.
Dazu kommt ein Vorteil: Symfony 7 bringt gegenüber 6.4 spürbare Verbesserungen bei Performance und Entwicklerkomfort. Ein Upgrade ist also keine reine Pflichtübung gegen den Zeitdruck. Es bringt auch unmittelbar etwas für den laufenden Betrieb.
Fazit: Planen Sie das Upgrade, bevor die Frist drängt
Symfony 6.4 EOL ist kein abstraktes Datum im Kalender. Es ist der Punkt, an dem gepflegte Software zu einem offenen Risiko wird. Bis November 2026 ist noch Zeit für ein geordnetes Upgrade. Danach wird jeder Monat teurer, nicht günstiger.
Wer heute mit der Bestandsaufnahme beginnt, hat die Kontrolle über den Zeitplan. Wer bis zum letzten Monat wartet, hat sie nicht mehr.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihr Symfony-Projekt an. Und sagen Ihnen ehrlich, welcher Upgrade-Pfad für Sie der richtige ist.
