Hvorfor legacy-systemer overlever, og konsekvenserne for forretningen
Næsten enhver etableret virksomhed har én: det centrale system, ingen tør slukke for, fordi det stadig bærer en vigtig del af forretningen. Det er sjældent en hemmelighed. Det står på listen over ting, der burde moderniseres, og har stået der i flere år, uden at nogen for alvor har rykket ved det.
Kløften mellem enighed og handling er en af de dyreste vaner i enterprise-IT. Det gamle system driver stadig forretningen, æder stadig budget og sætter stadig tempoet for alle teams, der afhænger af det. Samtidig peger efterspørgslen den modsatte vej: hurtigere releases, mere integration og data, der er klar til AI.
Legacy-systemer holdes sjældent i live, fordi nogen tror på dem. De overlever, fordi det er sværere at forsvare et exit end at blive.
Hvorfor legacy-systemet stadig består
Forhindringerne ligger mest i risiko, penge og viden.
Risikoen er skæv. Systemet kører fakturering, policeadministration, kernebanksystemet eller ERP'en. En vellykket modernisering går upåagtet hen, mens en mislykket huskes i årevis. At gøre ingenting føles trygt, selv om det ikke er det.
Ingen ved præcis, hvad den gør. Årtiers forretningsregler ligger i koden, og dem, der skrev den, er ikke længere i virksomheden eller på pension. Udokumenterede integrationer og batchjobs betyder, at hver ændring har bivirkninger, ingen kan forudsige.
Finansieringsmodellen arbejder imod. Budgetter favoriserer synlige nye funktioner frem for usynlig risikoreduktion. Argumentet for modernisering er ofte "undgå noget dårligt", og det er svært at sælge op imod et vækstinitiativ.
Forretningen skal eje det. Modernisering betyder at gentænke processer, ejerskab og data. Det kræver lige så meget forretningsmæssig opbakning som teknologi, og det får sjældent samme opmærksomhed.
Ar fra big bang-projekter. Mange virksomheder har et mislykket udskiftningsprogram i baggagen. Ledelsen husker det og er tilbageholdende med at prøve igen.
Kontrakter og kompetencer. Licenser, supportaftaler og lange leverandørvilkår gør exit dyrt. Og dem, der kender systemet bedst, er ofte dem, hvis rolle afhænger af det.
Hvad legacy-systemet gør ved hastighed og smidighed
Et legacy-system sætter ofte loft over, hvor hurtigt hele organisationen kan bevæge sig, uanset hvor agile teamene omkring det er. Vægten varierer fra system til system, men pointerne herunder går oftest igen.
Ændringer er langsomme og risikable. Et gammelt system har ofte mange afhængigheder til det, der omgiver det. Selv en lille ændring kræver omfattende test, fordi ingen med sikkerhed kan sige, hvad den rører ved. Release-kadencen falder til kvartalsvis eller værre.
Kapaciteten er svær at justere. Mange legacy-platforme er bygget til én bestemt belastning. Når behovet stiger, er løsningen ofte at overdimensionere hele systemet, fordi det ikke kan skaleres i de dele, der reelt mangler kapacitet.
Langsom integration. Nye produkter, partnere og AI-funktioner kræver API'er og dataadgang, som systemet aldrig blev designet til. Teams bygger omveje, og omvejene tilføjer kompleksitet.
Data låst inde. AI og analyse kræver tilgængelige, velstrukturerede data. Legacy-systemer gemmer dem ofte i proprietære eller forældede strukturer, hvilket er en reel bremse for AI-ambitioner.
Frygt for forandring. Gennemløbstiderne vokser, udviklere undgår de risikable områder, og teknisk gæld hober sig op.
Kompetenceflugt. Dygtige ingeniører foretrækker moderne stacks, og puljen af folk, der kender den gamle, bliver mindre.
Compliance- og sikkerhedseksponering. Uunderstøttede platforme, besværlig patching og svage revisionsspor vejer tungere under NIS2 og DORA, end de gjorde før.
Innovationsteater. Virksomheder bygger moderne lag ovenpå, men det gamle system bestemmer stadig, hvad der er muligt. Hastighedsgevinsten bliver ved kanten.
At gøre ingenting er ikke den sikre løsning
At lade legacy-systemet stå er også en beslutning, og den indebærer to risici, der vokser stille.
Driftskontinuitet. Platformen, der kører forretningens kerne, er ofte den, der er sværest at forstå og genoprette. Leverandørsupport udløber, patching bliver langsommere, og de folk, der kan rette den, er få og bliver færre. Når den fejler, rammer nedbruddet fakturering, skadesbehandling, betalinger eller produktion, og ingen kan med sikkerhed sige, hvor lang tid genopretning tager, eller hvad der ellers går ned. DORA og NIS2 sætter begge kontinuitet og genopretning på ledelsens dagsorden.
Tabt evne til forandring. For hvert kvartal det gamle system består, vokser afstanden mellem det, forretningen vil, og det, platformen tillader. Nye produkter venter på release-vinduer. Regulatoriske ændringer bliver til projekter. AI-initiativer går i stå på data, der ikke kan nås. Konkurrenter, der kan ændre sig på uger, sætter tempoet, og organisationen ender med at reagere frem for at vælge.
Ingen af de to risici står på en projektplan. Derfor vinder ingenting-scenariet igen og igen budgetdiskussionen: prisen for at handle er synlig, og prisen for at vente er det ikke.
Hvad der reelt blokerer exit
Det meste af årsagerne og omkostningerne ovenfor kan føres tilbage til ét hul: organisationen kan ikke se, hvad legacy-systemet er forbundet til.
Det hul afgør, om et exit overhovedet kan afgrænses, finansieres og planlægges i rækkefølge. Når afhængighederne kun delvist er skrevet ned, er hvert estimat et gæt, og hvert gæt taler for at vente.
Derfor ser strangler fig-mønstre og moderniseringsplaner overbevisende ud i en præsentation og går i stå i praksis. Planen forudsætter et kort, der ikke findes. Uden det bliver "lad os slippe af med den" ved med at være et ønske, og det gamle system bliver.
Integrationerne er der, hvor hullet gør mest ondt. Gennem årene har systemet samlet punkt-til-punkt-forbindelser, filoverførsler, batchjobs og rapporter, der fodrer andre systemer, ofte bygget af folk, der er stoppet. Hver enkelt er lille, men tilsammen afgør de, hvad der kan flyttes, og i hvilken rækkefølge. En enkel vej ind er at starte med forbindelserne frem for koden: list, hvad der kommer ind og går ud af systemet, hvem der afhænger af det, og hvor kritisk hvert flow er. Den korte liste viser som regel, hvor et exit kan begynde.
Et aktuelt eksempel. Bloomberg rapporterede i september, at Zeiss har lagt sin SAP-cloudmigrering om, efter at omkostningerne over flere år er vokset til mere end 200 millioner euro. Planen var oprindeligt at bygge et helt nyt system fra bunden. Den er nu skrottet til fordel for at konvertere de eksisterende systemer.
Pointen er ikke fejlslaget i sig selv, men at Zeiss forpligtede sig tidligt og alligevel endte her. Efter min erfaring er værktøjerne sjældent det svære. Det svære er én fælles forståelse af, hvad der skal ændres, og modet til at ændre driftsmodellen, så beslutninger bygger på viden frem for antagelser. Mønstret går langt ud over SAP og dukker op i stort set enhver modernisering af en kerneplatform. Jeg har skrevet mere om denne problematik i dette opslag på LinkedIn.
Det er ikke nok at omskrive koden, hverken i hånden eller med AI
Mange virksomheder er begyndt at modernisere koden i deres legacy-systemer, og flere bruger nu AI til at skrive den om. Det hjælper, men det adresserer kun ét lag af et større problem.
Resten af det gamle system Den nye kode deler ofte stadig de samme databaser og dataformater som før, så koblingen til resten af landskabet ikke forsvinder. Den flytter bare. Batchjobs, punkt-til-punkt-integrationer og rapporter bygget på det gamle system dukker op sent, ved overgangen, hvor de er dyrest at rette. Release-udvalg, testporte og teamgrænser afspejler stadig den gamle platform, så moderne kode leveres i gammelt tempo.
Ingen ejer forretningsreglerne. At omskrive kode betyder enten at kopiere regler, ingen forstår, eller at ændre dem uden en forretningsejer, der kan bekræfte, at de er rigtige. Det kræver folk uden for IT.
Ingenting bliver slukket. Nye services går i luften, mens den gamle platform bliver stående til nogle få tilbageværende afhængigheder. Virksomheden betaler for begge, og licenser og supportaftaler løber videre.
AI gør det billigt at skrive kode, og det flytter flaskehalsen. AI oversætter, hvad koden gør, ikke hvad forretningen har brug for, så en tro kopi af et 20 år gammelt design stadig er det samme design. At bevise, at den nye version opfører sig som den gamle, tager langt længere tid end at generere den. AI ser desuden kun det, den får serveret, og kørselsplaner, omveje og kontraktvilkår omkring koden ligger uden for kodebasen. Et pilotprojekt på ét velforstået modul går glat, mens den sammenfiltrede, udokumenterede rest er der, hvor programmer går i stå. Store mængder genereret kode, som ingen helt forstår, kan endda blive morgendagens legacy.
AI er reelt nyttig til at dokumentere, hvad eksisterende kode gør, generere tests, kortlægge afhængigheder og fremskynde udførelsen, når målbillede og rækkefølge er besluttet. AI kan accelerere en plan, men ikke levere den.
Sådan kommer man i gang
Man behøver ikke et femårigt program for at begynde. Man behøver fire ting i den rigtige rækkefølge.
Kortlæg, før du planlægger. Byg en forbundet model af, hvad systemet gør, hvad det afhænger af, og hvem der ejer hver del, med integrationerne først. Den behøver ikke være perfekt, blot god nok til at vise, hvad der afhænger af hvad. Modellen skal kobles til reelle data og løbende opdateres, ellers er den forældet, før den er færdig.
Læs kontraktkalenderen. Fornyelsesdatoer, opsigelsesfrister og licensvilkår er ofte den egentlige drivkraft for et exit, eller den egentlige bremse. Arkitekter kigger sjældent på dem, og licensfolk kigger sjældent på arkitektur. Sæt de to perspektiver side om side, og rækkefølgen af exits bliver som regel indlysende.
Brug regulering som businesscase. Under DORA og NIS2 er uunderstøttede platforme, nøglepersonafhængighed og tredjepartseksponering risici, der skal styres og dokumenteres. Det giver exit et finansieringsargument, som "vi vil gerne være mere agile" aldrig gjorde.
Beslut pr. system: udfas, indpak eller lad stå. Ikke ethvert legacy-system skal dø. Nogle er stabile, billige og fine. Kunsten er at vide, hvilke der skal udfases, hvilke der skal indpakkes bag en grænseflade, og hvilke der skal blive, og det kræver data om omkostning, risiko og forretningsværdi frem for mavefornemmelse.
Legacy-systemet er et symptom
Legacy-systemet er sjældent roden til problemet. Det er symptomet: en virksomhed, der ikke længere har overblik over sit eget landskab, mens prisen for at stå stille vokser stille og roligt, én fornyelse og én omvej ad gangen.
De virksomheder, der lykkes med at komme videre, starter sjældent med det mest ambitiøse målbillede. De starter med at gøre landskabet synligt og gør derefter exit til en række små, finansierede beslutninger med lav risiko.
Hvilket system i jeres landskab er alle enige om bør udfases, og hvad er det reelt, der holder det på plads?
📅 Vi hører gerne jeres svar på clariox.dk/contact
Oplysningerne om Zeiss stammer fra Bloombergs omtale den 7. september 2026.
Troels Rendbæk Sørensen - CEO & Founder