8 tegn på at dit legacy PHP-system skal moderniseres

Et gammelt PHP-system skal moderniseres når det koster dig mere i forsinkelser, frygt og sikkerhedsrisiko at lade det være end at gøre noget ved det. Legacy PHP-modernisering handler derfor lige så meget om forretningen som om koden: de tydeligste tegn er at ingen tør røre systemet, at små ændringer tager uger, og at serveren kører en PHP-version uden sikkerhedsopdateringer. Den gode nyhed er at modernisering sjældent betyder at starte forfra.

Jeg arbejder selv med Laravel og lever blandt andet af den slags opgaver, så læs med det forbehold. Netop derfor har jeg også skrevet et afsnit om hvornår du skal lade systemet være i fred.

Den korte version

De fire første tegn mærker du i forretningen. De fire sidste ligger i koden og på serveren, og dem skal du typisk have hjælp til at vurdere.

Min tommelfingerregel: Passer tegn 5 eller 8 på dit system, skal du handle inden for de næste måneder, uanset resten. Ellers er tre eller flere tegn et signal om at systemet skal vurderes før det bliver en akut opgave. Er du i tvivl om hvad løbende drift overhovedet bør omfatte, så start med min guide til drift og vedligehold af webapps.

Tegnene du mærker i forretningen

De første tegn ser ikke tekniske ud. De viser sig i møder, i overslag og i den måde folk taler om systemet på.

1. Ingen tør røre koden

Når en udvikler siger "det tør jeg ikke love" om en lille ændring, eller når I bevidst lader en fejl ligge fordi rettelsen kan vælte noget andet, er systemet blevet skrøbeligt. Det skyldes typisk at koden er vokset i mange år uden automatiske tests, så ingen kan se hvad en ændring rammer.

Frygten koster mere end den ser ud til. Forbedringer bliver udskudt, medarbejdere finder omveje, og når noget endelig skal ændres, sker det under pres. Spørg dig selv hvornår systemet sidst fik en forbedring der ikke var tvunget frem af en fejl.

2. Små ændringer tager uger

Et nyt felt i en formular, en ekstra kolonne i en eksport eller en ny rabatregel burde tage timer, ikke uger. Når simple ønsker konsekvent bliver til projekter med lange overslag, ligger logikken som regel spredt ud over hele systemet. Den samme regel kan være kopieret ind ti steder, og alle ti skal findes og testes.

Det er sjældent udvikleren der er langsom. Tiden går med at betale renter på gamle genveje i koden, det man kalder teknisk gæld: løsninger der var hurtige dengang, men som gør alt efterfølgende dyrere.

3. Kun én person kan arbejde i systemet

Mange gamle PHP-systemer er bygget af én udvikler, ofte en dygtig en, som har haft det hele i hovedet. Så længe den person er der, går det. Når vedkommende skifter job, går på pension eller bare holder tre ugers ferie, står du med et system som ingen andre kan overtage uden en lang indkøringsperiode.

Test det med ét spørgsmål: Hvis din udvikler stoppede i morgen, hvor lang tid ville det så tage en ny at lave en sikker ændring? Er svaret måneder, eller ved du det ikke, er afhængigheden en forretningsrisiko i sig selv. Et code review udefra er en forholdsvis billig måde at få et ærligt svar på.

4. Systemet siger nej til nye behov

Dine kunder forventer måske at kunne betale med MobilePay, logge ind med deres Microsoft-konto eller se deres data i en app. Dit regnskabsprogram har et API, og salg vil have data over i et CRM. Er svaret fra systemet nej, eller "det kan godt lade sig gøre, men det bliver dyrt", ender I med eksport til Excel, manuel indtastning og dobbeltarbejde.

Det manuelle arbejde dukker sjældent op i et budget, men det er en løbende udgift. Et moderne fundament med et ordentligt API gør den slags integrationer til almindelige opgaver i stedet for specialprojekter.

Tegnene under motorhjelmen

De næste fire tegn kræver at nogen kigger i koden eller på serveren. Du behøver ikke selv kunne læse PHP, men du bør kunne få svar fra den der vedligeholder systemet.

5. PHP-versionen får ikke længere sikkerhedsopdateringer

Hver PHP-version får to års aktiv support og derefter to års sikkerhedsrettelser. Ifølge PHP's egen oversigt over understøttede versioner er 8.1 og alt ældre uden support, og PHP 8.2 får sine sidste sikkerhedsrettelser 31. december 2026. Kører dit system PHP 7.4, har det været uden sikkerhedsopdateringer siden november 2022.

Det betyder ikke at systemet bliver hacket i morgen. Men nye sikkerhedshuller i PHP bliver ikke lukket for din version, mange nyere pakker understøtter den ikke, og det bliver sværere at finde hosting der vil køre den. Spørg din udvikler eller hostingudbyder hvilken version I kører. Er svaret 8.1 eller lavere, er det det vigtigste tegn på listen, og kører I 8.2, skal opgraderingen planlægges nu. Bygger systemet allerede på Laravel, har jeg lavet en oversigt over hvornår hver Laravel-version mister sine sikkerhedsopdateringer.

