Et system kan komme over til en ny udbyder på tre måder: det flyttes uændret, det tilpasses på enkelte punkter, eller det bygges om til den nye platform. Metoden vælges pr. system, for den afgør, hvor mange uger og hvilke folk flytningen kræver, og hvor meget der kan gå galt.
Tredelingen er vores egen forenkling. Udbydernes migreringsvejledninger bruger finere inddelinger med flere kategorier, og de er skrevet til flytning ind på deres egen platform. Her bruger vi tre, fordi det er tre forskellige slags arbejde for den, der skal drive resultatet. Ved siden af dem står tre udfald, der ikke er flytninger: systemet bliver, hvor det er, det lukkes, eller det afløses af et andet produkt.
Flyt uændret
Den virtuelle server løftes over med samme operativsystem, samme programmer og samme konfiguration. Det nye er hypervisoren, lageret og netværket under den. På dansk kaldes det ofte at løfte og flytte.
Metoden kræver mindst af applikationen og mest af infrastrukturfolkene. Diskformatet skal kunne læses af den nye platform, driverne skal passe, netværkskortet får et nyt navn, og faste adresser ændres. Licenser, der er knyttet til hardware eller til en bestemt platform, kan falde bort. Det står i virtuelle servere, hvad der typisk skal prøveflyttes.
Det, I får, er det samme system på et nyt sted. Gamle svagheder følger med. Var serveren dårligt dokumenteret før, er den det også bagefter.
Tilpas
Systemet flyttes med enkelte ændringer, der gør det lettere at drive på den nye platform. Et eksempel er at flytte en database fra en selvstændig server til udbyderens administrerede database med samme åbne motor, at skifte et forældet operativsystem undervejs eller at lægge filer i objektlager i stedet for på en lokal disk.
Her skal applikationsejeren med. Hver ændring skal testes, og testen skal vise, at systemet opfører sig ens før og efter. Tilpasning kan give en lettere drift bagefter, men den gør også flytningen længere, og den binder jer til de tjenester, I tilpasser til. Den administrerede database er et godt eksempel: den sparer arbejde i hverdagen og skal selv kunne flyttes næste gang.
Byg om
Systemet skrives eller sættes sammen på en ny måde, fx i containere, med nye køer eller med en anden datamodel. Det er den eneste metode, der kan fjerne en binding til en udbyders egne tjenester, og den mest omfattende.
Ombygning kræver udviklere, en testperiode og en ny driftsmodel. Den kan sjældent nås inden for den tid, en aftale eller en fornyelse giver. En arkitekt, der arver et system bygget på en udbyders funktioner, kan læse mere i applikationer på udbyderens tjenester.
Vores vurdering er, at ombygning sjældent skal ske i samme bevægelse som flytningen. Flyt eller tilpas først, og byg om, når systemet kører stabilt på det nye sted. Undtagelsen er, når ombygningen er selve grunden til at flytte.
Udfald, der ikke er flytninger
Tre udfald hører med i vurderingen, selv om intet flyttes:
Systemet bliver. Det kan være det rigtige, når det er bundet tæt til andre systemer, når det for nylig er fornyet, eller når risikoen ved at flytte er større end gevinsten. Læs det, der ikke skal flyttes.
Systemet lukkes. En gennemgang kan finde servere, som ingen bruger længere. De slukkes og arkiveres efter jeres regler for opbevaring.
Systemet afløses. Et program kan erstattes af et andet produkt, ofte som abonnement. Så er det et programvalg, og infrastrukturen under det nye produkt drives af andre end jer. Læs SaaS flytter ikke med.
Sådan vælger I pr. system
Stil fire spørgsmål til hvert system:
Hvad er systemet bygget på? En almindelig virtuel server med standardprogrammer peger mod at flytte. Et system, der bruger udbyderens egne tjenester, peger mod at tilpasse eller bygge om.
Hvad skal det kunne om tre år? Står systemet til at blive udskiftet, er det spild at tilpasse det. Står det til at vokse, kan en tilpasning betale sig.
Hvem kender det? Uden en applikationsejer, der kan teste, er tilpasning og ombygning svære at gennemføre sikkert.
Hvad binder det til? Licenser, faste adresser hos kunder, integrationer og data, der skal ligge tæt på andre data. Læs datatyngde og svartid.
Svarene giver en metode og en begrundelse pr. system. Skriv begge ned. Begrundelsen er den, der skal holde, når nogen spørger om et halvt år.
Hvad det kræver, og hvad det koster at lade være
En vurdering pr. system tager typisk et par timer for den, der kender systemet, og lidt mere, når applikationsejeren skal spørges. Overslaget for selve flytningen gives i uger og i roller: hvor mange dage infrastrukturfolk, applikationsejer og eventuelt udviklere skal bruge, med et lavt og et højt bud for hver rolle. Kronebeløbene sætter økonomi selv på.
Uden vurderingen bliver metoden valgt for hele miljøet på én gang. Vælger I at flytte alt uændret, flytter I også de servere, der burde være lukket, og de svagheder, der burde være rettet. Vælger I at bygge alt om, vokser projektet ud af den tid, I har, og det gamle miljø skal køre ved siden af, længere end planlagt. Begge dele koster i parallel drift og i egne timer.
Det skal I lade være med
- At vælge én metode for hele miljøet · systemerne er forskellige, og metoden skal passe til hvert af dem.
- At bygge om undervejs uden en beslutning · små forbedringer under flytningen bliver til et udviklingsprojekt, ingen har planlagt.
- At regne en uændret flytning for risikofri · drivere, adresser og licenser skal stadig prøveflyttes.
Det skal valget kunne vise
- ☐ Metode eller udfald pr. system: flyt, tilpas, byg om, bliv, luk eller afløs.
- ☐ En begrundelse for hvert valg.
- ☐ Et overslag pr. system i uger og roller, givet som et spænd.
- ☐ Hvem der tester hvert system, og hvornår testen er bestået.
Senest gennemgået: november 2026.
Næste skridt
Lav en liste over jeres systemer, og skriv metoden ud for hvert af dem, før nogen taler om udbydere.
Læs også: Flyt nu, flyt senere, bliv eller luk · Rækkefølgen i infrastrukturen
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
