Kører din applikation på Laravel 11 eller ældre, modtager den ikke længere sikkerhedsopdateringer — Laravel 11's sikkerhedssupport udløb 12. marts 2026. Det betyder, at nye sårbarheder i frameworket ikke bliver lukket i din version, uanset hvor alvorlige de er.
Det er ikke et teoretisk problem. Det er en forretningsrisiko med GDPR-konsekvenser, og den vokser for hver måned. Den gode nyhed: en Laravel-opgradering er et velafprøvet, trinvist forløb — ikke en genopbygning. Her er, hvordan jeg griber det an som konsulent i Laravel udvikling.
Laravel udgiver én major-version om året. Hver version får fejlrettelser i 18 måneder og sikkerhedsrettelser i 2 år — herefter er den reelt udgået:
Sikkerhed: når en sårbarhed offentliggøres, patches den kun i supporterede versioner. Kører du en udgået version, er offentliggørelsen i praksis en manual til at angribe dit system.
Pakke-økosystemet trækker sig: de pakker, din applikation afhænger af, dropper løbende understøttelsen af gamle Laravel-versioner. Til sidst kan du hverken opdatere pakker eller installere nye — og små fejlrettelser bliver umulige.
Prisen vokser med afstanden: et spring på én version er en overskuelig opgave; fire versioner plus en gammel PHP er et projekt. Hver udskudt opgradering gør den næste dyrere.
Udviklere siger nej tak: dygtige folk vil ikke arbejde i forældede kodebaser. Jo længere du venter, desto sværere bliver det at få kvalificeret hjælp — det ser jeg jævnligt, når jeg overtager projekter fra tidligere leverandører.
Det afhænger af to ting: hvor mange versioner der skal springes, og hvor meget sikkerhedsnet der findes i forvejen. Et enkelt versionsspring i en velholdt kodebase med tests er typisk dage, ikke uger. Flere spring plus en PHP-opgradering i en kodebase uden tests er typisk uger, ikke måneder. Efter kortlægningen (trin 1) får du et estimat med synlige antagelser — se også min guide til priser på Laravel-udvikling.