6. Koden bygger på et hjemmelavet eller forladt fundament

Mange systemer fra 2000'erne og starten af 2010'erne er bygget på et hjemmelavet framework eller på en gammel version af et framework som ingen vedligeholder længere. Ofte er tredjepartskode kopieret direkte ind i projektet i stedet for at blive styret af Composer, PHP's værktøj til at holde styr på pakker og versioner.

Problemet er ikke at koden er gammel. Problemet er at du selv skal vedligeholde alt, også det som resten af verden har løst for længe siden: login, validering af formularer, e-mails, køer og adgangsstyring. Og når en ny udvikler åbner et hjemmelavet framework, starter vedkommende fra nul fordi der hverken findes dokumentation, kurser eller et fællesskab at spørge.

7. Hver udgivelse er et lotteri

Bliver nye versioner lagt op via FTP direkte på produktionsserveren, uden et testmiljø (staging) og uden automatiske tests, er hver udgivelse et lotteri. Fejl bliver fundet af kunderne, og der er ingen nem måde at rulle tilbage til forrige version.

Ofte ligger koden heller ikke i et repository (kodearkiv) som Git, eller også er versionen dér ikke den samme som den der kører. Det er den del af en modernisering der er billigst at rette, og den giver mest ro med det samme. Derfor kommer den tidligt i trinene længere nede.

8. Sikkerheden hviler på gamle vaner

Gammel PHP-kode bærer præg af den tid den er skrevet i. Typiske fund er adgangskoder gemt med md5 eller sha1 i stedet for en moderne hashfunktion, databasekald hvor brugerens input sættes direkte ind i SQL (åbent for SQL injection), og formularer uden beskyttelse mod forfalskede forespørgsler.

Behandler systemet persondata, er det ikke kun et teknisk problem. Databeskyttelsesforordningen kræver i artikel 32 en sikkerhed der passer til risikoen og det aktuelle tekniske niveau. Kendte, uløste svagheder i et system med kundedata er svære at forsvare. Det er ikke juridisk rådgivning, men det er et godt argument at have med når budgettet skal godkendes.

Hvornår du skal lade systemet være

Ikke alle gamle systemer skal moderniseres, og jeg vil hellere sige det her end sælge dig et projekt du ikke har brug for. Det kan godt være fornuftigt at vente når:

• Systemet kun bruges internt bag login eller VPN, ikke behandler følsomme data og sjældent skal ændres.
• Det alligevel skal udfases inden for et års tid, fx fordi I skifter til et standardsystem.
• Opgaven kan løses af et færdigt produkt. Bookingsystemer, simple CRM'er og webshops er ofte billigere at købe end at modernisere.
• Ingen hos jer har tid til at svare på spørgsmål undervejs. En modernisering kræver at nogen kan forklare hvad systemet skal kunne, og hvorfor det gør som det gør.

Selv i de tilfælde bør du sikre det mest nødvendige: backup, koden i Git og en understøttet PHP-version hvis det overhovedet kan lade sig gøre. Og er dit system ikke skrevet i PHP, eller har du brug for et helt hold i flere år, er en freelancer som mig nok ikke det rigtige valg.

Modernisering eller omskrivning?

Når et system er gammelt nok, er det fristende at starte forfra. Det er sjældent det bedste valg. En fuld omskrivning tager længere tid end alle regner med, forretningen skal stadig have nye funktioner undervejs, og det gamle system rummer mange års regler og undtagelser som ingen har skrevet ned. Martin Fowler beskriver alternativet som strangler fig-mønsteret: Du bygger det nye ved siden af det gamle og flytter funktion for funktion indtil der ikke er mere tilbage af det gamle.

Groft sagt har du tre veje:

• Opgrader på stedet: Løft PHP-versionen, ryd op og tilføj tests, men behold strukturen. Passer når fundamentet er nogenlunde sundt, og problemet primært er versionen.
• Flyt gradvist til Laravel: Det nye system overtager én del ad gangen. Passer til de fleste systemer der skal udvikles videre i mange år.
• Byg forfra: Passer kun når systemet er lille, når forretningen har ændret sig så meget at det gamle ikke længere afspejler den, eller når datamodellen er umulig at bygge videre på.

Hvorfor Laravel som mål

Jeg anbefaler typisk Laravel fordi det er PHP. Din server, din database og meget af din forretningslogik kan genbruges, og ingen skal lære et nyt programmeringssprog. Samtidig får du login, køer, e-mails, tests og adgangsstyring som standard, og der kommer en ny hovedversion hvert år med en kendt supportperiode på to år for sikkerhedsrettelser. Jeg har skrevet mere om hvorfor Laravel er mit standardvalg til webapps.

