Het verschil dat er echt toe doet: het releaseritme
Laravel hanteert een jaarlijkse major release, doorgaans in het eerste kwartaal. Per release krijg je 18 maanden bugfixes en 2 jaar securityfixes. Concreet voor de versies die nu in productie draaien:
- Laravel 11 (12 maart 2024): bugfixes eindigden 3 september 2025, securityfixes eindigden 12 maart 2026. Deze versie krijgt dus geen updates meer.
- Laravel 12 (24 februari 2025): bugfixes eindigden 13 augustus 2026, securityfixes lopen tot 24 februari 2027.
- Laravel 13 (17 maart 2026): bugfixes tot Q3 2027, securityfixes tot 17 maart 2028.
Symfony werkt tijdgebonden: elke zes maanden een minor (mei en november), elke twee jaar een major. Elke laatste minor van een major-cyclus is een LTS met drie jaar support. Symfony 7.4 verscheen in november 2025 als LTS met bugfixes tot november 2028 en securityfixes tot november 2029. Symfony 6.4, nog altijd veel in productie, verliest in november 2026 zijn bugfixes en houdt securityfixes tot november 2027.
Het praktische gevolg: met Laravel plan je gemiddeld elke twee jaar een upgrade in, met Symfony LTS kun je drie jaar doorbouwen zonder majorstap. Wie liever klein en vaak upgradet kiest Laravel, wie liever een keer per drie jaar een groter traject doet kiest Symfony LTS.
Wat Laravel 13 meebrengt
Laravel 13 verscheen op 17 maart 2026 en vraagt minimaal PHP 8.3, met ondersteuning tot en met PHP 8.5. Het Laravel-team koos deze cyclus bewust voor weinig breaking changes: de meeste applicaties kunnen upgraden zonder veel applicatiecode aan te passen. De belangrijkste toevoegingen:
- Een eerstepartij AI SDK met een uniforme API voor tekstgeneratie, tool-calling agents, embeddings, audio en beeld, zodat je niet vastzit aan een specifieke AI-leverancier
- Native ondersteuning voor semantisch zoeken en vectorqueries, onder meer met PostgreSQL en pgvector
- JSON:API-resources in de kern, handig als je een API bouwt die aan die specificatie moet voldoen
- Queue routing per jobklasse en uitgebreidere PHP-attributen voor middleware, autorisatie en queue-instellingen
Vooral die AI SDK is relevant als je van plan bent AI-functionaliteit in je applicatie te verwerken. Dat je van model kunt wisselen zonder je code te herschrijven past bij hoe wij AI-oplossingen bouwen: leverancierskeuze is een configuratie, geen architectuurbeslissing.
Wat Symfony 7.4 en 8.1 anders doen
Symfony is opgebouwd uit losse componenten die je ook zonder het framework kunt gebruiken. Die bouwstijl maakt Symfony populair in organisaties waar architectuur zwaarder weegt dan snelheid van opleveren: je kiest expliciet wat je gebruikt, er zit weinig magie in en de configuratie is expliciet.
De huidige stand van zaken:
- Symfony 8.1 is sinds mei 2026 de stabiele release en vraagt PHP 8.4 of hoger
- Symfony 7.4 is de LTS die je kiest als je langdurige stabiliteit wilt, met PHP 8.2 als minimum
- Symfony 8.2 staat gepland voor november 2026
Let op een detail dat vaak over het hoofd wordt gezien: Laravel 13 leunt op Symfony 8-componenten. Je bent dus ook bij Laravel afhankelijk van het Symfony-releaseritme, alleen hoef je die versies niet zelf te beheren. Dat is een reden te meer om een ervaren PHP-ontwikkelaar naar je composer-bestand te laten kijken voordat je een upgradebudget vaststelt.
Wat dit betekent voor je onderhoudsbudget
Framework en PHP-versie lopen niet gelijk op, en juist die combinatie bepaalt je onderhoudsdruk. De officiele PHP-planning:
- PHP 8.2: geen actieve support meer, securityfixes tot 31 december 2026
- PHP 8.3: securityfixes tot 31 december 2027
- PHP 8.4: actieve support tot 31 december 2026, securityfixes tot 31 december 2028
- PHP 8.5 (uitgebracht op 20 november 2025): actieve support tot 31 december 2027, securityfixes tot 31 december 2029
Draai je nu op Laravel 11 en PHP 8.2, dan staan er dus twee einddata vlak achter elkaar. Dat is geen ramp, maar wel iets om in te plannen voordat het een spoedklus wordt. Wij adviseren klanten om upgrades te behandelen als terugkerend onderhoud met een vast budget per jaar, niet als een project dat je uitstelt tot er iets misgaat. Wat zulk onderhoud ongeveer kost en hoe je dat afspreekt, leggen we uit bij maatwerk software laten ontwikkelen.
Wanneer wij Laravel kiezen
Laravel is onze standaardkeuze voor het grootste deel van de projecten die we bouwen. Dat komt door drie dingen:
- De hoeveelheid functionaliteit die je niet zelf hoeft te bouwen: authenticatie, queues, planning, caching, realtime en tegenwoordig ook AI en vectorzoeken
- De beschikbaarheid van ontwikkelaars in Nederland, wat je overdracht en continuiteit makkelijker maakt
- Het tempo waarin je van idee naar werkende software gaat, vooral relevant bij portalen, dashboards en koppelingen
Denk aan een dealerportaal, een klantportaal of een platform dat data uit meerdere systemen samenbrengt, zoals het Kaweco dealerportaal dat we bouwden. Zulke projecten hebben veel standaardwerk dat Laravel uit de doos oplost, zodat de tijd naar de bedrijfslogica gaat. Zoek je versterking op een bestaande codebase, kijk dan bij Laravel ontwikkelaar inhuren.
Wanneer Symfony de betere keuze is
Symfony kiezen we als een van deze situaties speelt:
- De organisatie heeft al Symfony-kennis in huis en beheert de applicatie straks zelf
- Het systeem moet jarenlang draaien met minimale wijzigingen, bijvoorbeeld bij een overheidsorganisatie of in een gereguleerde omgeving, en de LTS-termijn van drie jaar past bij dat beheerregime
- De architectuur vraagt om losse componenten in een bestaand landschap in plaats van een compleet framework
Wat je in beide gevallen niet moet doen: een framework kiezen omdat een ontwikkelaar er toevallig het liefst mee werkt. De vraag is wie de software over drie jaar onderhoudt en welke termijnen er dan gelden. Dat is precies het gesprek dat we in de eerste fase van een traject voeren, zoals beschreven in ons stappenplan voor software laten maken.
De keuze maken zonder later spijt
Een paar vuistregels die in de praktijk goed werken:
- Schrijf op wanneer je huidige framework- en PHP-versie uit support lopen en zet die data in de planning, niet in een document dat niemand opent
- Beoordeel niet alleen de bouwtijd, maar ook de upgradetijd over vijf jaar; bij Laravel zijn dat ongeveer drie kleinere stappen, bij Symfony LTS ongeveer twee grotere
- Houd je eigen code los van framework-specifieke trucs waar dat kan, want dan is een migratie later een kwestie van aanpassen in plaats van herbouwen
- Twijfel je tussen maatwerk en een bestaand platform, lees dan eerst low-code versus maatwerk software
Wil je hierover sparren met iemand die beide frameworks in productie heeft draaien, plan dan een technisch adviesgesprek. We kijken naar je huidige stack, de supporttermijnen die voor jou gelden en wat een realistisch upgradepad kost.