Symfony 6.4 End of Life: Upgrade auf Symfony 7.4 LTS mit Plan, Zeitrahmen und realen Kosten

Wann erreicht Symfony 6.4 das End of Life?

Symfony 6.4 ist ein Long-Term-Support-Release (LTS) vom November 2023. Laut der offiziellen Release-Seite von Symfony (symfony.com/releases), geprüft am 22. Oktober 2026:

Die Uhr hat also zwei Markierungen. Ab Dezember 2026 wird ein Bug, den Sie in Symfony 6.4 melden, nicht mehr behoben. Ab Dezember 2027 wird auch eine Sicherheitslücke nicht mehr geschlossen. Symfony 7.4 LTS, veröffentlicht im November 2025, ist die Version, die ein Produkt bis Ende 2029 trägt.

Wir arbeiten jeden Tag mit Symfony: Es ist unser wichtigstes Back-End-Framework, und wir haben mehr als 15 Jahre Erfahrung damit. Die Website, die Sie gerade lesen, läuft Stand Oktober 2026 auf Symfony 6.4, dieser Leitfaden ist also auch unser eigener Plan. Wenn Sie das Upgrade lieber einem Team übergeben möchten, sehen Sie sich unsere Leistungen zur Symfony-Entwicklung an.

Was bedeutet das Support-Ende von Symfony 6.4 in der Praxis?

Das End of Life schaltet Ihre Anwendung nicht ab. Es ändert, wer das Risiko trägt.

• Bis November 2026 erhalten Sie Bugfixes und Sicherheitsfixes. Das ist das bequeme Zeitfenster für das Upgrade.
• Von November 2026 bis November 2027 erhalten Sie nur noch Sicherheitsfixes. Regressionen und Kompatibilitätsfehler bleiben offen, sodass neue PHP-Versionen und neue Releases von Bibliotheken anfangen, Reibung zu erzeugen.
• Nach November 2027 wird nichts mehr gepatcht. Jede Sicherheitslücke, die in einer Symfony-Komponente veröffentlicht wird (HTTP Kernel, Security, Forms, Serializer), bleibt in Ihrer Anwendung offen, bis Sie unter Druck upgraden.

Einige Nebenwirkungen treten früher ein als das offizielle Datum:

1. PHP ist Ihnen schon voraus. Symfony 6.4 erlaubt PHP 8.1, das seit Ende 2025 keine Sicherheitsfixes mehr erhält. Viele 6.4-Anwendungen laufen noch darauf.
2. Bundles entwickeln sich weiter. Die Maintainer verbreiteter Bundles streichen die Unterstützung für Symfony 6 in neuen Major-Versionen, sodass Sie auch deren Fixes nicht mehr übernehmen können.
3. Die Due Diligence bemerkt es. Sicherheitsfragebögen von Kunden, Berichte von Penetrationstests und technische Prüfungen durch Investoren weisen auf nicht mehr unterstützte Frameworks hin.
4. Je länger Sie warten, desto mehr überspringen Sie. Eine 6.4-Anwendung, die bis 2028 wartet, muss die Änderungen von 7.4 und 8.x auf einmal bewältigen.

Sollten Sie auf Symfony 7.4 LTS oder Symfony 8 zielen?

Für die meisten Produkte auf 7.4 LTS. Es erhält drei Jahre Bugfixes und vier Jahre Sicherheitsfixes, läuft auf PHP 8.2 und neuer und ist die Version, gegen die Bundles von Drittanbietern zuerst testen.

Symfony 8.x ist sinnvoll, wenn Ihr Team im Rahmen der regulären Wartung alle sechs Monate upgradet. Jede Minor-Version von 8.x wird etwa acht Monate unterstützt und braucht PHP 8.4. Die gute Nachricht: Eine Codebasis, die auf 7.4 ohne Deprecation-Warnungen läuft, ist nur einen kleinen Schritt von 8.0 entfernt, weil Major-Versionen von Symfony nur entfernen, was die letzte Minor-Version als veraltet markiert hat. Wer jetzt auf 7.4 geht, hält sich beide Wege offen.

