Hvad koster det at flytte til skyen?
En cloud-migrering koster oftest mellem 320.000 DKK og 5,3 mio. DKK alt efter strategi. Lift-and-shift, hvor servere flyttes som de er, ligger i bunden af spændet, replatform i midten og en refactor til cloud native-arkitektur i toppen. Budgettér også med dobbelte driftsudgifter i overgangen når det gamle og det nye miljø kører parallelt.
Hvad koster det at flytte til skyen? Spørgsmålet gælder selve flytningen, altså projektet, og det skal holdes adskilt fra hvad driften koster bagefter. Migreringsprojektet har sit eget budget, sine egne risici og et prisspænd der næsten helt styres af hvilken strategi I vælger.
Tre strategier, tre prisklasser
| Strategi | Typisk omkostning | Hvad det indebærer |
|---|---|---|
| Lift-and-shift | 320.000 DKK–1,1 mio. DKK | Servere og systemer flyttes som de er til cloud-infrastruktur |
| Replatform | 850.000 DKK–2,7 mio. DKK | Udvalgte dele skiftes til managed services under flytningen, f.eks. database og filhåndtering |
| Refactor | 2,1–5,3 mio. DKK+ | Applikationerne bygges om til cloud native-arkitektur med containere eller serverless |
Lift-and-shift er hurtigst og billigst i projektet, men giver mindst gevinst bagefter: Miljøet er det samme, bare på lejet infrastruktur. Refactor koster mest nu, men giver den laveste driftsudgift og den største fleksibilitet senere. Mange vælger klogt en blanding: lift-and-shift til systemer der skal udfases inden for nogle år, replatform til arbejdshestene og refactor til de systemer der er kernen i forretningen.
Budgetposten der bliver glemt: dobbelte driftsudgifter
I overgangsperioden betaler I for to miljøer på samme tid: Det gamle står der indtil alt er verificeret i det nye. For en migrering der løber over et halvt år, kan paralleldriften blive en sekscifret post, og den mangler påfaldende ofte i den første kalkule.
Regn også med følgeomkostninger i samme periode: datasynkronisering mellem miljøerne, ekstra testarbejde og medarbejdere der holder styr på begge miljøer. En tommelfingerregel er at planlægge med paralleldrift i mindst et kvartal, længere hvis kritiske systemer flyttes til sidst.
Almindelige faldgruber der gør det dyrere
- Hardcodede afhængigheder. IP-adresser, filstier og antagelser om latens der er bagt ind i gammel kode, viser sig først når systemet flytter. Kortlæg afhængighederne før flytningen, ikke undervejs.
- Licenser der ikke følger med. Noget software er licenseret pr. fysisk server eller processor og må ikke køre i skyen uden en ny licens: en forhandling der kan koste både tid og penge.
- Skjulte integrationspunkter. Natlige filoverførsler, printere, scannere og lokale specialsystemer som ingen har dokumenteret, men som forretningen er afhængig af.
- Viden der sidder i væggene. Serveren som “kun Bent ved hvordan man genstarter” er en risiko der skal håndteres før flytningen, ikke efter.
Et scenarie
En virksomhed med otte servere i et lejet rack skal ud af aftalen inden for et år. Kortlægningen viser at fem standardsystemer kan flyttes direkte, at ERP-systemets database bør blive en managed service, og at en egenudviklet kundeportal er en egentlig ombygning værd. Budgettet lander på cirka 1,6 mio. DKK for projektet plus tre måneders paralleldrift, og portalens refactor lægges som en separat etape året efter når flytningen er gennemført. Sådan ser en typisk, risikobevidst migreringsplan ud: en strategi pr. system, ikke én strategi til det hele.
Efter flytningen: optimér
Den første faktura efter migreringen er sjældent den kønneste. Servere der er flyttet direkte over, er ofte overdimensionerede, og gevinsten hentes hjem i optimeringen bagefter: rightsizing, autoskalering og reserveret kapacitet. Planlæg den fase ind fra starten, for det er den der gør at flytningen betaler sig.
Skal I ud af serverrummet eller en driftsaftale der udløber? Hos Weapp arbejder vi med cloud-arkitektur og migreringer som en del af vores ydelser. Kontakt os, så hjælper vi jer med at vælge strategi pr. system.
Ofte stillede spørgsmål
Hvad er forskellen på lift-and-shift, replatform og refactor?
Lift-and-shift flytter serverne som de er til skyen. Replatform skifter udvalgte dele til managed services undervejs, f.eks. databasen. Refactor bygger applikationen om til cloud native-arkitektur med containere eller serverless. Omkostning, tid og langsigtet gevinst stiger i samme rækkefølge.
Hvor lang tid tager en cloud-migrering?
En lift-and-shift af en håndfuld systemer tager ofte to til fire måneder inklusive test. Replatform af det samme miljø handler snarere om fire til otte måneder, og en refactor kan strække sig over et år eller mere. Kortlægningen i starten afgør hvor præcis tidsplanen bliver.
Bliver driften billigere i skyen efter migreringen?
Ikke automatisk. Et miljø der er flyttet direkte over, koster ofte omtrent det samme som før og nogle gange mere fordi serverne er dimensioneret til gammel hardware. Besparelsen kommer når miljøet tilpasses efter flytningen: de rigtige størrelser, autoskalering og managed services i stedet for egne servere.
Skal forretningen stå stille under flytningen?
Nej, en velplanlagt migrering flytter systemer i grupper med testperioder og rollback-plan, og selve overgangen pr. system sker ofte i løbet af en weekend eller en nat. Kritiske systemer kan køre parallelt i begge miljøer indtil det nye er verificeret. Det er det paralleldriften i budgettet er til for.
Hvilke systemer skal ikke flyttes til skyen?
Systemer med licenser der er bundet til egen hardware, meget gamle applikationer der kræver styresystemer som skyen ikke understøtter, og systemer med ekstreme latenskrav til lokalt udstyr. De håndteres ofte som undtagelser i en ellers cloud-baseret strategi eller udskiftes i stedet for at blive flyttet.