Pillar page
Legacy-modernisering
Inkrementel refaktorering fra monolit til mikroservices, migrering fra forældede teknologier til moderne stacks, cloud-migrering — uden nedetid for forretningen, med rollback-plan og komplet audit trail.
Hver virksomhed har et eller andet legacy-system. Nogle har flere. En regnskabsapplikation fra 2008, der på en eller anden måde stadig fungerer. Et CRM skrevet af konsulenter, som ingen længere husker. Et lager, der kører i Access. Hver af dem skal udskiftes på et tidspunkt — spørgsmålet er ikke om, men hvornår og hvordan.
Legacy-modernisering er en af de sværeste typer IT-projekter. Det kræver balance mellem tre kræfter: forretningskontinuitet (systemet skal køre hele tiden), indførelse af moderne teknologier (mikroservices, cloud, AI) og risikokontrol (hver refaktorering kan ødelægge noget, der har virket i årevis).
Hvorfor ikke bare „skrive om fra bunden"?
Fra vores erfaring er 9 ud af 10 vellykkede moderniseringer inkrementel refaktorering, ikke omskrivning. Omskrivninger er begrebsmæssigt fristende („vi starter på en frisk"), men i praksis har de tre grundlæggende problemer:
- Usynlig forretningslogik. Det gamle system indeholder års forretningsregler — særlige betingelser for de største kunder, skattefritagelser for bestemte brancher, workarounds for regler fra 2015. Det meste er udokumenteret. En omskrivning skal genskabe alt det fra folks hukommelse eller kodeanalyse.
- Dobbeltarbejde. Mens det nye system skrives, kræver forretningen stadig ændringer i det gamle (regler, nye kunder, små fejl). Teamet enten duplikerer arbejdet (ændringer to steder) eller fryser det gamle system (forretningsrisiko).
- Big bang-deployment. Efter et års arbejde er det nye system „næsten klar". At skifte alle brugere over på én nat skaber en monumental risiko. Ethvert uventet problem betyder retur til det gamle system, tab af teamets moral og forretningens tillid.
Inkrementel refaktorering (typisk efter Strangler Fig-mønsteret) løser alle tre: forretningslogik opdages gradvist, én sandhedskilde pr. enhed, deployment i etaper med feature flags.
Seks moderniseringsmønstre
Hvert mønster adresserer en specifik risiko. I de fleste projekter kombinerer vi flere og vælger et mønster pr. modul.
Strangler Fig
Gradvis „indpakning" af det gamle system med nye komponenter. Den gamle kode kører stadig, men hver ny feature går til en ny mikroservice, og eksisterende moduler udskiftes ét ad gangen. Efter 12-24 måneder slukkes den gamle monolit.
Anti-corruption layer
En adapter, der beskytter ny kode mod det gamle systems særheder (ulæselige feltnavne, mærkelige datoformater, inkonsistente typer). Al „grim" logik isoleres ét sted — ny kode arbejder på en ren domænemodel.
Database-refaktorering
Mønstre fra Refactoring Databases (Ambler/Sadalage): expand-and-contract til skemamigreringer, datavalidering før fjernelse af gamle kolonner, parallel kørsel af begge skemaer under applikationsmigrering.
Branch by abstraction
Indførelse af et abstraktionslag omkring den gamle komponent, parallel implementering af den nye komponent, gradvis skift af trafik fra 0% til 100% (feature flag). Uden en „big bang"-deployment.
Shadow mode
Den nye kode kører sideløbende med den gamle — begge behandler samme requests, men kun resultater fra det gamle system når brugeren. Resultaterne sammenlignes offline. Efter bekræftet kompatibilitet (typisk 2-4 uger) skifter vi trafik til den nye kode.
Event sourcing til migrering
Vi registrerer strømmen af forretningshændelser fra det gamle system og afspiller dem i det nye. Det giver mulighed for foreløbig validering af den nye arkitektur uden produktionsrisiko og evne til at vende tilbage til enhver historisk tilstand.
Typisk moderniseringsplan
For et mellemstort system (en monolit på ~200k linjer kode, 5-10 forretningsmoduler):
- Måned 1: Discovery og dokumentation. Reverse engineering af arkitektur, kortlægning af afhængigheder, identifikation af datastrømme, dokumentation af forretningsprocesser med hjælp fra forretningsejere.
- Måned 2: Målarkitektur og pilot. Design af ny arkitektur, teknologivalg, pilot på det enkleste modul (proof of concept). Første validering af tilgangen.
- Måned 3-4: Udskæring af det første produktionsmodul. Strangler Fig-mønster, shadow mode i 2-3 uger, trafik-omlægning, hypercare. Første ægte forretningsværdi.
- Måned 5-12: Iterativ udskæring af efterfølgende moduler. Hvert i en cyklus på 4-6 uger: refaktorering → test → shadow → produktion → hypercare. Løbende procesforbedring, reduktion af tid pr. modul.
- Måned 12-18: Datamigrering og udfasning af monolitten. Når alle kritiske moduler er udskåret, færdiggør vi den historiske datamigrering, slukker det gamle system, arkiverer. Fejre.
Legacy-system vs. moderniseret
| Aspekt | Legacy-system (typisk) | Efter modernisering |
|---|---|---|
| Tid til levering af en ny feature | 4-8 uger (høj regressionsrisiko) | 3-7 dage (automatiserede test minimerer risiko) |
| Testdækning | 5-15% (eller ingen) | >80%, i CI/CD-pipelinen |
| Udviklertilgængelighed | Lav (forældet teknologi) | Høj (populære, moderne stacks) |
| Sikkerhed | Gamle biblioteker med ikke-patchede CVE'er | OWASP-scanning, gitleaks, automatiserede opdateringer |
| Skalering | Vertikal (flere ressourcer til monolitten) | Horisontal (skalering af specifikke mikroservices) |
| Observabilitet | Logs i filer, ingen metrikker | Prometheus + Grafana + Sentry + SIEM |
| Compliance (GDPR, EU AI Act, ISO 27001) | Krævende, dyr at dokumentere | Indbygget i arkitekturen, klar til audit |
Seks typiske risici — og hvordan vi håndterer dem
Risiko: Ingen test i legacy-systemet
Mitigering: Først bygger vi karakteristik-test (capture tests) — registrering af systemets nuværende adfærd baseret på produktionslogs og trafik-captures. Først derefter starter vi refaktorering med test som sikkerhedsnet.
Risiko: Viden koncentreret hos én person („truck factor 1")
Mitigering: Vidensoverførsel starter i projektets første uge. Alle møder med den person, der kender systemet, optages og transskriberes, nøgleprocesser dokumenteres, arkitekturbeslutninger begrundes. Efter projektet forstår hele teamet systemet.
Risiko: Midlertidig team-opbremsning
Mitigering: I de første 2-3 måneder vedligeholder teamet det gamle system + bygger det nye. En naturlig opbremsning i ændringshastighed. Vi mitigerer ved: prioritering af ændringer, der kun går til det nye system, frysning af lavprioriterede ændringer i den gamle codebase.
Risiko: Datamigrering
Mitigering: Hver datamigrering har tre faser: dry-run (på en produktionskopi), staging (i testmiljø med data i realskala), produktion (i et servicevindue eller inkrementelt). Rollback-plan klar inden start.
Risiko: Organisatorisk modstand
Mitigering: Kommunikation med forretningen fra dag ét: hvorfor vi moderniserer, hvad ændres for brugeren, hvad er tidsplanen, hvordan måler vi succes. Den første iteration vælges, så den hurtigt viser konkret værdi (f.eks. en ny UI eller en hurtigere rapport).
Risiko: Undervurdering af omkostninger
Mitigering: Discovery (1-2 uger) før projektprissætning. 2-3 ugers iterationer med konkrete leverancer — lettere at justere kursen end i et langt „alt på én gang"-projekt. Budget med 20-30% buffer til det uforudsete.
Ofte stillede spørgsmål
Hvad er et legacy-system?
Hvorfor modernisere, hvis systemet fungerer?
Er det ikke nemmere at skrive alt om fra bunden?
Kræver modernisering nedetid for forretningen?
Hvor lang tid tager en typisk modernisering?
Hvilke teknologier migrerer vi oftest fra?
Hvad med eksisterende integrationer med andre systemer?
Hvordan reducerer I forretningsrisikoen?
Hvad med systemdokumentation, der ikke findes?
Hvordan ser moderniseringsomkostningen ud sammenlignet med vedligeholdelse af det gamle system?
Lad os starte med en audit
En teknisk audit på en uge: kortlægning af den aktuelle tilstand, identifikation af de mest presserende moderniseringsområder, en faseopdelt plan med konkrete forretningsmæssige resultater i den første iteration.