Vejen til Laravel trin for trin

Sådan griber jeg typisk en gradvis modernisering an. Rækkefølgen er vigtigere end tempoet, for de første trin gør det sikkert at tage de næste.

Gør fundamentet sikkert

1. Kortlæg systemet. Find PHP-version, pakker, database, integrationer og cronjobs (planlagte kørsler), og find ud af hvilke dele folk faktisk bruger. Ofte viser det sig at en del af funktionerne er glemt og ikke skal flyttes med.
2. Gør det sikkert at ændre. Læg koden i Git, sæt automatisk backup op, og byg et testmiljø så ingen ændring går direkte i drift. Erstat FTP med en udgivelsesproces der kan rulles tilbage.
3. Fasthold den nuværende adfærd med tests. Før noget ændres, skriver jeg tests der beskriver hvad systemet gør i dag i de vigtigste forløb, fx login, ordrer og fakturering. Formålet er ikke at godkende den gamle logik, men at opdage det hvis den ændrer sig ved et uheld.
4. Løft PHP-versionen. Første mål er en version der stadig får sikkerhedsopdateringer. Rector kan automatisere en stor del af de mekaniske ændringer, men resultatet skal stadig gennemgås og testes. Bemærk at Laravel 13 kræver mindst PHP 8.3.

Flyt systemet over bid for bid

5. Sæt Laravel foran det gamle system. En ny Laravel-app tager imod alle forespørgsler og sender dem videre til den gamle kode indtil den pågældende side er flyttet. Begge dele kan bruge samme database. Det sværeste er typisk at dele login så brugerne ikke mærker skiftet.
6. Flyt én funktion ad gangen. Start hvor du alligevel skal ændre noget, eller hvor fejlene er flest, og byg kun nye funktioner i Laravel. Så betaler moderniseringen sig løbende og ikke først til sidst.
7. Sluk det gamle, og hold det nye opdateret. Når den sidste del er flyttet, fjernes den gamle kode. Derefter handler det om ikke at havne samme sted igen, så sørg for at framework og pakker bliver opdateret løbende.

Næste skridt

Du behøver ikke have en plan klar før du taler med en udvikler, men du får et langt bedre svar hvis du har styr på det her:

Med det på plads kan en udvikler give dig et realistisk billede af om systemet skal opgraderes på stedet, flyttes gradvist eller have lov at køre videre. Jeg starter større opgaver med et betalt forprojekt til fast pris så du kender planen og prisen før du forpligter dig til mere. Du ejer koden fra første dag. På siden om Laravel-udvikling og modernisering kan du se hvordan jeg arbejder.

Ofte stillede spørgsmål

Hvad koster det at modernisere et gammelt PHP-system?+

Det afhænger mest af systemets størrelse, antallet af integrationer og hvor meget af logikken der er dokumenteret eller dækket af tests. En ren PHP-opgradering af et lille system er en helt anden opgave end en gradvis flytning af en stor platform. Derfor giver en seriøs udvikler sjældent en fast pris uden at have set koden. Et kort forprojekt med kortlægning er den billigste vej til et præcist tal.

Kan systemet køre videre mens det bliver moderniseret?+

Ja, og det er netop pointen med en gradvis modernisering. Brugerne arbejder i det samme system mens funktionerne flyttes én ad gangen bag kulisserne. Der kan være korte, planlagte skift, fx når login flyttes, men de kan som regel lægges uden for arbejdstid. En fuld omskrivning kræver derimod ét stort skift, og det er dér risikoen er størst.

Skal vi skifte til Laravel, eller kan vi blive på ren PHP?+

I kan godt blive på ren PHP hvis systemet er lille, stabilt og sjældent ændres. Så er en opgradering af PHP-versionen og lidt oprydning ofte nok. Skal systemet udvikles videre i mange år, anbefaler jeg et framework fordi du slipper for selv at vedligeholde login, sikkerhed og infrastruktur. Laravel er mit valg, men Symfony er også et solidt fundament.

Er PHP stadig et godt valg i 2026?+

Ja. PHP bliver aktivt udviklet med en ny version hvert år, senest PHP 8.5 fra november 2025, og hver version får fire års support i alt. Moderne PHP har typer, god ydeevne og et stort økosystem af pakker. Problemet med gamle systemer er sjældent sproget, men at versionen og koden er gået i stå. Modernisering handler derfor oftest om at komme op på nutidig PHP, ikke om at forlade den.

Hvad gør vi hvis den oprindelige udvikler er væk?+

Start med at sikre adgangene: hosting, domæne, database, kode og eventuelle tredjepartskonti skal ligge hos jer og ikke hos en tidligere leverandør. Derefter kan en ny udvikler lave en kortlægning af koden og serveren. Den giver dig et grundlag for at beslutte om systemet skal opgraderes, flyttes eller udskiftes, og den viser hvor de største risici ligger.