Laravel-opgradering: supportfrister, forløb og pris
Af Nicklas K. Frank · Opdateret 10. september 2026 · 5 min. læsning
Kører din applikation på Laravel 11 eller ældre, modtager den ikke længere sikkerhedsopdateringer. Laravel 11's sikkerhedssupport udløb 12. marts 2026. Versionen er dermed uden for Laravels officielle sikkerhedssupport.
Opgavens størrelse afhænger især af PHP-version, tredjepartspakker, testdækning og integrationer. Her gennemgår jeg supportfristerne og den arbejdsform, jeg bruger ved Laravel-udvikling.
Få afklaret springet, før I budgetterer
Send jeres Laravel- og PHP-version samt gerne composer.json og composer.lock. Så kan jeg indledningsvis vurdere versionsafstanden, de mest oplagte blokeringer og om opgaven bør begynde med en teknisk audit. Del ikke adgangskoder eller produktionsdata.
Supportstatus for Laravel-versioner (september 2026)
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:
Supportstatus for Laravel 10 til 13 i september 2026
Version
Udgivet
Sikkerhedsrettelser til
Status
Laravel 13
17. marts 2026
17. marts 2028
Aktuel version
Laravel 12
24. februar 2025
24. februar 2027
Kun sikkerhedsrettelser
Laravel 11
12. marts 2024
12. marts 2026
Udgået
Laravel 10 og ældre
2023 og før
Februar 2025 og før
Udgået
Datoerne er kontrolleret 10. september 2026 mod Laravels officielle release-dokumentation. Bemærk også, at Laravel 13 kræver PHP 8.3 eller nyere, så PHP-versionen skal ofte opgraderes i samme ombæring.
Hvad en udgået version påvirker
Sikkerhed: Laravel retter nye framework-sårbarheder i supporterede versioner. På en udgået version skal I selv vurdere og afhjælpe problemet eller opgradere, hvis rettelsen ikke kan bruges direkte.
Pakker: tredjepartspakker fjerner løbende understøttelsen af gamle Laravel-versioner. Det kan blokere opdateringer eller kræve, at en pakke udskiftes.
Opgavens størrelse: flere versionsspring betyder flere ændringer i framework, PHP og pakker. Det tager normalt længere tid at kortlægge og teste end et enkelt spring.
Kompatibilitet: nye PHP-versioner, biblioteker og udviklingsværktøjer kan kræve en nyere Laravel-version. Det er en af de afhængigheder, jeg kortlægger, når jeg overtager et eksisterende Laravel-projekt.
Det får I i en opgraderingsaudit
Efter gennemgangen får I en plan, som beskriver:
Versioner og pakker: nuværende og anbefalet Laravel- og PHP-version samt pakker, der skal opgraderes, erstattes eller undersøges.
Funktioner, der kræver særlig test: kendte brudflader som authentication, køer, filhåndtering, betaling, mail, cron-jobs og eksterne integrationer.
Manglende tests: hvilke forretningskritiske flows der mangler automatiske tests, før koden ændres.
Rækkefølge: Laravel, PHP og pakker fordelt i arbejdstrin med kontrolpunkter mellem versionsspringene.
Estimat og releaseplan: forventet indsats, forudsætninger, test- og deploystrategi samt mulighed for rollback.
Udgangspunkt: ældre Laravel- og PHP-version, delvis testdækning og en betalingsintegration. Konklusion: etabler tests omkring betaling og login først; opgrader derefter PHP, framework og blokerende pakker i separate trin; verificér jobkøer og webhooks før produktion. Beslutning: projektet estimeres først endeligt, når den udokumenterede integrationspakke er undersøgt.
Eksemplet viser format og detaljeringsniveau. Det er ikke en kundecase eller et estimat for jeres system.
Sådan foregår en trinvis opgradering
1
Kortlægning
Jeg registrerer Laravel- og PHP-version, afhængigheder, ændringer i framework-koden og den eksisterende testdækning. Resultatet beskriver rækkefølge, risici og blokeringer.
2
Tests af kritiske flows
Hvis de forretningskritiske flows mangler automatiske tests, skriver jeg målrettede tests før opgraderingen. De bruges til at opdage ændret adfærd undervejs.
3
Version for version
Jeg gennemgår versionernes officielle opgraderingsguides i rækkefølge, herunder ændringerne fra Laravel 12 til 13. Hvert trin bliver testet og kan deployes separat, når projektets setup gør det muligt.
4
PHP, pakker og CI/CD
PHP-versionen og tredjepartspakkerne indgår i samme plan. Jeg kontrollerer også PHP-versionens egen frist for sikkerhedsrettelser i PHPs supportoversigt. Hvis projektet mangler automatiseret test og deployment, aftaler vi, om det skal etableres som en del af opgaven.
Tre eksempler på opgavens størrelse
Scenarier, tidsrammer og risikoniveauer for en Laravel-opgradering
Risiko
Eksempel
Foreløbig tidsramme
Lav
Laravel 12 til 13, kompatibel PHP, aktive tests og vedligeholdte pakker
Få arbejdsdage; stadig med staging, test og kontrolleret deploy
Mellem
Laravel 10 eller 11 til 13, samtidig PHP-skift og delvis testdækning
Flere trin og ofte uger; hver version valideres separat
Høj
Laravel 9 eller ældre, gammel PHP, få tests eller kritiske specialintegrationer
Estimeres efter gennemgangen og deles i faser
Tidsrammerne er planlægningskategorier, ikke tilbud. Kodebasens størrelse alene afgør ikke risikoen; testdækning, pakker og integrationer vejer ofte tungere.
Tjekliste før I køber en opgradering
Er målversionen og den nødvendige PHP-version skrevet tydeligt i tilbuddet?
Er udskiftning af inkompatible eller forladte pakker med i scope?
Hvilke automatiske og manuelle tests skal være bestået før release?
Findes staging, backup og en dokumenteret rollback-plan?
Hvem verificerer betaling, mail, jobkøer, webhooks og integrationer efter deploy?
Hvilken dokumentation afleveres, og hvem ejer kode og adgange bagefter?
Hvad koster en Laravel-opgradering?
Prisen afhænger især af antal versionsspring, PHP- og pakkeafhængigheder, testdækning og kritiske integrationer. Et enkelt spring i en velholdt kodebase med tests kan ofte løses på få arbejdsdage. Flere spring, PHP-opgradering og manglende tests kræver typisk flere arbejdstrin. Efter auditten får du et estimat med forudsætninger og et beslutningspunkt. Se mine timepriser og budgeteksempler for Laravel-udvikling.
Kører I på en udgået Laravel-version?
Send Laravel- og PHP-version, teststatus og de vigtigste integrationer. Jeg svarer med de oplagte afhængigheder og om opgaven bør begynde med en teknisk audit.
