Mange virksomheder sidder med en legacy-applikation, der virker, men som er svær at vedligeholde og en bremseklods for nye initiativer. Svaret er sjældent at bygge det hele forfra.
Den klassiske fejl er at beslutte: “Vi laver en ny version fra bunden.” Det lyder rigtigt og føles rigtigt, men i praksis er en total rewrite sjældent et teknisk problem. Det er et risikoproblem.
Projektet løber næsten altid over den estimerede tidsramme.
Kompleksiteten i et eksisterende system undervurderes konsekvent.
Forretningen mister fremdrift, mens hele teamet er låst i rebuild-projektet.
Den gamle løsning skal stadig vedligeholdes og fejlrettes imens.
Strangler Fig Pattern er opkaldt efter en plante, der vokser rundt om et træ og langsomt overtager det. I software betyder det, at du bygger en ny applikation ved siden af den gamle og lader den gradvist overtage funktionalitet.
Den gamle applikation lever videre, indtil den ikke længere er nødvendig — og kan derefter fjernes uden dramatik.
Det er den tilgang, vi som PHP-udviklere anbefaler, når forretningen er afhængig af en kørende løsning.
Byg ved siden af
Den nye applikation bygges parallelt med den eksisterende — uden at forstyrre drift.
Overtag lidt efter lidt
Funktionalitet flyttes over i bidder — login, API, rapportering, nye features.
Fjern det gamle
Når legacy-systemet er tømt for funktionalitet, kan det skrues ned og fjernes.
Forestil dig, at du har en ældre PHP-applikation med år af forretningslogik. I stedet for at slette den og starte forfra, introducerer du en ny applikation som gateway foran den gamle.
En moderne Laravel-applikation fungerer som gateway. Alle requests passerer igennem den nye applikation, der beslutter: håndteres requesten her, eller sendes den videre til legacy-systemet?
Start med afgrænsede, lavrisiko-moduler:
Over tid håndterer den nye applikation en stadigt større del af trafikken. Legacy-systemet får færre og færre opgaver. Når det er tømt, skrues det ned — og med det forsvinder den tekniske gæld, der bremser jer.
Strangler Fig-tilgangen adresserer præcis de risici, der typisk vælter et total-rewrite-projekt.
Du ændrer ikke alt på én gang. Hvert skridt er afgrænset og testbart, før du fortsætter.
Brugerne mærker sjældent overgangen. Der er ingen big-bang-lancering, der kan gå galt.
Nye features kan leveres i den moderne stack med det samme — du behøver ikke vente på at alt er migreret.
Du rydder op undervejs i stedet for at kopiere gamle fejl direkte over i en ny codebase.
Strangler Fig-tilgangen er ikke den rigtige løsning for alle systemer. Men den giver særligt mening, når nedenstående karakteristika er til stede — og det er ofte præcis her, vi som PHP-udviklere bliver involveret.
Virksomheder, der ikke kan stoppe driften — men heller ikke kan fortsætte med at stå stille.
Forretningskritisk applikation
Systemet er kernen i virksomhedens drift, og nedetid har direkte konsekvenser.
Mange integrationer
Systemet taler med økonomi, lager, CRM eller andre tjenester, der ikke bare kan stoppes.
Mangelfuld dokumentation
Der er ikke fuld overblik over alle edge cases og forretningsregler i koden.
Aktiv videreudvikling
Der efterspørges løbende nye features, som den eksisterende stack gør besværlige.
Usikkerhed om omfang
Ingen ved præcist, hvad et total rebuild egentlig ville kræve at efterligne korrekt.
En modernisering starter ikke med kode — den starter med analyse. Det vigtigste er ikke valget af framework. Det vigtigste er strategien.
Uanset om I lander på Laravel, Symfony eller en anden moderne stack, vil den tekniske transition følge det samme overordnede mønster.
En del moderniseringsforløb starter desuden med en PHP-versionsopgradering som første skridt — for at stabilisere fundamentet, inden den større migrering begynder.
Analyse af domæne og afhængigheder
Kortlæg alle integrationer, databasestrukturer og forretningsregler, der er indlejret i koden.
Kortlægning af risikable områder
Identificer de dele af systemet, der er mest komplekse, mest brugte og mindst dokumenterede.
Introduktion af tests
Hvis der ikke findes tests, etableres et testlag, der fanger regressioner under migrering.
Etablering af ny arkitektur
Den nye applikation sættes op som gateway. CI/CD, environments og deploymentflow defineres.
Gradvis migrering
Modul for modul flyttes over. Hvert modul testes og valideres, inden næste påbegyndes.
Legacy-systemer er sjældent kun et teknisk problem. De bærer typisk på årtiers forretningslogik, der kun delvist er dokumenteret — og som kræver både teknisk og forretningsmæssig forståelse at modernisere korrekt.
Systemet indeholder regler og adfærd, der er opstået over 10+ år — ofte uden at nogen husker baggrunden. Modernisering kræver, at denne viden kortlægges og bevares.
Systemet er koblet til økonomi, lager og CRM på måder, der ikke er fuldt dokumenterede. Hvert API-endpoint og dataudveksling skal kortlægges, inden migrering begynder.
Dele af kodebasen er så fragile, at ingen tør ændre i dem. Modernisering handler om at erstatte denne skrøbelighed med testdækning og forudsigelig backendarkitektur.
Hvis du sidder med et ældre system og overvejer, om I skal bygge nyt, opgradere eller migrere, er det vigtigt at få lagt en realistisk plan — før der skrives en eneste linje ny kode.
Modernisering handler ikke om at kassere det gamle. Det handler om at beskytte den værdi, der allerede er skabt, og gøre den fremtidssikret.
Vi hjælper med alt fra indledende analyse til fuld backendudvikling og lancering.
Har du brug for hjælp til at modernisere en legacy-applikation? Vi lægger en realistisk plan sammen med dig – uden at starte forfra.
