Die Anwendung entwickelt sich weiter.
Das System bleibt relevant und neue Anforderungen können nicht für eine monatelange Upgrade-Phase angehalten werden.
Alle Leistungen
Symfony-Upgrade
Symfony, Zweig für Zweig. Ohne den Sprung ins Blaue.
Gewartet werden derzeit 6.4, 7.4, 8.1 und 8.2. Symfony 5.4 bekommt nur noch Sicherheitskorrekturen; alles darunter sowie die Zweige 6.0 bis 6.3 und 7.0 bis 7.3 gar nichts mehr. Der Weg dorthin führt nicht über einen großen Sprung, sondern über eine Folge kleiner: Deprecations abbauen, dann eine Hauptversion weiter, dann von vorn. Das ist unspektakulär und der einzige Weg, bei dem man jederzeit weiß, woran man ist.
5.4 → 6.4 → 7.4Rector & Deprecationsohne AusfallEinstieg ab 950 €
Was Sie bekommen
- Bestandsaufnahme: Zielzweig, Zwischenschritte, nötige PHP-Version
- Liste der Deprecations, nach Aufwand und Fundstelle sortiert
- Bundles geprüft: was es für den Zielzweig gibt, was ersetzt werden muss
- Upgrade Zweig für Zweig, jeder Schritt einzeln produktiv
- Testnetz um die Stellen, die angefasst werden
- Übergabe an Ihr Team, schriftlich und im Gespräch
Umfang & Zusammenarbeit
Einstieg als erster Upgrade-Schritt zum Festpreis, Umsetzung nach Umfang. Auch für Anwendungen ohne Tests und ohne die Leute, die sie gebaut haben.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
Der Aufwand steckt nicht in Symfony.
Symfony selbst ist beim Upgrade der berechenbare Teil, weil das Projekt sich an eine Zusage zur Abwärtskompatibilität hält: Was entfallen soll, wird in einer Nebenversion als Deprecation markiert und erst mit der nächsten Hauptversion entfernt. Wer diese Meldungen auf der letzten Nebenversion abarbeitet, bevor er springt, hat den Sprung fast hinter sich. Ausgenommen sind als intern oder experimentell gekennzeichnete Teile und Sicherheitskorrekturen, dort kann es auch ohne Vorwarnung brechen.
Das Problem sind die Bundles. Ein Projekt mit fünfzehn Abhängigkeiten hat fünfzehn eigene Zeitpläne, und wenn eines davon seit vier Jahren keinen Commit gesehen hat, hält es die ganze Anwendung fest. Dazu kommt eigener Code, der auf Interna gesetzt hat: ein überschriebener Service, ein Event-Listener an einer Stelle, die es später nicht mehr gibt, eine Konfiguration in einem Format, das drei Versionen weiter entfallen ist.
Und darunter liegt die Sprachversion. Symfony 6.4 verlangt mindestens PHP 8.1, 7.4 mindestens 8.2, die 8er-Reihe mindestens 8.4. Wer auf PHP 7.4 steht, hat also zwei Vorhaben vor sich, nicht eines. Welches zuerst kommt, entscheidet der Befund, nicht das Bauchgefühl.
Kommt Ihnen etwas davon bekannt vor?- Die Anwendung läuft auf Symfony 5.4 oder älter und bekommt keine Fehlerkorrekturen mehr.
- Composer meldet Konflikte, sobald eine einzige Abhängigkeit angehoben wird.
- Das Log ist voll mit Deprecation-Meldungen, die niemand mehr liest.
- Ein Bundle wird nicht mehr gepflegt und blockiert den ganzen Sprung.
- Ein früherer Upgrade-Versuch wurde abgebrochen und liegt als Branch herum.
- Die PHP-Version passt nicht zum gewünschten Symfony-Zweig.
Für wen das passt
Für Symfony-Teams, die weiterliefern müssen, obwohl das Framework aufgeholt werden muss.
Das Angebot richtet sich an CTOs und Tech Leads mit einer produktiven Symfony-Anwendung auf einem älteren Release. Fachliche Entwicklung läuft weiter, gleichzeitig werden Security-Support und kompatible Pakete knapp.
Abhängigkeiten bestimmen den Aufwand.
Bundles, eigene Erweiterungen und veraltete Bibliotheken müssen in einer belastbaren Reihenfolge statt per Versionssprung behandelt werden.
Jeder Zweig soll deploybar bleiben.
Tests, Deprecations und kleine Releases schaffen einen kontrollierten Weg bis zur unterstützten Zielversion.
Was ich mache
Was dabei passiert
01
Zielzweig und Reihenfolge festlegen
Nicht jeder springt auf die neueste Fassung. Wer heute auf 5.4 steht, geht sinnvoll über 6.4 auf 7.4, und ob die 8er-Reihe das Ziel ist, hängt daran, ob PHP 8.4 in Reichweite ist. Ergebnis ist eine Kette von Zwischenschritten mit jeweils eigener Voraussetzung.
02
Deprecations vor dem Sprung abbauen
Über die Laufzeit einer Hauptversion sammeln sich die Deprecations an. Diese Meldungen werden eingesammelt, nach Häufigkeit und Aufwand sortiert und noch auf der alten Hauptversion abgearbeitet. Das ist der Teil, der das eigentliche Upgrade klein macht: Jede Änderung lässt sich einzeln ausrollen, während die Anwendung auf der bisherigen Version weiterläuft. Risikofrei ist das nicht, es wird produktiver Code angefasst, aber es ist in kleine, einzeln prüfbare Schritte zerlegbar.
03
Bundles prüfen und ersetzen
Je Abhängigkeit: Gibt es sie für den Zielzweig, wird sie noch gepflegt, und was tritt an ihre Stelle, wenn nicht. Aufgegebene Bundles bekommen eine gepflegte Alternative, eine schmale eigene Umsetzung dessen, was tatsächlich benutzt wird, oder eine Grenze, hinter der sie eingekapselt weiterlaufen.
04
Sicherheitsnetz, wo Tests fehlen
Wo keine Tests existieren, entstehen Characterization Tests für die Wege, die angefasst werden und an denen Geld hängt. Sie halten fest, was die Anwendung heute tut, unabhängig davon, ob es richtig ist.
05
Eine Hauptversion nach der anderen
Jeder Zweig ist ein eigener Schritt mit eigenem Rückweg, und jeder geht einzeln in Produktion. Zwei Hauptversionen in einem Zug zu nehmen spart auf dem Papier Zeit und kostet sie beim ersten Fehler zurück, weil niemand mehr sagen kann, aus welchem Sprung er stammt.
06
Danach: nicht wieder zurückfallen
Zum Abschluss die Dinge, die den Abstand künftig klein halten: Deprecation-Meldungen als Fehler in der Pipeline, statische Analyse, automatische Abhängigkeitsprüfung, und eine Notiz, wann der jetzt gewählte Zweig aus der Wartung fällt.
Steht Ihr Symfony auf einem Zweig ohne Wartung?
Schicken Sie mir die Eckdaten. Sie bekommen die Kette der Zwischenschritte und den Aufwand, bevor Sie etwas beauftragen.
Ablauf
Wie das abläuft
Vier Schritte, und nach dem ersten kennen Sie den Weg samt Zwischenstationen. Kein Schritt setzt voraus, dass Sie den nächsten beauftragen.
SCHRITT 01
Eckdaten und Zugang
Symfony-Version, PHP-Version, ungefähre Größe, Testabdeckung, Liste der Bundles. Ein Lesezugriff auf das Repository genügt für den Befund.
SCHRITT 02
Befund
Zielzweig, Zwischenschritte, Deprecations nach Aufwand, Bundles nach Ersetzbarkeit. Damit können Sie entscheiden, auch gegen mich.
SCHRITT 03
Aufräumen und absichern
Deprecations im aktuellen Zweig abarbeiten, Testnetz spannen. Beides passiert, bevor die erste Versionsnummer steigt.
SCHRITT 04
Zweig für Zweig ausrollen
Ein Sprung, ein Rollout, ein Rückweg. Zum Schluss Prüfungen in der Pipeline und die Übergabe.
Einstieg
Erster Upgrade-Schritt. Ab 950 €
Startpreis. Die weiteren Zwischenschritte werden nach Umfang angeboten, zum Festpreis, bevor sie beginnen.
Kein Gutachten, sondern ein Anfang: Der erste Sprung Ihrer Upgrade-Kette wird in einem eigenen Zweig ausgeführt. Was Rector dabei nicht erledigt, steht danach als gemessene Liste da, nicht als Schätzung.
Was Sie bekommen
- Zielzweig und Kette der Zwischenschritte, mit nötiger PHP-Version je Stufe
- Der erste Sprung mit Rector in einem eigenen Zweig ausgeführt, jeder Lauf ein eigener Commit
- Was danach offen bleibt, als gemessene Liste mit Fundstelle und Aufwand
- Deprecations gesammelt, nach Häufigkeit und Aufwand sortiert
- Bundle-Prüfung: verfügbar, gepflegt, ersetzbar
- Einschätzung zu Testabdeckung und nötigem Sicherheitsnetz
- Eine Stunde Besprechung der Ergebnisse, Aufzeichnung auf Wunsch
Was Sie nicht bekommen
- Keine vollständige Upgrade-Kette. Der Zweig trägt den ersten Sprung, nicht alle
- Keine Behebung dessen, was nach dem Rector-Lauf offen bleibt
- Kein Refactoring, keine neuen Funktionen
- Kein PHP-Upgrade, das ist ein eigenes Vorhaben mit eigener Seite
- Keine Prüfung der Infrastruktur, dafür gibt es die AWS-Kostenanalyse
- Keine Sicherheitsprüfung im Sinne eines Penetrationstests
- Lesezugriff auf das Repository genügt. Der Upgrade-Zweig entsteht daneben, Ihr Hauptzweig bleibt unangetastet
- Der Zweig gehört Ihnen und bleibt Ihnen, auch wenn Sie sich gegen die weitere Umsetzung entscheiden
- Preis netto, zuzüglich Umsatzsteuer
- Ab etwa 200.000 Zeilen oder mehreren Anwendungen wird der Umfang vorher abgestimmt
- Der Betrag wird angerechnet, wenn Sie die Umsetzung anschließend beauftragen
- Sie sind zu nichts verpflichtet. Manche Kunden führen die Kette von dort aus selbst weiter, und das ist ein gültiges Ergebnis
Das Ergebnis
Was danach anders ist
Wieder in der Wartung
Fehlerkorrekturen und Sicherheitsfixes kommen wieder, und die Frage im nächsten Audit ist beantwortet.
Abhängigkeiten wieder beweglich
Ein neues Paket lässt sich installieren, ohne dass drei andere blockieren. Das war vorher der eigentliche Stillstand.
Der nächste Sprung ist klein
Mit Deprecations als Fehler in der Pipeline sammelt sich nichts mehr an. Der nächste Hauptversionssprung ist dann Routine statt Projekt, weil die Arbeit laufend passiert ist statt gebündelt am Ende.
Ein Netz, das bleibt
Die Tests, die für das Upgrade entstanden sind, gehören danach Ihnen und sichern jede weitere Änderung ab.
Eingesetzte Technologien
Womit ich arbeite
Framework
- Symfony 6.4
- Symfony 7.4
- Symfony 8.1
- Flex
Komponenten
- Doctrine ORM
- Twig
- Messenger
- Security
- Console
Sprache
- PHP 8.1
- PHP 8.2
- PHP 8.3
- PHP 8.4
Analyse
- Rector
- PHPStan
- Psalm
- PHP-CS-Fixer
Tests
- PHPUnit
- Panther
- Pest
- Xdebug
Pakete
- Composer
- Packagist
- Composer Audit
- Dependabot
Daten
- MySQL
- MariaDB
- PostgreSQL
- Valkey / Redis
Ausrollen
- Docker
- GitHub Actions
- GitLab CI
- AWS
Nachweis
PHP und Zend Framework zertifiziert.
Die meisten Anbieter kennen das Ziel. Bei einem alten System entscheidet aber, ob jemand auch die Ausgangslage kennt: warum eine Stelle so geschrieben ist, wie sie geschrieben ist, und was ihre Ablösung anrichtet. Zend Technologies gibt es unter dem Namen nicht mehr, die Prüfungen von damals also auch nicht. Für die Datenbankseite kommt eine Oracle-Zertifizierung auf MySQL 5 dazu, denn dort liegen die stilleren Fallen: Zeichensätze, Sortierregeln und ein Strict Mode, der bisher Geduldetes ablehnt.
Mit wem Sie es zu tun haben
Direkt mit mir als Freelancer. Keine Agentur dazwischen.
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, und Symfony begleitet mich seit den frühen Fassungen. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
- 20+Jahre Softwareentwicklung
- 50+erfolgreiche Projekte
- 2003seit diesem Jahr remote im Einsatz
Häufige Fragen
Häufige Fragen zum Symfony-Upgrade
Welche Symfony-Versionen werden noch gewartet?
Stand August 2026 werden 6.4, 7.4, 8.1 und 8.2 gewartet. Symfony 5.4 bekommt nur noch Sicherheitskorrekturen, alles darunter sowie die Zweige 6.0 bis 6.3 und 7.0 bis 7.3 gar nichts mehr. Als Ziel empfehle ich in der Regel den aktuellen LTS-Zweig 7.4: lange Unterstützung, und die Bibliotheken haben nachgezogen.
Kann man mehrere Versionen auf einmal überspringen?
Technisch ja, praktisch selten sinnvoll. Symfony entfernt nur mit einer Hauptversion, und angekündigt wird das über die Nebenversionen davor. Genau deshalb lohnt der Zwischenhalt: Wer auf der letzten Nebenversion einer Hauptversion deprecation-frei ist, springt fast überraschungsfrei. Wer zwei Hauptversionen in einem Zug nimmt, überspringt diese Station zweimal und weiß bei einem Fehler nicht mehr, aus welchem Sprung er stammt.
Was kostet ein Symfony-Upgrade?
Der erste Upgrade-Schritt kostet ab 950 Euro netto und sagt Ihnen, was die Umsetzung kostet. Die Spanne ist groß und hängt nicht an der Codegröße, sondern an zwei anderen Zahlen: wie viele Bundles aufgegeben sind, und ob es Tests gibt. Die Umsetzung wird danach zum Festpreis angeboten.
Was, wenn ein Bundle nicht mehr gepflegt wird?
Das ist der häufigste harte Fall. Drei Antworten kommen infrage: eine gepflegte Alternative mit derselben Aufgabe, eine eigene schmale Umsetzung genau dessen, was Sie tatsächlich benutzen, oder eine Grenze, hinter der das alte Bundle eingekapselt weiterläuft, bis es abgelöst ist. Welche trägt, steht im Befund samt Aufwand.
Brauche ich zuerst ein PHP-Upgrade?
Oft ja, denn die Zweige setzen Mindestversionen: 6.4 braucht PHP 8.1, 7.4 braucht 8.2, die 8er-Reihe braucht 8.4. Beides gleichzeitig zu wechseln ist der zuverlässigste Weg, einen Fehler nicht mehr zuordnen zu können. Welcher Schritt zuerst kommt, hängt am Ausgangsstand und steht im Befund.
Muss die Anwendung dafür angehalten werden?
Nein. Das Abarbeiten der Deprecations passiert im laufenden Zweig und ist ohnehin unsichtbar. Jeder Versionssprung danach ist ein eigener Rollout mit eigenem Rückweg, wie jede andere Änderung auch.
Wir haben einen abgebrochenen Upgrade-Branch. Hilft der?
Meistens als Fundgrube, selten als Grundlage. Er zeigt, woran es beim letzten Mal gescheitert ist, und das ist eine wertvolle Abkürzung im Befund. Weiterarbeiten würde ich darauf nur, wenn er jünger als ein paar Monate ist; sonst ist der Abstand zum Hauptzweig größer als der Gewinn.
Machen Sie auch das PHP-Upgrade und die Bundles zusammen?
Ja, aber als getrennte Schritte in einer abgestimmten Reihenfolge, nicht als ein Vorhaben. Genau diese Reihenfolge ist der Teil, für den man jemanden holt: Sie entscheidet, ob das Ganze drei Wochen oder drei Monate dauert.
Weitere Leistungen
Womit ich sonst helfe.
Legacy-Modernisierung
Gewachsene Systeme schrittweise modernisieren: Strangler-Fig statt Rewrite, laufender Betrieb unangetastet, jeder Schritt umkehrbar.
Mehr erfahrenPHP-Upgrade & Migration
Von PHP 5.6, 7 oder frühem 8 auf eine unterstützte Version, im laufenden Betrieb: Kompatibilitätsanalyse, Testnetz, automatisierte Umschreibung, schrittweiser Rollout.
Mehr erfahrenZend Framework
ZF1, ZF2 oder ZF3 auf einen Stand bringen, der wieder gewartet wird: Laminas für ZF2 und ZF3, schrittweise Ablösung für ZF1.
Mehr erfahren