"Was kostet ein Symfony-Upgrade?" ist die Frage, die ich am häufigsten höre — und ehrlich beantwortet lautet sie: Es kommt darauf an. Das klingt nach einer Ausrede, ist aber der einzige seriöse Startpunkt. Denn die Spanne reicht von wenigen Tagen bis zu mehreren Monaten, und wer Ihnen ohne Blick auf den Code eine Pauschale nennt, rät. In diesem Artikel zerlege ich die tatsächlichen Kostentreiber, damit Sie eine Schätzung selbst plausibilisieren können.
Wovon hängen die Symfony Upgrade Kosten konkret ab?
Die Symfony Upgrade Kosten werden nicht von der Symfony-Version bestimmt, sondern davon, wie viel fremder Code an dieser Version klebt. Ein sauber gebautes Symfony 4.4 auf 6.4 zu heben ist Fleißarbeit. Ein Symfony-2-Projekt mit selbstgebautem Dependency Injection, gepatchten Vendor-Dateien und Business-Logik in Twig-Templates ist ein anderes Kaliber.
Die wichtigsten Faktoren, die den Aufwand nach oben oder unten ziehen:
- Wie viele Major-Versionen liegen dazwischen? Von 5.4 auf 6.4 ist ein anderer Sprung als von 2.8 auf 6.4. Jeder Major-Wechsel bringt eigene Deprecations.
- Zustand der Abhängigkeiten: Bundles, die es nicht mehr gibt oder die aktuelle Symfony-Versionen nicht unterstützen, müssen ersetzt oder ausgebaut werden.
- PHP-Version: Ein Symfony-Upgrade zieht fast immer ein PHP-Upgrade mit sich (von 7.x auf 8.2+). Typisierung, entfernte Funktionen und geänderte Fehlerbehandlung erzeugen eigenen Aufwand.
- Testabdeckung: Ohne Tests ist jedes Upgrade ein Blindflug. Fehlende Tests bedeuten manuelles Durchklicken oder das Nachrüsten von Tests — beides kostet.
- Eigenmächtige Vendor-Änderungen: Direkt editierte Dateien im
vendor/-Verzeichnis gehen bei jedem Update verloren und sind oft undokumentiert.
Warum die alte Anwendung meist besser ist als ihr Ruf
Ein System, das seit acht Jahren im Produktivbetrieb Rechnungen schreibt, Bestellungen abwickelt oder Verträge verwaltet, ist kein technischer Schrott. Es ist der Beweis, dass die Fachlogik korrekt ist. Diese Logik ist über Jahre an der Realität getestet worden — an echten Kunden, echten Sonderfällen, echten Edge-Cases, die niemand mehr im Kopf hat.
Das Problem ist fast nie diese Fachlogik. Das Problem ist der Code drumherum: das veraltete Framework, die verwobene Struktur, die fehlende Trennung von Zuständigkeiten. Genau das lässt sich modernisieren, ohne die funktionierende Substanz wegzuwerfen. Wer das Upgrade angeht, kauft die bewährte Logik gewissermaßen mit — anstatt sie teuer neu zu erfinden.
Was ist günstiger — Upgrade oder Neuentwicklung?
In der Regel ist das Upgrade deutlich günstiger und risikoärmer als eine Neuentwicklung. Eine Neuentwicklung bedeutet, jahrelang gewachsene Fachlogik komplett neu zu implementieren — inklusive aller Sonderfälle, die niemand mehr vollständig kennt.
Der teure Trugschluss bei der Neuentwicklung liegt selten in der offensichtlichen Funktion. Er liegt in den unsichtbaren Regeln: die Rabattstaffel für einen bestimmten Kundentyp, die Sonderbehandlung bei Stornos, das Rundungsverhalten, das seit Jahren so und nicht anders sein muss. Diese Regeln stehen in keinem Lastenheft. Sie stehen im alten Code. Bei einer Neuentwicklung entdecken Sie sie einzeln wieder — meist dann, wenn ein Kunde sich beschwert.
Eine Neuentwicklung kann sinnvoll sein, wenn sich das Geschäftsmodell grundlegend geändert hat oder die Anwendung nur einen Bruchteil dessen leistet, was sie soll. Aber sie ist fast nie die günstige Option, als die sie gern verkauft wird. Wenn die Logik funktioniert, ist das Upgrade der ehrlichere Weg.
Wie läuft ein Symfony-Upgrade in der Praxis ab?
Ein strukturiertes Upgrade läuft schrittweise ab und meidet den großen Sprung ins Ungewisse. Der bewährte Ablauf:
- Bestandsaufnahme: Welche Symfony- und PHP-Version läuft aktuell? Welche Bundles sind im Einsatz, welche werden nicht mehr gepflegt?
- Sicherheitsnetz schaffen: Bevor irgendetwas geändert wird, braucht es Tests — zumindest für die kritischen Pfade wie Bezahlung, Login und Datenexport.
- Deprecations auflösen: Symfony meldet veraltete Aufrufe zur Laufzeit. Diese werden Version für Version abgearbeitet, nicht erst am Ende.
- Version für Version hochziehen: Nicht von 3.4 direkt auf 6.4, sondern über die Zwischenversionen. Das hält jeden Schritt überschaubar und rückverfolgbar.
- PHP nachziehen: Parallel oder danach die PHP-Version anheben und die dabei auftretenden Fehler bereinigen.
Dieser inkrementelle Weg ist der Grund, warum ein Upgrade planbar ist. Sie sehen nach jedem Schritt, ob das System noch läuft. Ein Big-Bang-Rewrite gibt Ihnen dieses Feedback erst am Ende — wenn es für Korrekturen teuer geworden ist.
Welche versteckten Kostentreiber übersehen die meisten?
Die offensichtlichen Aufwände plant fast jeder ein. Teuer wird es an den Stellen, die im ersten Angebot gern fehlen:
- Fehlende Tests: Ohne automatisierte Tests wird jeder Upgrade-Schritt manuell verifiziert. Das ist der größte einzelne Kostentreiber, den ich in der Praxis sehe.
- Abgekündigte Third-Party-Bundles: Ein Bundle, das seit Jahren kein Update mehr bekommen hat, muss ersetzt oder durch eigenen Code abgelöst werden.
- Datenbank und Doctrine: Änderungen an Doctrine ORM über die Major-Versionen hinweg betreffen Mappings, Query-Verhalten und Migrations — kein Selbstläufer.
- Sicherheitskomponente: Der Security-Layer von Symfony wurde über die Versionen grundlegend umgebaut. Authentifizierung ist oft der aufwändigste Einzelteil.
- Frontend-Kopplung: Wenn Assets über veraltete Bundles ausgeliefert werden, hängt am Upgrade oft auch ein Stück Frontend-Arbeit.
Wie bekomme ich eine belastbare Kostenschätzung?
Eine belastbare Schätzung entsteht erst nach einem kurzen technischen Audit — nicht am Telefon. Konkret braucht es einen Blick auf die composer.json, die aktuelle Symfony- und PHP-Version, den Stand der Tests und eine Stichprobe im Code, um die Struktur einzuschätzen.
Verlangen Sie von jedem Anbieter, dass er die Schätzung begründet: Welche Bundles sind das Problem? Wie viele Deprecations meldet die Anwendung? Gibt es Tests? Wenn diese Fragen nicht beantwortet werden, ist die Zahl geraten. Eine seriöse Schätzung nennt außerdem eine Spanne und die Annahmen dahinter — nicht einen einzelnen Betrag mit der Suggestion falscher Präzision.
Praxis-Tipp zum Schluss
Der ehrlichste Rat, den ich geben kann: Fangen Sie nicht mit dem Upgrade an, sondern mit den Tests der drei bis fünf wichtigsten Abläufe. Diese Investition brauchen Sie ohnehin, sie senkt das Risiko sofort — und nach dem Schreiben dieser Tests haben Sie meist ein sehr viel klareres Bild davon, wo die eigentlichen Kosten liegen. Wer die Substanz seiner Anwendung respektiert, modernisiert sie günstiger, als er sie neu bauen könnte.
Bei genau solchen Bestandsaufnahmen und Upgrades von Legacy-Symfony-Anwendungen unterstützt LegacyWerk — mit dem Ziel, das Funktionierende zu erhalten statt es leichtfertig zu ersetzen.