Wie upgraden Sie Symfony 6.4 Schritt für Schritt auf 7.4?

Der offizielle Ansatz, dem wir folgen, lautet: zuerst die Deprecations beheben, dann die Version wechseln. Hier ist der Plan, den wir in Kundenprojekten verwenden.

1. Codebasis und Abhängigkeiten prüfen

Beginnen Sie mit Fakten, nicht mit Schätzungen:

• composer outdated und composer why-not symfony/framework-bundle 7.4 zeigen, welche Pakete das Upgrade blockieren.
• Listen Sie jedes Bundle von Drittanbietern auf und prüfen Sie, ob es ein Release mit Unterstützung für Symfony 7 gibt. Verwaiste Bundles sind die Hauptquelle für Überraschungen.
• Zählen Sie die Deprecations: Lassen Sie die Testsuite mit der PHPUnit Bridge laufen und prüfen Sie bin/console debug:container --deprecations sowie das Deprecation-Log im Profiler auf den wichtigsten Seiten.
• Notieren Sie die PHP-Version in Produktion, in der CI und auf den Rechnern der Entwickler.

In der composer.json unserer eigenen Website findet das Audit sofort zwei Blocker: sensio/framework-extra-bundle und doctrine/annotations. Das SensioFrameworkExtraBundle ist verwaist und unterstützt Symfony 7 nicht, und Symfony 7 liest Doctrine-Annotations für Routing, Validierung und Serialisierung nicht mehr. Beide müssen vor dem Wechsel entfernt werden. Diese beiden sind die häufigsten Blocker, die wir in 6.x-Anwendungen sehen.

2. Auf eine unterstützte PHP-Version wechseln

Symfony 7.4 braucht PHP 8.2+, aber der Sicherheitssupport für PHP 8.2 endet am 31. Dezember 2026 (php.net, geprüft im Oktober 2026). Wechseln Sie auf PHP 8.4, wenn Ihr Hosting und Ihre Extensions das zulassen; es wird bis Ende 2028 unterstützt. Führen Sie das PHP-Upgrade als eigenes Release durch, noch auf Symfony 6.4, damit Sie bei einem Fehler wissen, welche Änderung ihn verursacht hat. Lassen Sie PHPStan und die PHP-Sets von Rector gegen die Zielversion laufen, bevor Sie wechseln.

3. Deprecations auf 6.4 beseitigen

Hier liegt der größte Teil der Arbeit. Typische Punkte in einer 6.4-Codebasis:

• Annotations in PHP-Attribute umwandeln: @Route, @ORM\..., @Assert\..., @Groups. Rector konvertiert die meisten davon automatisch.
• Funktionen des SensioFrameworkExtraBundle durch native ersetzen: #[MapEntity] und Argument Resolver statt @ParamConverter, #[IsGranted] statt @Security, #[Template] aus der Twig Bridge statt @Template.
• Rückgabetypen bei überschriebenen Methoden (Voter, Normalizer, Commands, Event Subscriber), die verpflichtend werden.
• Entfernte Klassen und Interfaces wie ContainerAwareInterface sowie alte Schlüssel der Security-Konfiguration.
• Ihr eigener Code, der veraltete APIs aufruft, die das Deprecation-Log findet.

Führen Sie diese Korrekturen in kleinen Pull Requests in den Hauptzweig zusammen, während das Produkt weiter auf 6.4 läuft. Das Ziel sind null Deprecation-Hinweise in den Tests und in den wichtigsten Nutzerabläufen.

4. Bundles aktualisieren oder ersetzen

Aktualisieren Sie jedes Bundle auf eine Version, die sowohl Symfony 6.4 als auch 7.x unterstützt, sofern es eine gibt. Für verwaiste Bundles gibt es drei Optionen: einen gepflegten Fork, einen Ersatz oder die Übernahme des kleinen Teils, den Sie nutzen, in Ihren eigenen Code. Doctrine ORM 3 und DBAL 4 kommen hier oft zur Sprache; sie sind unabhängig von Symfony 7.4 und können später erfolgen, wenn Ihre Bundles noch ORM 2.x erlauben, was das Risiko senkt.

