Kort antwoord
Een Laravel-applicatie heeft onderhoud en periodieke upgrades nodig omdat elke Laravel-versie maar een beperkte supporttermijn heeft: 18 maanden bugfixes en 2 jaar securityfixes. Onderhoud houdt dependencies, beveiliging en tests actueel; een upgrade zet je applicatie over naar een nieuwe hoofdversie. Wie bijblijft, houdt de kosten laag en de software veilig — wie achterstand oploopt, betaalt later voor een grote inhaalslag.
Waarom software nooit "af" is
Een applicatie die vandaag perfect draait, is over twee jaar kwetsbaar als er niets aan gebeurt. Niet omdat de code slechter wordt, maar omdat de wereld eromheen beweegt: het Laravel-framework brengt nieuwe versies uit, PHP stopt met ondersteuning van oude versies, en de packages waarop je project leunt worden bijgewerkt of verlaten. Software onderhouden is geen teken dat er iets mis is — het is de prijs van software die live blijft.
Laravel is het meestgebruikte PHP-framework ter wereld, met meer dan 78 miljoen installaties via Composer/Packagist (2025). Juist doordat het ecosysteem zo actief is, gaat de ontwikkeling snel — en dat betekent dat stilstaan sneller achteruitgang wordt dan bij een traag bewegende stack.
De release- en supportcyclus van Laravel
Sinds Laravel 6 volgt het framework een voorspelbaar ritme: één hoofdversie per jaar, meestal in het eerste kwartaal. Volgens de officiële support policy krijgt elke release 18 maanden bugfixes en 2 jaar securityfixes. Dat venster bepaalt hoe lang je veilig op een versie kunt blijven.
| Aspect | Wat het betekent |
|---|---|
| Nieuwe hoofdversie | Jaarlijks, doorgaans Q1 |
| Bugfixes | 18 maanden na release |
| Securityfixes | 2 jaar na release |
| Praktische ondergrens | Blijf binnen het securityvenster van 2 jaar |
De actuele einddatums per versie staan in de Laravel release notes en op endoflife.date/laravel.
Vroeger kende Laravel aparte Long Term Support (LTS)-releases, maar sinds het jaarlijkse ritme geldt de bovenstaande policy voor élke versie. Het idee van "één keer bouwen en tien jaar niet omkijken" bestaat dus niet — de vraag is niet óf je upgradet, maar hoe klein je elke stap houdt.
Wat er misgaat zonder onderhoud
Achterstallig onderhoud is geen abstract risico. De concrete gevolgen stapelen zich op:
- Bekende kwetsbaarheden blijven open — Zonder securityfixes staan gepubliceerde CVE's in je framework en packages onbeschermd open. Kwetsbaarheden zijn inmiddels de grootste inbraakroute bij datalekken.
- PHP loopt zelf uit support — Laravel-versies zijn gekoppeld aan PHP-versies. Een oude Laravel dwingt je op een oude PHP die zelf geen securityupdates meer krijgt.
- Packages haken af — Community-packages ondersteunen doorgaans alleen recente Laravel-versies. Hoe verder je achterloopt, hoe meer dependencies vastlopen of onveilig worden.
- Developers worden schaars — Ontwikkelaars werken liever op actuele versies. Een verouderde codebase maakt het lastiger en duurder om onderhoud en doorontwikkeling te regelen.
- De inhaalslag wordt exponentieel — Vijf versies tegelijk inhalen is veel meer werk dan vijf keer één versie. Uitstel is de duurste optie, geen besparing.
Onderhoud uitstellen voelt goedkoop, tot het moment dat je in één keer moet inhalen. Dan blijkt het geen onderhoud meer maar een migratieproject.
Hoe een Laravel-upgrade verloopt
Een upgrade van de ene hoofdversie naar de volgende is bij goed onderhouden software goed te overzien. De aanpak:
1. Upgrade guide en breaking changes
Laravel publiceert bij elke versie een gedetailleerde upgrade guide met alle breaking changes. Die vormt de checklist voor de migratie.
2. Automatiseren waar het kan
Tools als Laravel Shift automatiseren een groot deel van de mechanische wijzigingen tussen versies, zodat het handwerk beperkt blijft tot wat echt aandacht nodig heeft.
3. Leunen op je testsuite
Hier valt of staat een upgrade. Met een goede suite Feature- en Unit-tests (Pest of PHPUnit) zie je direct wat er breekt na een versiesprong. Zonder tests wordt elke upgrade handmatig doorklikken en gokken — en dat is precies waar risico ontstaat. Testdekking is daarmee de grootste bepalende factor voor hoe soepel een upgrade verloopt.
4. Gefaseerd en via de OTAP-straat
Een upgrade hoort niet rechtstreeks op productie. Via ontwikkel-, test- en acceptatieomgevingen valideer je de nieuwe versie voordat gebruikers ermee werken, met een deployment die je zonder downtime kunt uitrollen.
Onderhoud versus upgrade
Het loont om twee dingen uit elkaar te houden. Onderhoud is doorlopend werk: dependency-updates, securitypatches, kleine bugfixes en verbeteringen. Een upgrade is de stap naar een nieuwe hoofdversie. De twee versterken elkaar: doorlopend onderhoud houdt je project dicht bij de actuele versie, waardoor upgrades klein en voorspelbaar blijven. Verwaarloos je het onderhoud, dan wordt elke upgrade een op zichzelf staand project met bijbehorend risico.
Veel organisaties beleggen dit in een doorlopende samenwerking, zodat er structureel aandacht is voor beveiliging en versiebeheer in plaats van pas te acteren wanneer er iets stukloopt. Hoe je een geschikte partner voor dat onderhoud kiest, lees je in Laravel specialist inhuren.
Zelf doen of uitbesteden?
Heb je een eigen ontwikkelteam met Laravel-kennis en een goede testdekking, dan is regelmatig upgraden prima zelf te doen — het is dan routine. Ontbreekt die kennis of tijd, of gaat het om bedrijfskritische software, dan is een gespecialiseerde partner de veiligere route. Niet omdat een upgrade magisch is, maar omdat continuïteit, testcultuur en kennisborging het verschil maken tussen een soepele stap en een pijnlijke inhaalslag.
Coding Agency is Laravel-specialist en lid van de Dutch Laravel Foundation. We nemen bestaande Laravel-applicaties over, brengen ze via een code review weer bij de tijd en houden ze daarna op de actuele versie — met tests, monitoring en een voorspelbaar ritme.
Conclusie
Laravel-onderhoud en upgrades zijn geen bijzaak maar een voorwaarde voor veilige, toekomstbestendige software. De supportcyclus is helder: jaarlijks een hoofdversie, 18 maanden bugfixes, 2 jaar security. Blijf binnen dat venster, investeer in testdekking en behandel onderhoud als doorlopend proces in plaats van incident. Dan blijft elke upgrade een kleine, beheersbare stap — en voorkom je de dure inhaalslag die achterstallig onderhoud onvermijdelijk oplevert.
