Written by:
Last Published:
15. september 2026
•
Kan man virkelig spare 40–50 % ved at flytte til skyen?
Ja. Men ikke på den måde, du tror.
De fleste virksomheder, der taler om besparelser i skyen, beskriver det, som om det er en naturlov: "Flyt fra dyr on-premise-infrastruktur til skalerbar cloud, så falder omkostningerne." Rent. Og logisk. Men forkert. Virkeligheden er mere rodet. Det handler mindre om teknologien og mere om hvad du rent faktisk betaler for lige nu.
Men de fleste organisationer aner ikke, hvad det drejer sig om. De ser én linje med "infrastrukturomkostninger" og lader den ligge. Derefter forsøger de at modernisere uden at kortlægge det, der ligger gemt, såsom licenser bundet i flerårige kontrakter, overflødig hardware og et driftsteam, der udelukkende eksisterer for at holde liv i legacy-systemerne. Indtil du får løsnet op for de knuder, virker modernisering risikabelt. Den gode nyhed: Det er det også, lige indtil det ikke er det længere.
Det er her, historien starter. TrustPortal, en britisk fintech- og automatiseringsplatform, brændte penge af på legacy-infrastruktur. De satte sig ikke for at spare 40–50 %. Det, de gjorde, var at forstå, hvad de rent faktisk betalte for, og den klarhed ændrede alt.
Her er, hvordan de fleste legacy-omkostninger reelt ser ud. Lad os opdele dem i tre: softwarelicenser (ofte låst i flerårige kontrakter med strafgebyrer), infrastruktur og hosting (nogle gange overflødigt, altid historisk dyrt) samt driftsarbejdskraft (den usynlige skat). De fleste virksomheder måler ikke arbejdskraft som en omkostningsdriver, men det burde de. Et driftsteam, der er dedikeret til at holde legacy-systemer kørende, er en klods om benet sammenlignet med cloud-native teams, der arbejder via automatisering.
TrustPortal var en mellemstor, global virksomhed. Deres legacy-infrastruktur så standard ud: enterprise-databaser, legacy-applikationsservere, on-premise lagring og en managed hosting-aftale. Men her er grunden til, at omkostningerne var usynlige: De var spredt ud. Licenser lå under it-budgettet, infrastruktur under faciliteter og arbejdskraft under drift. Finansafdelingen kunne ikke se det fulde billede, så ledelsen kunne ikke retfærdiggøre en modernisering.
De fleste legacy-omkostninger kan opdeles i tre mønstre:
Læg det sammen. De fleste mellemstore virksomheder har en infrastruktur til mange millioner, som ikke skaber nogen konkurrencemæssig fordel. Den er der bare... og kører.
De fleste virksomheder gemmer denne omkostning på tværs af flere budgetter. Det gør I sikkert også.
Systematisk modernisering kræver benhård prioritering. Hvilke systemer genererer omsætning? Hvilke er blot en udgift? Og hvilke er så tæt forbundet med compliance, at en flytning ville være regulatorisk selvmord?
TrustPortal stod over for en reel begrænsning: Deres kerne til betalingsbehandling var låst fast i legacy-infrastruktur af regulatoriske og revisionsmæssige årsager. At ombygge den til skyen ville have taget årevis og kostet millioner. Det var ikke den rigtige vej. I stedet opdelte de deres arbejdsbelastninger ved hjælp af en simpel ramme:
Flyt til skyen: TrustPortals primære RPA- og automatiseringsplatform, kundedashboards, interne rapporteringsværktøjer og systemer til medarbejderproduktivitet. Disse var ikke bundet af compliance-krav. De var bygget på moderne arkitekturer (Angular, NodeJS, containerbaserede udrulninger i cloud-infrastruktur). De skabte forretningsværdi og var kundevendte.
Behold legacy: Betalingsbehandling. Håndtering af kernetransaktioner. Den regulatoriske byrde var for stor. Risikoen ved en mislykket migrering var uacceptabel.
Hybrid: Brugeridentitetssystemer og svindeldetektering. Disse skulle kunne kommunikere med både legacy- og cloud-systemer, så de opdelte arbejdsbelastningen: cloud til de kundevendte dele og legacy til den følsomme kerne.
Resultatet: 70 % af deres infrastruktur flyttede til skyen. 30 % forblev legacy. Hybrid arkitektur.
Hvorfor betyder denne opdeling noget? Fordi den er realistisk. De fleste virksomheder antager, at "cloud-migrering" betyder, at "alt skal i skyen." Det gør det ikke. Det kandet ikke, hvis man vil bevare omsætningen og holde tilsynsmyndighederne tilfredse. Fintech-virksomhedens hybride tilgang betød, at de kunne modernisere aggressivt, hvor det var sikkert, og strategisk, hvor det betød mest. Besparelser på licenser kom fra de 70 %, de flyttede. Alt andet handlede om risikostyring.
Den tekniske migrering var ambitiøs, men metodisk. Det tog måneder, ikke år, og det krævede en plan, et budget og dedikerede ressourcer fra teamet.
Moderniseringen indebar følgende:
Teknisk migrering: Datareplikering, refaktorering af applikationer (særligt skiftet til moderne frameworks som Angular og NodeJS), test og validering. De benyttede en agil udviklingsproces med flere bølger for at mindske risikoen og indsamle feedback.
Parallel drift: Fintech-virksomheden kørte deres legacy-system og cloud-løsning side om side i en længere periode. Hvorfor? Som en forsikring. Hvis cloud-implementeringen fejlede katastrofalt, kunne de skifte tilbage til legacy-systemet på få timer i stedet for dage. Dette sikkerhedsnet betød, at teamet kunne bevæge sig hurtigere, fordi de ikke var bange for uigenkaldelige beslutninger. Den psykologiske værdi af en nødudgang bliver ofte undervurderet.
Efteruddannelse af teamet: Driftsteamet kendte legacy-infrastrukturen ud og ind. De kendte ikke til Kubernetes, cloud-overvågningsplatforme, værktøjer til omkostningsstyring eller CI/CD-pipelines. Virksomheden investerede i ekstern træning, interne workshops og gav teamet tid til at lære. Nogle forlod virksomheden i denne fase: for meget forandring, for hurtigt. Andre blev og udviklede sig fra at være "infrastruktur-viceværter" til at blive arkitekter.
Skift af værktøjer: Overgangen fra legacy-overvågning og logning til cloud-native værktøjer skabte mere støj end forventet. De nye værktøjer gav flere alarmer. Teamet var nødt til at finjustere, konfigurere og lære, hvordan "normaltilstanden" så ud i cloud-systemer.
Uforudsete hændelser: Uventede redesigns af cloud-arkitekturen, omkostninger til dataoverførsel og præstationsoptimering, der krævede en omlægning af applikationsforespørgsler. Det var reelle penge og kedelige udgifter, som business casen måtte absorbere.
Men det, der overraskede dem mest, var: deres cloud-regning var højere end forventet i den første måned. Omkostningerne til dataoverførsel var høje. De overprovisionerede ressourcer, mens de optimerede ydeevnen. Driftsteamet vidste endnu ikke, hvordan man optimerede cloud-omkostninger (det er et andet paradigme: man betaler for beregningskraft, ikke hardware). Derfor tog det måneder at finde frem til de faktiske cloud-effektive konfigurationer. Dette er kløften mellem "vi er flyttet i skyen" og "vi driver cloud effektivt", som de fleste virksomheder overser.
TrustPortals cloud-modernisering leverede 40–50% reduktion i driftsomkostninger, hvilket er resultatet af systematisk og metodisk arbejde på tværs af flere dimensioner.
Hvor kom besparelserne fra? Det typiske mønster ser således ud:
Licensering: Flerårige legacy-kontrakter udløb. Virksomheden valgte ikke at forny dem. Omkostningerne blev elimineret.
Infrastruktur: Cloud-hosting til 70 % af deres arbejdsbelastning kostede, efter optimering, mindre end on-premise-infrastruktur kombineret med den administrerede hostingaftale. Ikke så dramatisk som man kunne håbe, men en reel besparelse.
Omplacering af medarbejdere: Virksomheden afskedigede ikke driftsteamet. De omplacerede dem. Teammedlemmerne rykkede over i platform engineering (opbygning af infrastructure-as-code-pipelines, interne værktøjer), site reliability engineering (overvågning og incident response) og andre roller med større gennemslagskraft. Samme antal ansatte, men et andet output. Det frigjorde kapacitet til nye projekter. Ikke en "besparelse" i regnskabsmæssig forstand, men værdiskabelse, der ikke eksisterede før.
Operationel effektivitet: Automatiseringsfokuserede deployment-pipelines, forudsigelig skalering og færre manuelle indgreb. Antallet af hændelser faldt. Tiden brugt på at "slukke ildebrande" i legacy-infrastruktur blev reduceret. Det akkumuleres over tid.
Intervallet på 40–50 % (frem for et enkelt tal) afspejler virkeligheden af, at år 1 havde engangsomkostninger (migrering, efteruddannelse, beredskab). Fra år 2 og frem er det mere forudsigeligt. Desuden øgede virksomheden deres cloud-forbrug (nye funktioner og platformsmuligheder), men væksten medførte ikke en proportional stigning i omkostningerne. Dette skete, fordi cloud kan skalere, mens legacy-systemer ikke kan. Det er den gearing, der skaber de langsigtede gevinster.
Omkostninger er ikke det eneste målepunkt. Driften ændrede sig også fundamentalt.
Før: driftsteamet var reaktivt. Deployments var manuelle, scriptede og fejlbehæftede. Overvågning var præget af kaos og alarmer: for mange falske positive og for mange notifikationer om problemer, der løste sig selv. Skalering krævede indkøb af hardware og budgetgodkendelser måneder i forvejen.
Efter: fokus på automatisering. Continuous deployment-pipelines, der kører containeriserede applikationer på cloud-infrastruktur. Forudsigelig skalering (cloud håndterer det). Overvågningen støjer mere i starten, men når den er finjusteret, er den faktisk intelligent. Det går hurtigere at reagere på hændelser, fordi teamet ikke skal skifte kontekst mellem at løse legacy-problemer og udføre nyt arbejde.
Ændringen i bemandingen: fire tidligere driftsingeniører blev til to platformingeniører, to site reliability engineers (SREs) samt en række konsulenter, der kunne skaleres op eller ned efter behov. Samme antal medarbejdere (stort set), men med en anden vægtstangseffekt. Platformingeniørerne har ansvaret for infrastructure-as-code, CI/CD-pipelines, interne værktøjer og strategien for containerisering. SRE-teamet står for overvågning og incident response. Begge roller har stor betydning og er svære at erstatte. De gamle roller var præget af manuelt udførelsesarbejde med lav gennemslagskraft.
Den skjulte gevinst: tid frigjort gennem automatisering. Platformteamet kunne nu overtage en større del af applikationsinfrastrukturen. Funktioner blev leveret hurtigere, og antallet af hændelser, der påvirkede kunderne, faldt med 60 %. Det er en gevinst, der akkumuleres over tid.
Udfordringen: cloud-overvågning er anderledes; logfilerne er mere støjende, og traces er komplekse. Teamet måtte lære nye mentale modeller for fejlfinding i distribuerede systemer og containeriserede miljøer. Der var måneder, hvor følelsen af "vi får flere alarmer" føltes som et skridt tilbage. Det var det ikke; de så blot det, som den gamle infrastruktur havde skjult.
Hvis de skulle gennemføre dette projekt igen, ville de ændre fire ting:
Kortlæg jeres reelle legacy-omkostninger først. Før du kan retfærdiggøre en modernisering, skal du vide, hvad du moderniserer væk fra. Start med en revision: licenser, infrastruktur, arbejdskraft, alt sammen. Saml det i ét regneark.
Start med en nem sejr. Flyt ikke jeres indtægtsgenererende kerne først. TrustPortal var kloge her: De startede med interne værktøjer og kundedashboards, mens de sideløbende byggede deres nye cloud-native platform. Lav risiko. Høj læring. Hvis det pilotprojekt var slået fejl, ville de have mistet måneder og penge, men ikke kundernes tillid. Vælg én arbejdsbyrde eller ét system, der er isoleret, ikke-kritisk, men dyrt at drive. Modernisér det først. Lær af det, og skaler derefter.
Kør legacy og cloud parallelt i længere tid, end du tror er nødvendigt. Den psykologiske værdi af en nødudgang er prisen værd. Det sikkerhedsnet betød, at teamet kunne bevæge sig hurtigere, fordi de ikke var bange for uigenkaldelige beslutninger. Budgettér med det fra starten.
Invester tidligt i efteruddannelse og omplacering af teamet. Dette var den sværeste del. Infrastrukturteams byggede deres identitet op omkring at "holde systemerne kørende." Cloud-modernisering gør den identitet forældet. Du beder dem om at lære nye værktøjer og nye paradigmer og acceptere, at deres gamle ekspertise pludselig er mindre værd. TrustPortal gjorde det godt: De omformulerede det som en mulighed for at udføre arbejde med større gennemslagskraft (platform engineering, SRE, infrastructure-as-code). Ikke alle købte præmissen. Nogle forlod virksomheden. Det er normalt. Men dem, der blev, blev arkitekter. Så invester i den overgang. Det betaler sig.
Systematisk cloud-modernisering giver mening, hvis:
Hvis alle fire punkter gør sig gældende for jer, er modernisering sandsynligvis værd at undersøge. Hvis kun ét eller to gør sig gældende, bør I regne tallene igennem, før I forpligter jer.
If this resonates, start small.
First: audit. Map your current legacy spend. Licensing, infrastructure, labour. Every pound. Put it in a spreadsheet. That baseline is your north star.
Second: identify a pilot. One system, one workload, one team. Something with clear boundaries and measurable impact. For the fintech, it was internal tools and customer dashboards, used by dozens of people, non-revenue-critical, but expensive to run on legacy infrastructure. Modernise that. Measure the outcome. Time, cost, team friction, unexpected problems. Let those learnings shape your next move.
Third: build your business case. "We spent £X on migration, saved £Y on run costs, and got Z as a bonus (faster deployments, fewer incidents, team morale)." That's persuasive. Most companies skip this and wonder why leadership won't fund round two.
If you're ready to start that process, Imaginary Cloud helps companies architect and execute modernisation strategies. We've worked through these decisions before. Let's talk about yours.
Cloud-modernisering er ikke magi, men metodik.
Kortlæg, hvad du rent faktisk betaler for. Start med noget med lav risiko. Kør parallelle systemer i længere tid, end du tror er nødvendigt (forsikringen er det værd). Omskool dit team til at være forretningspartnere frem for forældede infrastrukturpassere. Mål alt obsessivt. Fejr sejrene og anerkend de uventede omkostninger, for begge dele vil opstå.
Fintech-virksomheden sparede 40–50 % ved at være systematisk. Det kan du sandsynligvis også. Men kun hvis du starter med at forstå, hvad du sparer væk fra.
Det afhænger af din sammensætning af arbejdsbelastninger, og hvad der gemmer sig i din legacy-infrastruktur. Arbejdsbelastninger med høje licensomkostninger (virksomhedsdatabaser, middleware, kommercielle overvågningsværktøjer) ser ofte besparelser på over 50 %. Operationer med lavere overhead kan se 20–30 %. Men de fleste mellemstore virksomheder har skjulte legacy-omkostninger, der gør 40 %+ realistisk, hvis du foretager revisionen først.
Hvis ledelsen mistede tålmodigheden med fasen for parallel kørsel. Det er her, omkostningerne er højest, og fordelene endnu ikke er synlige. Fintech-virksomhedens CFO var nødt til at stole på planen i fire måneder i træk. Hvis den opbakning var vaklet, ville de have sprunget over, hvor gærdet er lavest, og destabiliseret migreringen. Organisatorisk disciplin er undervurderet.
Sandsynligvis ikke, hvis den håndterer omsætning. Byrden i forhold til regulering, revision og risiko er for høj. Hybrid er din ven. Modernisér alt omkring den. Lad kernen være kedelig og stabil.
Tilbagebetaling i måned 6. Men teamet så operationelle forbedringer (hurtigere implementeringer, bedre overvågning, containeriseret skalerbarhed) meget tidligere, omkring måned 8, da den parallelle kørsel sluttede, og de forpligtede sig fuldt ud til cloud-drift.
Nej. Men cloud er ikke et magisk værktøj til at skære omkostninger. Det er løftestang. Hvis du kører en oppustet legacy-infrastruktur med høje licensomkostninger og manuelle processer, kan cloud mangedoble din effektivitet. Hvis dit nuværende setup allerede er slankt, sparer cloud måske ikke meget. Regnestykket betyder noget.
Hvis du blot er ved at undersøge mulighederne for modernisering. Sednas historie viser en anden tilgang til og et andet resultat af modernisering af legacy-systemer.
Men hvis du er klar til at gå fra cases til handling, så kontakt Imaginary Cloud. Vi hjælper virksomheder med at arkitektere og eksekvere moderniseringsstrategier, der er baseret på reelle begrænsninger og målbart afkast.
Virkelighedens infrastruktur er kompleks. Lad os tale om din.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
People who read this post, also found these interesting:
