Det meste af det, der kører på virtuelle servere og åbne databaser, kan flyttes til en europæisk udbyder med begrænsede ændringer. Jo mere et system bruger en udbyders egne tjenester, jo mere skal bygges om, og programmer, I køber som abonnement, flytter slet ikke med, fordi I ikke driver infrastrukturen under dem.
Spørgsmålet “kan vi komme over til en europæisk cloud?” har derfor ikke ét svar. Det har et svar pr. systemtype. Den, der skal drive resultatet, har mest brug for at vide, hvor meget der skal ændres, før systemet kører igen på det nye sted. Nedenfor står systemtyperne sorteret efter netop det, fra mindst til mest arbejde.
1. Virtuelle servere med almindelige programmer
En virtuel server med Windows eller Linux og programmer, I selv har installeret, er det letteste at flytte. Serveren er en fil med en disk og en beskrivelse af hardwaren, og den kan som regel løftes over på en anden hypervisor.
Let betyder ikke uden arbejde. Ved flytning til en KVM-baseret platform skal gæsten typisk have de rigtige drivere installeret på forhånd, firmwaren skal passe til den måde, serveren starter på, og netværkskortet skifter, så faste adresser og reservationer skal rettes. Er disken krypteret med nøgler i en virtuel TPM, kan den tilstand ikke altid følge med, og så skal nøglerne ligge klar. Det står mere udførligt i virtuelle servere.
Licenserne er et punkt, der let overses. Windows Server og SQL Server har egne regler for, hvornår en licens må flyttes, og hos hvilke udbydere den må bruges. Reglerne er samlet i artiklen om licenser til Windows og SQL Server.
2. Databaser på en åben motor
En database på PostgreSQL, MySQL eller MariaDB, som I selv driver på en server, flytter næsten som en virtuel server. Motoren findes hos alle udbydere og på egne servere, og dataformatet er det samme. Det, der tager tid, er datamængden, nedetiden under omstillingen og testen af, at programmerne opfører sig ens bagefter.
3. Databaser på udbyderens egen motor eller som færdig tjeneste
Her deler billedet sig. En administreret database med en åben motor kan som regel genskabes hos en anden udbyder, der tilbyder samme motor. En database på udbyderens egen motor er en anden sag. Udbyderen kan skrive, at den er kompatibel med en åben motor, men hvad der ikke følger med ud, er noget, I skal teste selv. Udvidelser, sikkerhedskopier, overvågning og de værktøjer, der hører til, skal også findes på det nye sted. Læs databaser ved flytning.
4. Applikationer bygget på udbyderens egne tjenester
Funktioner, der kører uden servere, køer, hændelser, identitet til tjenesterne og udbyderens egne lagerformer er bygget til én platform. De europæiske udbydere har ikke nødvendigvis en tjeneste, der svarer én til én. Her er arbejdet en ombygning, og overslaget gives i uger for udviklere og arkitekter. Læs applikationer på udbyderens tjenester.
5. Dataplatforme og analyse
Et datalager eller en analyseplatform er selv tjenesten. Spørgsmålet er her, i hvilke regioner platformen findes, og hvem der står bag den. Kan den ikke ligge, hvor I ønsker, er alternativet en anden platform, og så er det et skifte af produkt med alt, hvad det kræver af ombygning. Læs datalager og analyse.
6. Programmer, I køber som abonnement
Mail, kontorpakke, CRM og lønsystem, der leveres som SaaS, kører på leverandørens infrastruktur. Et skifte af jeres servere ændrer intet ved dem. Skal de have en anden placering, er det et valg af program eller af leverandør. Det forklarer SaaS flytter ikke med.
Det, der går på tværs
Tre ting gælder alle typer. Data, der skal bruges sammen, skal som regel ligge tæt på hinanden, og et system, der teknisk kan klare sig alene, hænger måske fast i andre. Identitet, backup og overvågning skal virke på det nye sted, før det første system kommer over. Og hvert system skal have en ejer, der kan sige, om det virker bagefter.
Hvem der bygger den europæiske infrastruktur, beskriver digital-suveraenitet.dk. Denne artikel ser på jeres egne systemer og på, hvad I kan tage med.
Hvad det kræver, og hvad det koster at lade være
At placere jeres systemer i de seks typer kræver en liste over systemerne og en person, der kender hvert af dem. Er miljøet overskueligt, kan en IT-chef eller arkitekt nå det på to til tre dage. Med mange systemer og få dokumenterede er det mere, fordi noget af tiden bruges på at opklare, hvad der faktisk kører.
Uden opdelingen bliver flytningen vurderet samlet, og det samlede svar bliver forkert. Enten ser alt let ud, fordi de virtuelle servere fylder mest i listen, og projektet løber ind i de få systemer, der skal bygges om. Eller alt ser umuligt ud, fordi et enkelt system er bundet tæt, og de lette systemer bliver, hvor de er, uden at nogen har valgt det. Begge dele koster i egne timer og i parallel drift.
Det skal I lade være med
- At give ét svar for hele miljøet · systemtyperne kræver vidt forskelligt arbejde.
- At regne SaaS med i infrastrukturskiftet · de programmer flytter ikke, når serverne gør.
- At læse “kompatibel” som et testresultat · først en prøveflytning viser, hvad der kommer med.
Det skal valget kunne vise
- ☐ Hvert system placeret i én af de seks typer.
- ☐ Licenser, der er bundet til en bestemt platform eller udbyder.
- ☐ Systemer, der bruger udbyderens egne tjenester, med en ejer til hver.
- ☐ Hvad der skal virke på det nye sted, før det første system flytter: identitet, backup og overvågning.
Kilder
- Proxmox VE wiki, Migrate to Proxmox VE, https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE, læst 8. november 2026.
- AWS, What is Amazon Aurora?, https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv jeres systemer op, og sæt et tal fra 1 til 6 ud for hvert af dem efter typerne ovenfor.
Læs også: Datatyngde og svartid · Seks steder, jeres systemer kan ligge
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
