Wenn Ihre Anwendung noch auf Symfony 3.4 läuft, kennen Sie die Situation vermutlich: Das System tut seit Jahren zuverlässig seinen Dienst, die Fachlogik stimmt, die Nutzer sind zufrieden. Trotzdem hängt seit November 2021 ein unangenehmes Etikett daran. Denn seit diesem Zeitpunkt gibt es keine Sicherheitsupdates mehr vom Symfony-Team. Die Frage ist also nicht mehr ob, sondern wie und in welcher Reihenfolge Sie handeln.
Bevor wir zu den Optionen kommen, ein Wort zur Einordnung: Ein System, das über Jahre stabil läuft, ist kein Müll. Es ist der lebende Beweis, dass Ihre Geschäftslogik funktioniert. Das Problem sitzt fast nie in der Fachlogik, sondern im Code drumherum - im veralteten Framework, in aufgegebenen Bibliotheken, in der PHP-Version darunter. Das ist eine wichtige Unterscheidung, weil sie den Unterschied zwischen einer teuren Neuentwicklung und einer beherrschbaren Modernisierung ausmacht.
Was bedeutet Symfony 3.4 End of Life konkret?
Symfony 3.4 End of Life bedeutet, dass das Symfony-Team seit November 2021 keine Sicherheitspatches mehr für diese Version veröffentlicht. Der Code läuft weiter, aber neu entdeckte Schwachstellen werden nicht mehr geschlossen.
Symfony 3.4 war ein LTS-Release (Long Term Support). Veröffentlicht im November 2017, erhielt es drei Jahre Bugfixes (bis November 2020) und vier Jahre Sicherheitsfixes (bis November 2021). Diese Daten sind nicht verhandelbar und stammen direkt aus dem offiziellen Release-Prozess von Symfony.
Praktisch heißt das: Jede neue CVE, die Symfony 3.4 oder eine seiner Kernkomponenten betrifft, bleibt in Ihrer Anwendung offen. Dazu kommt fast immer ein zweites Problem. Symfony 3.4 lief auf PHP 7.x, und auch diese PHP-Versionen sind längst am Ende ihres Supports. Sie haben also in der Regel zwei EOL-Baustellen gleichzeitig: das Framework und die Sprachlaufzeit darunter.
Welche Optionen haben Sie bei Symfony 3.4 End of Life?
Es gibt im Wesentlichen vier Wege. Sie unterscheiden sich stark in Kosten, Risiko und Nachhaltigkeit.
- Upgrade innerhalb von Symfony (3.4 zu 4.4 zu 5.4 zu 6.4/7.x). Der offizielle und in den meisten Fällen sinnvollste Weg. Symfony ist auf inkrementelle Upgrades ausgelegt: Deprecations in einer Minor-Version zeigen an, was in der nächsten Major-Version wegfällt. So arbeiten Sie sich Stufe für Stufe hoch.
- Wechsel des Frameworks (etwa zu Laravel). Klingt nach einem Neuanfang, ist aber in der Praxis oft eine verkappte Neuentwicklung. Sinnvoll nur, wenn es dafür starke Gründe jenseits des EOL gibt.
- Komplette Neuentwicklung. Die teuerste und riskanteste Variante - dazu gleich mehr.
- Nichts tun und das Risiko tragen. Manchmal eine bewusste Übergangsentscheidung für ein internes Tool ohne Internetzugang. Für alles, was öffentlich erreichbar ist oder personenbezogene Daten verarbeitet, keine tragbare Option.
Warum Neuentwicklung fast nie die richtige Antwort ist
Die Versuchung ist groß: Der Code fühlt sich alt an, also baut man ihn neu. In der Praxis ist das meistens die teuerste und riskanteste Entscheidung. Bei einer Neuentwicklung werfen Sie nicht nur den veralteten Rahmen weg, sondern auch die über Jahre gewachsene, funktionierende Fachlogik. Jede Sonderregel, jeder Grenzfall, jede stille Annahme, die Ihr Team irgendwann eingebaut hat, muss neu entdeckt, neu verstanden und neu getestet werden.
Hinzu kommt: Während Sie neu bauen, muss das alte System weiterlaufen und gepflegt werden. Sie zahlen doppelt und tragen das volle Risiko, dass das neue System am Tag der Umstellung nicht exakt das tut, was das alte tat. Eine Migration hingegen behält die bewährte Logik und tauscht nur das Fundament darunter aus. Das ist planbarer und deutlich risikoärmer.
In welcher Reihenfolge sollten Sie vorgehen?
Die Reihenfolge entscheidet über Erfolg oder Chaos. Diese Schritte haben sich bewährt:
- Bestandsaufnahme und Sicherheitsnetz. Zuerst brauchen Sie Überblick: Welche Symfony-Komponenten, welche Bundles, welche PHP-Version, welche Datenbanktreiber. Und Sie brauchen Tests. Ohne automatisierte Tests ist jede Migration ein Blindflug. Wo keine Tests existieren, schreiben Sie zumindest für die kritischen Pfade welche.
- PHP-Version zuerst stabilisieren. Prüfen Sie, wie weit Sie die PHP-Version anheben können, ohne das Framework zu wechseln. Oft lässt sich hier schon eine unterstützte PHP-Version erreichen, was die akuteste Sicherheitslücke schließt.
- Deprecations in 3.4 abarbeiten. Symfony meldet im Log jede Nutzung veralteter Funktionen. Diese Warnungen sind Ihre Landkarte für den Sprung auf 4.4. Erst wenn das Log sauber ist, migrieren Sie die Major-Version.
- Schrittweise Major-Upgrades. 3.4 zu 4.4, dann 4.4 zu 5.4, dann weiter. Nicht in einem Sprung. Jede Stufe ist eine LTS-Version, auf der Sie kurz verweilen und stabilisieren können.
- Abhängigkeiten und tote Bundles ersetzen. Manche Community-Bundles wurden nie auf neuere Symfony-Versionen portiert. Diese müssen Sie ersetzen oder durch eigenen Code ablösen - oft der aufwendigste Teil.
Werkzeuge wie Rector können die mechanischen Anteile eines Upgrades automatisieren, etwa das Anpassen von Signaturen oder Annotations zu Attributes. Sie ersetzen aber kein Verständnis der Fachlogik und keine Tests.
Was ist der pragmatische Einstieg?
Wenn Sie heute nur eine Sache tun können, dann diese: Verschaffen Sie sich Klarheit über den Ist-Zustand und heben Sie die PHP-Version auf eine unterstützte Fassung, soweit das ohne Framework-Sprung möglich ist. Das entschärft die dringendste Sicherheitslage und kauft Ihnen Zeit für die geordnete Symfony-Migration. Alles Weitere folgt der oben beschriebenen Reihenfolge, in Etappen statt im großen Wurf.
Ehrlich gesagt scheitern die meisten Migrationen nicht an der Technik, sondern an fehlender Vorbereitung: keine Tests, kein Überblick, zu großer erster Schritt. Wenn Sie genau vor dieser Aufgabe stehen und einen erfahrenen Blick von außen brauchen, ist das der Bereich, in dem ich mit LegacyWerk täglich unterstütze.
