Hvad koster en Laravel-opgradering? Priser efter versionsspring og kodens tilstand

En Laravel-opgradering koster typisk 3.000-10.000 kr. ekskl. moms hvis appen kun er én version bagud og har automatiske tests, og 25.000-80.000 kr. hvis den er to-tre versioner bagud. Er appen fire eller flere versioner bagud og uden tests, lander prisen på en Laravel-opgradering let over 100.000 kr., og så bør du også overveje om en modernisering er det bedre køb.

Jeg laver selv opgraderinger, så læs tallene med det forbehold (og afsnittet om hvornår du ikke skal betale nogen for det).

Den korte version: prisniveauer for en Laravel-opgradering

Prisen afhænger mest af afstanden til den nyeste version og af hvor let koden er at teste. Tabellen viser mine grove skøn.

Timerne gælder en typisk forretningsapp med login, et par integrationer og en håndfuld tredjepartspakker, udført af en erfaren udvikler. Prisen er regnet med 1.000 kr. i timen ekskl. moms, et rundt tal midt i det spænd på 800-1.200 kr. som LønRadar angiver for senior-freelancere i it i 2026. Det er et regnestykke, ikke min pris, så du kan skalere det til det tilbud du får. Hvad der er en normal timepris, og hvad du får for den, har jeg samlet i indlægget om timepriser for freelanceudviklere.

Til sammenligning skriver Laravel selv at de stræber efter at en opgradering til en ny hovedversion kan klares på en dag eller mindre, og opgraderingsguiden fra 12 til 13 anslår 10 minutter. Det passer til selve frameworket i en app der ligner Laravels standardopsætning. Mine tal er højere fordi de også dækker pakker, PHP, test og udgivelse, altså det der tager tiden i en app med nogle års historik.

Opgraderingen er kun én post i budgettet for en app i drift. Hvordan prisen på udvikling generelt bliver regnet ud, står i den samlede prisguide til softwareudvikling.

Hvad der gør en opgradering dyr eller billig

Antallet af versioner er det mest synlige, men det er sjældent det eneste. Disse faktorer går igen:

• Antal versionsspring. Hvert trin har sin egen opgraderingsguide, og trinene skal tages i rækkefølge.
• PHP-versionen. Laravel 13 kræver mindst PHP 8.3, og PHP 8.2 får kun sikkerhedsrettelser til og med 31. december 2026. Kører serveren en ældre PHP, skal den op samtidig, og nogle gange skal hele serveren skiftes.
• Tests. Med automatiske tests kan udvikleren se på få minutter om noget gik i stykker. Uden tests skal de vigtige forløb klikkes igennem i hånden efter hvert trin. Det er den største enkeltfaktor i mine skøn.
• Tredjepartspakker. Hver pakke skal også understøtte den nye version. Er en pakke opgivet af sin udvikler, skal den erstattes eller skrives om, og det kan koste mere end selve frameworket.
• Lappet eller usædvanlig kode. Ændringer direkte i frameworkets filer, egne udgaver af Laravels interne klasser eller meget gamle mønstre gør hvert trin langsommere.
• Frontend og byggeværktøjer. Bygger appen sine JavaScript- og CSS-filer med et ældre værktøj, fx Laravel Mix i stedet for Vite, kan det også trænge til en opdatering.
• Kender udvikleren koden? En udvikler der allerede vedligeholder appen, kan gå direkte i gang. En ny udvikler skal først sætte sig ind i opsætningen, og det tager fra et par timer på en lille app til flere dage på en stor.

Står flere af faktorerne på én gang, forstærker de hinanden. En app fire versioner bagud uden tests og med to forladte pakker er der hvor estimaterne bliver brede, og hvor en kortlægning før tilbuddet er pengene værd.

Hvad du betaler for i en opgradering

En opgradering er mere end at ændre et versionsnummer. Arbejdet følger typisk de samme seks trin, uanset hvem der laver det:

