Sie betreiben eine Anwendung auf Symfony 2.8. Sie läuft. Sie verdient Geld. Und trotzdem beschleicht Sie beim Blick auf die composer.json ein ungutes Gefühl, weil dort eine Version steht, deren offizieller Support Ende 2018 endete und deren Security-Fixes Ende 2021 ausgelaufen sind. Die Frage ist berechtigt, aber die naheliegende Antwort ist meistens falsch. "Dann bauen wir es eben neu" ist der teuerste und riskanteste Weg, den Sie einschlagen können.
Ein System, das seit Jahren im Produktivbetrieb funktioniert, ist kein Altlast-Müll. Es ist der Beweis, dass Ihre Fachlogik korrekt ist, dass Randfälle abgefangen wurden und dass sich reale Nutzer daran gewöhnt haben. Genau dieses Wissen steckt nicht in der Symfony-Version, sondern in Ihrem eigenen Code. Und genau dieses Wissen werfen Sie bei einer Neuentwicklung als Erstes über Bord.
Warum Sie Symfony 2.8 nicht ewig weiterbetreiben können
Symfony 2.8 war die letzte Version der 2.x-Reihe und ein Long-Term-Support-Release. Der Sicherheitssupport ist seit November 2021 beendet. Das bedeutet konkret: Neue CVEs im Framework selbst werden nicht mehr gepatcht. Sie sind auf Eigenleistung oder Backports angewiesen.
Das eigentliche Problem ist aber selten Symfony allein. Es ist der Rattenschwanz:
- PHP-Version: Symfony 2.8 läuft offiziell nur bis PHP 7.x sauber. Sie hängen damit auf einer PHP-Version fest, die selbst keine Security-Fixes mehr bekommt.
- Abhängigkeiten: Doctrine, SwiftMailer, Twig 1.x und Dutzende Bundles sind auf alten Ständen eingefroren. SwiftMailer ist offiziell abgekündigt.
- Ökosystem: Neue Bibliotheken setzen PHP 8 voraus. Sie können nichts Modernes mehr integrieren, ohne gegen Wände zu laufen.
Der Betrieb ist also nicht akut kaputt, aber er wird jeden Monat teurer und fragiler. Das ist der Grund, warum Sie Symfony 2.8 migrieren sollten, bevor ein Vorfall die Entscheidung für Sie trifft.
Warum Neuentwicklung fast immer die falsche Antwort ist
Der Reflex ist verständlich: Der Code ist alt, also machen wir es "richtig", modern, sauber, von Grund auf neu. In der Praxis unterschätzt dieser Plan drei Dinge.
Erstens die schiere Menge an unsichtbarer Fachlogik. Jede Sonderregel, jeder Steuerfall, jede Ausnahme für einen bestimmten Kundentyp, die über Jahre in Ihre Controller und Services gewandert ist, muss neu entdeckt, verstanden und nachgebaut werden. Vieles davon ist nirgends dokumentiert außer im laufenden Code.
Zweitens die Doppelbelastung. Während das neue System entsteht, muss das alte weiterlaufen und weiter gewartet werden. Sie bezahlen zwei Systeme gleichzeitig, oft über Monate oder Jahre.
Drittens das Risiko. Ein Big-Bang-Rewrite ist erst am Tag der Umstellung testbar. Ein schrittweises Upgrade ist an jedem einzelnen Tag lauffähig und deploybar. Die Fachlogik funktioniert bereits. Das Problem ist fast nie die Logik, sondern der Rahmen drumherum: das Framework, die veralteten Bibliotheken, die PHP-Version.
Wie Sie Symfony 2.8 migrieren, ohne alles wegzuwerfen
Der belastbare Weg führt über inkrementelle Upgrades entlang des offiziellen Symfony-Pfads. Die grobe Route lautet 2.8 nach 3.4 (LTS), dann nach 4.4 (LTS), dann nach 5.4 (LTS) und weiter Richtung 6.4 oder 7.x. Jede dieser LTS-Versionen ist ein stabiler Haltepunkt, an dem Sie pausieren und produktiv bleiben können.
Der entscheidende Hebel ist die Kompatibilitätsschicht zwischen 2.8 und 3.4. Symfony 3.4 und 2.8 teilen sich weitgehend dieselbe API, deprecated aber vieles. Ihr erster Job ist deshalb nicht der Versionssprung, sondern das systematische Beseitigen von Deprecations.
- Deprecations sichtbar machen. Aktivieren Sie den Deprecation-Layer und lassen Sie Ihre Testsuite oder einen Crawl über die Anwendung laufen. Jede Meldung ist eine konkrete Stelle, die Sie vor dem Sprung reparieren.
- Auf 3.4 heben. Ist die Anwendung deprecation-frei, ist der Schritt auf 3.4 meist überraschend klein. Danach sind Sie auf einer LTS-Version mit Support.
- PHP nachziehen. Ab Symfony 4/5 heben Sie PHP schrittweise auf 8.x. Das ist oft der aufwendigere Teil als das Framework selbst, weil sich PHP-interne Verhalten geändert haben.
- Bundles ersetzen. SwiftMailer weicht dem Symfony Mailer, alte Third-Party-Bundles werden durch gepflegte Nachfolger oder eigenen Code ersetzt.
- Konfiguration modernisieren. Der Wechsel von der alten Verzeichnisstruktur (
app/) auf Flex-Struktur (config/,src/) kann als eigener Schritt erfolgen, nicht zwingend gleichzeitig.
Welche Rolle spielen automatisierte Werkzeuge wie Rector?
Kann ich die Migration automatisieren? Teilweise. Werkzeuge wie Rector können viele mechanische Umschreibungen erledigen, etwa Namespace-Anpassungen, geänderte Methodensignaturen oder PHP-Syntax-Modernisierungen. Sie ersetzen aber kein Verständnis der Fachlogik.
Rector nimmt Ihnen die stumpfe Fleißarbeit ab und reduziert menschliche Fehler bei repetitiven Änderungen. Was Rector nicht kann: entscheiden, ob ein deprecated Verhalten in Ihrem Fachkontext überhaupt korrekt genutzt wurde. Diese Urteile bleiben Handarbeit. Die Kombination aus automatisierten Regeln für die Masse und gezielter Handarbeit für die kniffligen Stellen ist in der Regel am effizientesten.
Ohne Testnetz kein sicheres Upgrade
Der häufigste Grund, warum Upgrades scheitern oder in Angst-Deployments enden, ist fehlende Testabdeckung. Wenn Sie nicht wissen, ob nach dem Versionssprung noch alles funktioniert, wird jeder Schritt zum Blindflug.
Die gute Nachricht: Sie brauchen keine 100 Prozent Coverage. Sie brauchen Tests für die kritischen Pfade, also die Abläufe, deren Ausfall echtes Geld oder Vertrauen kostet. Bezahlvorgang, Login, zentrale Datenexporte. Investieren Sie zuerst in Characterization-Tests, die das aktuelle Verhalten festschreiben, auch wenn es nicht perfekt ist. Diese Tests sind Ihr Sicherheitsnetz für jeden einzelnen Migrationsschritt.
Der ehrliche Praxis-Tipp
Fangen Sie nicht mit dem Versionssprung an, sondern mit einer Bestandsaufnahme. Lassen Sie den Deprecation-Layer laufen, listen Sie Ihre Bundles mit ihrem Support-Status auf und identifizieren Sie die drei kritischsten Fachabläufe. Diese eine Nachmittagsarbeit sagt Ihnen mehr über Aufwand und Risiko als jede Schätzung aus dem Bauch. Meistens stellt sich dabei heraus: Es ist weniger, als Sie befürchtet haben, und Ihre Fachlogik bleibt fast vollständig erhalten.
Genau bei dieser Bestandsaufnahme und dem schrittweisen Upgrade unterstützt LegacyWerk, wenn Sie den Weg nicht allein gehen möchten.