5. Version wechseln und Recipes aktualisieren

Ändern Sie extra.symfony.require und die Constraints für symfony/* auf 7.4.*, führen Sie composer update "symfony/*" --with-all-dependencies aus und dann composer recipes:update, um die Konfigurationsänderungen Recipe für Recipe zu prüfen. Lesen Sie die Dateien UPGRADE-7.0.md bis UPGRADE-7.4.md für die Komponenten, die Sie nutzen. Leeren Sie den Cache, wärmen Sie ihn in der Produktionsumgebung auf und beheben Sie, was dabei bricht.

6. Gründlich testen

Lassen Sie die automatisierte Testsuite laufen und prüfen Sie dann manuell die Abläufe, mit denen Sie Geld verdienen: Registrierung und Login, Checkout oder Abrechnung, Importe und Exporte, geplante Commands, Messenger-Worker, E-Mails und PDF-Erzeugung. Security (Firewalls, Voter, Passwort-Hashing) und Forms verdienen eigene Tests, weil sie sich über 6.x und 7.x am stärksten verändert haben. Wenn die Anwendung wenige Tests hat, schreiben Sie Charakterisierungstests für diese Abläufe vor Schritt 3, nicht danach.

7. Gestuft ausrollen

Deployen Sie zuerst auf Staging mit produktionsnahen Daten, dann in Produktion mit offenem Fehlermonitoring und einem vorbereiteten Rollback. Wenn die Anwendung mehrere Server oder Mandanten hat, geben Sie das Release zuerst für einen kleinen Teil frei. Halten Sie den 6.4-Branch ein bis zwei Wochen deploybar. Erhöhen Sie nach dem Release das Level von PHPStan um eins und ergänzen Sie einen CI-Job, der bei neuen Deprecations fehlschlägt, damit das nächste Upgrade auf 8.x kurz wird.

Wie lange dauert das Upgrade je nach Projektgröße?

Dies sind typische Spannen aus unserer Upgrade-Arbeit, für ein oder zwei Senior-Entwickler. Sie gehen von Symfony 6.4 als Ausgangspunkt aus und schließen Tests und Rollout ein.

Was ein Projekt in eine größere Zeile verschiebt: verwaiste Bundles, intensive Nutzung des SensioFrameworkExtraBundle und von Annotations, eigener Security-Code, ein Abstand bei der PHP-Version und fehlende Tests. Was es in eine kleinere verschiebt: eine 6.4-Codebasis ohne Deprecations und eine CI-Pipeline, die bereits PHPStan ausführt.

Zum Vergleich: Unsere Plattform Ritoria hat 54 Domänen-Entitäten auf Symfony, was sie in die Zeile "mittel bis groß" einordnet. Ein Geschäftssystem wie unser individuelles ERP für ein US-Unternehmen für Flugzeugwartung, mit Terminplanung, Lager und Echtzeit-Updates über Mercure, liegt wegen der Zahl der zu testenden Abläufe ebenfalls in diesem Bereich.

Checkliste für das Upgrade von Symfony 6.4 auf 7.4

• PHP-Versionen in Produktion, CI und lokal erfasst
• composer outdated und blockierende Pakete geprüft
• Jedes Bundle auf Unterstützung für Symfony 7 geprüft; Plan für verwaiste Bundles
• Fehlermonitoring und eine getestete Wiederherstellung aus dem Backup vorhanden
• Tests für kritische Abläufe (Charakterisierungstests bei geringer Abdeckung)
• PHP auf 8.2+ aktualisiert (8.4 empfohlen), als eigenes Release
• Annotations mit Rector in Attribute umgewandelt
• SensioFrameworkExtraBundle und doctrine/annotations entfernt
• Null Deprecations in der Testsuite und auf den wichtigsten Seiten
• Constraints für symfony/* und extra.symfony.require auf 7.4.* gesetzt
• composer recipes:update Recipe für Recipe geprüft
• Security, Forms, Serializer und Messenger-Worker gezielt getestet
• Release auf Staging mit produktionsnahen Daten
• Rollout in Produktion mit Monitoring und Rollback-Plan
• CI-Job, der bei neuen Deprecations fehlschlägt

Was sind die wichtigsten Risiken?

Das Upgrade selbst ist vorhersehbar. Projekte gehen schief, wenn das Audit übersprungen wird und eine verwaiste Abhängigkeit erst in Woche sechs auffällt.

Was kostet ein Symfony-Upgrade wirklich?

Die Kosten folgen den Personentagen. Bei typischen Marktsätzen für 2026 von rund 30 bis 50 USD pro Stunde für erfahrene ukrainische Entwickler ergibt die Zeittabelle oben einige tausend Dollar für eine kleine, saubere Anwendung und Zehntausende für eine große Plattform. Agenturen in Westeuropa und den USA verlangen für dieselbe Arbeit typischerweise das Zwei- bis Vierfache pro Stunde.

Bei uns beginnt ein Projekt für ein Symfony-Upgrade ab 10.000 USD, mit einem Festpreisangebot nach einem kurzen Scoping-Gespräch. Typische Spannen:

Die meisten mittelgroßen Business-Anwendungen landen in einer typischen Spanne von 10.000 bis 30.000 USD. Zeigt das Audit, dass die Anwendung älter als 6.4 ist oder ohne Framework gebaut wurde, wird die Arbeit zu einem Modernisierungsprojekt. Wenn Sie für laufende Wartung und Upgrades lieber ein monatliches Budget haben, ist ein dediziertes Entwicklungsteam oft die einfachere Lösung.

Wann sollten Sie das Upgrade mit KI-Funktionen verbinden?

Verbinden Sie beides, wenn die KI-Funktion denselben Code berührt, den Sie während des Upgrades ohnehin testen, und wenn Ihre Frist ein paar zusätzliche Wochen zulässt. Sie bezahlen das Sicherheitsnetz aus Tests, die CI-Arbeit und die Regressionstests dann einmal statt zweimal.

Gute Gründe für die Verbindung:

1. Die KI-Funktion braucht moderne Symfony-Funktionen. Messenger-Worker, der Rate Limiter, Attribute und der neuere HttpClient sind die Basis von KI-Funktionen, und neue KI-bezogene Bundles zielen zuerst auf aktuelle Symfony-Versionen.
2. Dasselbe Team und dieselben Tests. Entwickler, die gerade Ihre Bundles, Ihre Security und Ihr Datenmodell erfasst haben, bauen die KI-Funktion schneller.
3. Ein Release-Plan. Zuerst das Upgrade, einige Wochen später die KI-Funktion auf dem aktualisierten Kern, in einem Projekt.

Halten Sie beides getrennt, wenn das Upgrade dringend ist (zum Beispiel wegen der Frist eines Sicherheitsaudits) oder wenn die KI-Funktion noch eine Idee ohne klaren Nutzerablauf ist. Dann upgraden Sie jetzt und validieren die Idee später als eigenen Schritt, zum Beispiel als 4-wöchigen AI Sprint zum Festpreis von 10.000 USD.

Unser eigenes Produkt AI Resume Master läuft auf PHP und Symfony mit React und Python und erreichte 50.000 monatlich aktive Nutzer.

Unser Fazit

Planen Sie das Upgrade jetzt, solange Symfony 6.4 noch Bugfixes erhält, und zielen Sie auf 7.4 LTS mit PHP 8.4. Gehen Sie in drei Releases vor: PHP, Deprecations, dann der Versionswechsel. Beginnen Sie mit einem kurzen Audit, damit das verwaiste Bundle in Woche eins gefunden wird. Für eine typische Business-Anwendung ist es ein Projekt von 3 bis 12 Wochen mit bekannten Kosten, und jeder Monat des Wartens erhöht sie.

Wenn ein Team das Upgrade übernehmen soll, sehen Sie sich unsere Leistungen zur Symfony-Entwicklung an oder kontaktieren Sie uns mit Ihren aktuellen Symfony- und PHP-Versionen und der Liste aus composer outdated.