1. Kortlægning. Versionerne af Laravel, PHP og alle pakker bliver gennemgået, så det er klart hvad der blokerer, og i hvilken rækkefølge tingene skal ske.
2. PHP og server. Testmiljøet (staging) og senere produktionsserveren kommer op på en PHP-version som både den gamle og den nye Laravel-version kan køre på.
3. Afhængigheder. Laravel og pakkerne bliver opdateret ét trin ad gangen med Composer, PHP's værktøj til pakker, og forladte pakker bliver erstattet.
4. Kodeændringer. Ændringerne fra opgraderingsguiden og pakkernes ændringslister bliver rettet i koden.
5. Test. Automatiske tests bliver kørt, og de vigtigste forløb som login, betaling og e-mails bliver testet i testmiljøet.
6. Udgivelse og opfølgning. Opgraderingen bliver udgivet med en frisk backup og en plan for at rulle tilbage, og fejlloggen bliver fulgt de første dage.

Værktøjer der gør det billigere

Det mekaniske arbejde i trin 3 og 4 kan i dag delvist automatiseres. Laravel Shift er en selvstændig tjeneste som Laravels egen opgraderingsguide henviser til. Den laver automatisk de fleste ændringer og afleverer dem til gennemgang hos din udvikler. Ifølge Shifts prisside koster et versionstrin 19-39 dollars (oktober 2026), altså et par hundrede kroner. Laravel har desuden sit eget AI-værktøj, Laravel Boost, som den officielle opgraderingsguide nævner til trinnet fra 12 til 13.

Bruger din udvikler den slags værktøjer, er det god praksis og ikke snyd. Det flytter timerne fra rutinearbejde til det der kræver vurdering: pakker der ikke følger med, test og en sikker udgivelse. Det er også derfor tallene i tabellen ikke falder til nul, selvom værktøjet er billigt.

Fast pris eller timepris på en opgradering?

Et enkelt trin i en app som udvikleren kender, er nemt at prissætte fast. Et spring over flere versioner i en ukendt kodebase er det ikke før nogen har kigget i koden. Min anbefaling er derfor at dele det op:

• Ét trin i en kendt app: fast pris direkte.
• Flere trin eller ukendt kode: en kort kortlægning til fast pris først, typisk 2-6 timer, og derefter fast pris pr. trin.
• Meget gammel app uden tests: kortlægningen skal også svare på om opgradering eller modernisering er billigst.

Fast pris pr. trin har en ekstra fordel. Hvert trin kan udgives for sig, så appen er i drift hele vejen, og du kan holde pause efter et trin hvis budgettet strammer.

For at give et estimat der holder, skal en udvikler typisk bruge:

• Laravel- og PHP-versionen i produktion.
• Adgang til kodearkivet (repository) eller som minimum filerne composer.json og composer.lock.
• Oplysning om der findes automatiske tests, og om de bliver kørt.
• Hvor appen kører, fx hos en hostingudbyder eller på egen server.
• En liste over integrationer, fx betaling, økonomisystem og e-mail.
• En eventuel deadline, fx fordi hostingudbyderen udfaser en PHP-version.

Får du flere tilbud, så tjek at de dækker det samme: test, udgivelse og rettelse af fejl bagefter. Hvordan du gør det i praksis, står i guiden til at læse og sammenligne tilbud fra udviklere.

Hvorfor små løbende opgraderinger er billigst

Laravel udgiver en ny hovedversion cirka én gang om året, og ifølge Laravels supportpolitik får hver version fejlrettelser i 18 måneder og sikkerhedsrettelser i 2 år. I praksis kan appen derfor højst være én version bagud før den mister sikkerhedsrettelser.

Tallene herunder er tænkte, men mønstret er typisk. Forestil dig en forretningsapp med login, betaling, en håndfuld pakker og nogle tests, set over fire år:

Hvorfor er springet dyrere end summen af trinene? Fordi problemerne fra de enkelte trin hober sig op og skal løses på én gang. PHP skal flere versioner op, nogle pakker er opgivet undervejs, og når noget går i stykker, er det svært at se hvilket trin der forårsagede det. Hertil kommer den pris der ikke står på fakturaen: de år hvor appen kørte uden rettelser.

Hvornår din version mister support, og hvad det betyder i praksis, har jeg samlet i oversigten over Laravel-versioner og support. Vil du have opgraderingerne lagt ind i en fast aftale, kan en retainer eller et klippekort dække dem. Forskellen gennemgår jeg i guiden til retainer og klippekort.

Hvornår du ikke skal betale for en opgradering

