Symfony auf Version 7 migrieren: Der planbare Weg

Ein Symfony-Upgrade wirkt oft bedrohlicher, als es ist. Der Grund für die Angst ist meist eine schlechte Erfahrung mit anderen Frameworks, wo ein Versionssprung bedeutet, dass plötzlich die halbe Anwendung nicht mehr startet. Symfony macht das anders, und wer diesen Unterschied versteht, geht das Ganze deutlich entspannter an.

Der Schlüssel heißt Deprecations. Symfony kündigt Änderungen lange vorher an, statt sie einfach auszuliefern.

Warum man nicht in einem Rutsch springt

Es liegt nahe, ein Symfony-4-Projekt direkt auf 7 heben zu wollen. In der Praxis führt der Weg aber über die Zwischenversionen, also 4.4, dann 5.4, dann 6.4, dann 7. Das hat einen guten Grund: Jede dieser .4-Versionen ist eine LTS-Version und bildet den sauberen Übergabepunkt zur nächsten Hauptversion.

Der eigentliche Trick liegt in den Deprecation-Meldungen. Innerhalb einer Hauptversion ändert sich das Verhalten nicht. Aber das Framework protokolliert jede Nutzung von etwas, das in der nächsten Version wegfällt. Ihr Ziel bei jedem Zwischenschritt ist deshalb simpel: die Deprecation-Meldungen auf null bringen. Ist das erledigt, verläuft der Sprung auf die nächste Hauptversion in aller Regel unspektakulär. Man arbeitet sich also von Meldung zu Meldung vor, und an keinem Punkt steht die Anwendung still.

Der Ablauf im Überblick

1. Zuerst auf die aktuelle Minor-Version innerhalb der eigenen Hauptversion gehen. Ein Symfony 4.2 wird also erst zu 4.4, bevor 5 überhaupt ein Thema ist.
2. Deprecations sichtbar machen. Symfony zeigt sie in der Web Debug Toolbar und im Test-Log, und die PHPUnit-Bridge kann sie sogar als Testfehler werten.
3. Die Deprecations abarbeiten. Meist geht es um umbenannte Klassen, geänderte Konfigurationsschlüssel oder angepasste Signaturen.
4. Die Hauptversion anheben, also die Symfony-Constraints in der composer.json hochsetzen und die Recipes aktualisieren.
5. Die Konfiguration angleichen, weil sich zwischen Hauptversionen Standardwerte und der Aufbau einzelner Config-Dateien ändern.
6. Das Ganze wiederholen, bis Version 7 erreicht ist.

Die Stolpersteine, die wirklich Zeit kosten

Der Framework-Kern ist selten das Problem. Aufwendig wird es an drei anderen Stellen, und die entscheiden oft über den Zeitplan.

Da sind zuerst die Bundles von Drittanbietern. Nicht jedes hält mit dem Framework Schritt. Manchmal muss man auf ein Nachfolgeprojekt wechseln, manchmal eine kleine Funktionalität selbst übernehmen, weil das Bundle nicht mehr gepflegt wird. Das klärt man am besten ganz am Anfang, sonst plant man um eine Abhängigkeit herum, die es gar nicht mehr gibt.

Dann die Verzeichnisstruktur. Ältere Projekte tragen oft noch das Layout von Symfony 3 mit sich, mit app/ und web/. Der Umbau auf die moderne Struktur mit config/, public/ und src/ läuft über Symfony Flex und ist einmalige Arbeit. Wichtig zu wissen: Erst wenn Flex integriert ist, greift auch das Recipe-System, über das sich spätere Updates deutlich leichter einspielen lassen. Bei sehr alten Projekten ist das also der Schritt, der zuerst passieren muss.

Und schließlich Doctrine. ORM und DBAL werden parallel mitgezogen und haben eigene Breaking Changes. An dieser Stelle lohnt es sich, gleich die alten Annotations auf PHP-Attribute umzustellen, statt das später noch einmal anzufassen. Von Hand muss das niemand machen: Rector erledigt genau solche Umbauten automatisiert.

Wie man den Aufwand schätzt

Eine belastbare Schätzung entsteht nicht aus der Codezeilenzahl, sondern aus vier Fragen. Wie viele Hauptversionen liegen zwischen Start und Ziel? Wie viele Drittanbieter-Bundles sind im Spiel, und werden die noch gepflegt? Gibt es Tests, die Regressionen aufdecken? Und wie weit ist die aktuelle Struktur vom modernen Standard entfernt?

Ein gepflegtes Symfony-5-Projekt mit Tests ist in überschaubarer Zeit auf 7. Ein Symfony-3-Projekt ohne Tests und mit exotischen Bundles ist ein eigenes kleines Vorhaben. Beides bekommen wir hin, nur eben nicht mit derselben Zahl darunter, und alles andere zu behaupten wäre unseriös.

Kurz gesagt

Die Migration auf Symfony 7 ist kein Sprung, sie ist eine Treppe. Wer sich an die LTS-Zwischenschritte hält und die Deprecations konsequent abarbeitet, hat an jedem Punkt eine lauffähige Anwendung und ein klares Netz. In vielen Projekten lohnt es sich, PHP- und Symfony-Upgrade sinnvoll zu verzahnen. Welche PHP-Fallstricke dabei warten, steht in unserer PHP-8-Checkliste.

Weiterführende Quellen

• Symfony: Upgrade einer Hauptversion (offizielle Doku)
• Übersicht der Symfony-Releases und LTS-Versionen
• Rector für automatisierte Symfony- und Doctrine-Umbauten
• Im Ratgeber weiterlesen: Was kostet eine PHP-Migration?