Een Symfony upgrade is het bijwerken van je applicatie naar een nieuwere Symfony version, inclusief de bundles, de PHP-versie en je eigen code. Het klinkt als een technische klus, maar het is vooral een bedrijfsrisico dat je beheerst of laat liggen. Een versie die end of life is krijgt geen securityfixes meer. Elke maand dat je wacht, wordt de stap groter.
Wij nemen regelmatig Symfony-applicaties over die al jaren niet zijn bijgewerkt. Het patroon is bijna altijd hetzelfde: het werkt, dus niemand raakt het aan, tot een hostingpartij een oude PHP-versie uitzet of een pentest een lek vindt. Dit artikel helpt je om voor die situatie uit te komen.
Symfony versies en end of life (per oktober 2026)
Symfony releases verschijnen elk halfjaar: in mei en november komt er een nieuwe minor-versie uit. Elke laatste minor van een major, zoals 6.4 en 7.4, is een LTS-versie met langere ondersteuning. Gewone versies worden maar acht maanden onderhouden. Dit is de stand van de belangrijkste Symfony versies volgens symfony.com/releases, per oktober 2026:
| Versie | Type | Minimale PHP | Bugfixes tot | Securityfixes tot |
|---|---|---|---|---|
| 8.1 | standaard | 8.4 | januari 2027 | januari 2027 |
| 8.0 | standaard | 8.4 | juli 2026 (verlopen) | juli 2026 (verlopen) |
| 7.4 | LTS | 8.2 | november 2028 | november 2029 |
| 6.4 | LTS | 8.1 | november 2026 | november 2027 |
| 5.4 | LTS | 7.2.5 | november 2024 (verlopen) | februari 2029 |
| 4.4 en ouder | – | – | verlopen | verlopen |
Symfony 8.2 staat gepland voor november 2026. Draai je nog op 6.4, dan stoppen de bugfixes binnenkort en is het een goed moment om de stap naar 7.4 te plannen.
Wat betekent Symfony end of life voor je applicatie?
Symfony end of life betekent dat er geen patches meer komen. Je applicatie blijft gewoon werken, maar een nieuw ontdekt lek in de versie die je gebruikt wordt niet meer gedicht. Daarnaast lopen ook de bundles en libraries om je applicatie heen achter, en moet je vaak op een oude PHP-versie blijven die zelf ook niet meer ondersteund wordt. Dat raakt je beveiliging, je hosting en de kosten van elke volgende wijziging.
Wanneer moet je een Symfony upgrade plannen?
Een paar signalen dat het tijd is:
- Je versie staat in de tabel als verlopen of verloopt binnen een jaar.
- Je hostingpartij kondigt aan dat een PHP-versie verdwijnt.
- Nieuwe functies duren steeds langer omdat bundles niet meer meegaan.
- Composer weigert updates door conflicten tussen packages.
- Er is geen developer meer die de applicatie goed kent.
Plan een upgrade bij voorkeur als vast onderdeel van onderhoud, niet als noodgreep. Wie elke LTS meeneemt, doet steeds een overzichtelijke stap in plaats van één grote sprong.
Stappenplan: Symfony upgraden naar een nieuwe major-versie
De officiële Symfony-documentatie beschrijft het upgraden in vier stappen. Dit is hoe wij dat in de praktijk aanpakken.
1. Maak een inventarisatie van je project
Bekijk welke Symfony version, PHP-versie en bundles je project gebruikt. Controleer per bundle of er een versie is die de nieuwe Symfony ondersteunt, en kijk in de openstaande issues van die bundle of anderen al tegen problemen aanliepen. Een verlaten bundle is vaak het grootste obstakel in een project, niet Symfony zelf. Leg ook vast welke tests er zijn en hoe je deployt.
2. Upgrade eerst naar de laatste minor
Ga binnen je huidige major naar de laatste minor (bijvoorbeeld 6.4). Daar zie je alle deprecations: code die in de volgende major verdwijnt. Je vindt ze in de web debug toolbar, de profiler en via de PHPUnit bridge (symfony/phpunit-bridge), die aan het einde van een testrun een overzicht toont.
3. Los alle deprecations op
Werk de deprecations één voor één weg, ook die uit bundles van derden. Tools zoals Rector kunnen een deel van de wijzigingen automatisch doen, maar controleer het resultaat altijd zelf. Pas als je testrun deprecation-vrij is, ben je klaar voor de volgende stap.
4. Werk composer.json bij en update
Zet de symfony/* requirements in composer.json (het JSON-bestand met al je afhankelijkheden) op de nieuwe versie en draai composer update "symfony/*". Bij conflicten helpt --with-all-dependencies. Leeg daarna de cache door de map var/cache te verwijderen.
5. Update de recipes
Met composer recipes zie je welke Symfony Flex-recipes een update hebben, met composer recipes:update voer je ze door. Elke update komt als patch binnen; conflicten los je op zoals een gewone git-merge.
6. Lees de UPGRADE-notes en test
Lees het UPGRADE-X.0.md-bestand van de nieuwe versie voor wijzigingen die niet als deprecation zichtbaar waren. Test daarna op een staging-omgeving met echte data en zet pas dan live, met een rollbackplan klaar.
Van een oude Symfony version naar de nieuwste: de tussenstappen
Sta je nog op Symfony 3.4 of 4.4? Spring dan niet in één keer naar de nieuwste versie. Upgrade per major via de LTS: 3.4 → 4.4 → 5.4 → 6.4 → 7.4. Op elke tussenstop heb je een werkende applicatie die je kunt testen en eventueel live kunt zetten. Neem de PHP-versie mee: veel tussenstops vragen een nieuwere PHP-versie, en andersom. Lees daarvoor ook ons artikel over een PHP upgrade plannen.
Bij heel oude applicaties zit de echte vertraging zelden in Symfony zelf. Het zit in verouderde bundles, ontbrekende tests en code die nooit is opgeruimd. Dat is technische schuld, en die maak je het beste eerst zichtbaar voordat je een planning maakt.
Wat maakt een Symfony upgrade groot of klein?
De omvang van een upgrade hangt vooral af van:
- Afstand: hoeveel major-versies je achterloopt.
- Bundles: hoeveel externe packages je gebruikt en of die nog onderhouden worden.
- Tests: met een goede testset kun je sneller en veiliger upgraden.
- Maatwerk: hoeveel eigen services en code direct op interne Symfony-onderdelen leunen.
- Deploy: of er een staging-omgeving en een herhaalbare deploy is.
Geen project is hetzelfde. Daarom geven we geen standaardprijs voor een upgrade, maar een inschatting op maat na een blik in de code.
Hulp bij je Symfony upgrade
Wil je weten hoe groot de stap voor jouw applicatie is? Met een codebase scan brengen we de versie, de bundles, de deprecations en de risico’s in kaart, zodat je een concreet upgradeplan hebt. Wil je het daarna uitbesteden, dan nemen onze Symfony-ontwikkelaars je upgrade en onderhoud over, ook als de oorspronkelijke developer al lang weg is.