Jeg tjener penge på opgraderinger, så det er rimeligt at sige hvornår pengene er bedre brugt andre steder:

• Appen skal lukkes eller erstattes inden for få måneder. Så er det bedre at begrænse adgangen, holde serveren opdateret og holde øje med den, indtil den bliver slukket.
• Du har en intern udvikler der kender Laravel. Et enkelt trin i en app med tests er en overskuelig opgave med den officielle guide og Shift i hånden.
• Appen er så gammel at trin for trin koster mere end modernisering. Det gælder især Laravel 5-apps uden tests, hvor store dele alligevel skal skrives om undervejs.
• Appen er ikke bygget i Laravel. Så gælder tallene her ikke, og du bør finde en specialist i den teknologi den faktisk bruger.

Og så det modsatte råd: lad være med at gemme opgraderingen, så den bliver lavet sammen med næste store funktion. To store ændringer på én gang gør begge sværere at teste og dyrere at rette, når noget fejler.

Næste skridt

Start med de to versionsnumre, Laravel og PHP i produktion. Med dem og tabellen øverst ved du om du står over for et lille trin eller et projekt.

1. Find versionerne. Din udvikler eller hostingudbyder kan svare på det på få minutter.
2. Sammenlign dem med supporttabellen, og skriv datoen for udløbet af sikkerhedsrettelser i kalenderen.
3. Er appen mere end én version bagud, så få en kortlægning og et estimat pr. trin.
4. Læg fremtidige opgraderinger i en fast rytme, én gang om året, gerne inden for et halvt år efter en ny version udkommer.

Vil du have hjælp til selve arbejdet, kan du se hvordan jeg arbejder med Laravel-udvikling, opgraderinger og videreudvikling. Du taler direkte med mig, der skriver koden, du ejer koden fra dag ét, og du får svar inden for én hverdag.

Ofte stillede spørgsmål

Kan jeg springe versioner over og gå direkte til den nyeste?+

Ikke i én bevægelse. Hver opgraderingsguide tager udgangspunkt i den forrige version, så en app på Laravel 9 skal igennem 10, 11 og 12 for at nå 13. Du kan godt samle trinene i ét projekt og først udgive til sidst, men arbejdet med hvert trin forsvinder ikke. Jeg foretrækker at udgive hvert trin for sig fordi det gør det tydeligt hvad der skabte en eventuel fejl.

Hvor lang tid tager en Laravel-opgradering i kalendertid?+

Et enkelt trin tager typisk 1-3 arbejdsdage fra start til udgivelse, inklusive test. Et spring over flere versioner tager oftere 2-8 uger. Hvert trin skal testes, og du skal selv bruge tid på at afprøve de vigtigste forløb. Har du en deadline, fx fordi hostingudbyderen fjerner en PHP-version, så sig det fra start, så planen kan bygges baglæns fra datoen.

Går appen ned under opgraderingen?+

Som regel ikke, eller kun i få minutter. Arbejdet foregår i et testmiljø, og med den rigtige opsætning kan selve udgivelsen ofte ske uden nedetid. Skal serveren skiftes eller PHP opgraderes, kan det kræve et kort, planlagt servicevindue, typisk uden for åbningstid. Sørg for at der findes en frisk backup og en plan for at rulle tilbage før opgraderingen bliver udgivet.

Bliver appen hurtigere efter en opgradering?+

Nogle gange lidt, men det er sjældent grunden til at opgradere. Nyere PHP-versioner er generelt hurtigere end de gamle, så en app der springer flere PHP-versioner op, kan godt mærke en forskel. Selve Laravel-opgraderingen giver ikke dine brugere nye funktioner af sig selv. Den giver din udvikler nyere værktøjer at bygge med og holder appen på en version der får sikkerhedsrettelser.

Hvem betaler hvis noget går i stykker efter opgraderingen?+

Det skal aftales før arbejdet starter. Et fornuftigt tilbud til fast pris dækker rettelse af fejl som opgraderingen selv har skabt, i en periode efter udgivelsen, fx 14-30 dage. Fejl der fandtes i forvejen, og ny funktionalitet hører ikke med. Få det skrevet ind i tilbuddet, så der ikke opstår diskussion den dag noget holder op med at virke.