Flytter I jeres servere til en europæisk udbyder, bliver mail, kontorpakke, CRM og lønsystem, hvor de er. Programmer, I køber som SaaS, kører på leverandørens infrastruktur og flytter kun, hvis I vælger et andet program eller en anden leverandør, og det er en helt anden beslutning end at flytte servere.
Skellet lyder selvfølgeligt for den, der driver infrastrukturen. Det er det ikke altid for en ledelse, der har hørt, at virksomheden skal “ud af den amerikanske cloud”. Hvis forventningen i bestyrelseslokalet er, at alt flytter, og projektet kun flytter servere, er projektet slået fejl, før det begynder. Derfor hører skellet til i det første oplæg.
Tre lag, tre ejere
NIST, det amerikanske institut for standarder, inddelte i 2011 cloud efter, hvem der styrer hvad. Den er amerikansk og ingen europæisk standard. Den giver et sprog til skellet:
Infrastruktur som tjeneste. I styrer styresystem, lager og programmer og eventuelt dele af netværket. Udbyderen styrer bygning, hardware og platformen under det. Det er her, en flytning af servere sker.
Platform som tjeneste. I styrer jeres egne applikationer og nogle indstillinger. Udbyderen styrer servere, styresystem, lager og netværk. Her kan der flyttes, men applikationen skal ofte tilpasses.
Software som tjeneste. I bruger programmet og styrer højst begrænsede indstillinger. Alt under det er leverandørens. Her er der intet for jer at flytte. I kan kun vælge noget andet.
Et infrastrukturskifte rører det første lag og dele af det andet. Det tredje er uden for rækkevidde.
Grænsen mellem lagene er ikke altid skarp i jeres egen liste. Et program, I har købt licens til og installeret på egne servere, hører til det første lag, selv om det kommer fra en stor leverandør. Det samme program købt som abonnement hører til det tredje. Spørg derfor for hvert program, hvem der driver serveren, det kører på. Svaret afgør, hvilket lag det hører til.
Det, der bliver tilbage
Programmerne bliver, og nogle af dem holder infrastruktur fast hos sig.
Identiteten. Microsoft 365 bruger Microsoft Entra ID til brugere og godkendelse, enten kun i skyen eller hybrid, hvor brugere synkroniseres fra et lokalt katalog. Flytter I servere væk fra Azure, mens Microsoft 365 bliver, bliver Entra ID også. Konklusionen er vores egen ud fra Microsofts tekst, og den har betydning for, hvor jeres brugere logges ind, også for de servere, der er flyttet.
Integrationerne. CRM og løn udveksler data med jeres egne systemer. Flytter jeres systemer, ændres adresserne, og integrationerne skal rettes. Har en leverandør en liste over godkendte adresser hos jer, skal den også opdateres.
Data i programmerne. Kundedata i CRM og personaledata i løn ligger hos leverandøren. Er det disse data, ledelsen bekymrer sig om, flytter et infrastrukturskifte ingenting.
Sådan sætter I forventningen
Lav en liste over alle systemer, og sæt et af tre mærker ud for hvert: kører på vores infrastruktur, kører på en platformstjeneste, købes som program. Vis listen for ledelsen, før projektet får et navn.
Ud for de systemer, der købes som program, skrives, hvor leverandøren selv oplyser, at data ligger, og hvem leverandøren er. Det er en oplysning til beslutningen. Om programmet skal skiftes, er et andet spørgsmål, og det besvares ikke af infrastrukturfolkene. Hvordan et alternativ til en kontorpakke vælges, beskriver europaeiske-alternativer.dk om alternativer til Microsoft 365.
Når begge dele skal ske
Nogle virksomheder vil både flytte infrastruktur og skifte programmer. Så er det to projekter med hver sin tidsplan, og rækkefølgen betyder noget. Identitet er det tydeligste eksempel: skifter I kontorpakke, skifter I måske også identitetsløsning, og så skal de flyttede servere logge ind et nyt sted. Planlægges de to projekter hver for sig, skal identiteten bygges om to gange.
Læg de to tidsplaner ved siden af hinanden, og find de steder, hvor de rører hinanden: identitet, integrationer og backup. Dér skal den ene vente på den anden, eller de skal planlægges sammen.
Hvad det kræver, og hvad det koster at lade være
Opdelingen i tre lag kan en IT-chef lave på et par arbejdsdage for et almindeligt miljø, mest fordi alle programmer skal med, også dem, afdelingerne selv har købt. Et oplæg til ledelsen med listen og en side om, hvad projektet løser og ikke løser, tager en dag mere.
Uden opdelingen kan projektet blive målt på noget, det aldrig kunne levere. Servere flytter, regningen for infrastruktur ændres, og så spørger ledelsen, hvorfor kundedata stadig ligger hos en amerikansk leverandør. Den samtale koster tillid og måske et nyt projekt, der skulle have været planlagt sammen med det første.
Det skal I lade være med
- At love ledelsen, at alt flytter · programmerne, I køber som abonnement, er et separat valg.
- At glemme identiteten · den kan blive hos den leverandør, I flytter væk fra.
- At planlægge programskifte og infrastrukturskifte hver for sig · de rører hinanden i identitet, integrationer og backup.
Det skal valget kunne vise
- ☐ Alle systemer mærket som infrastruktur, platformstjeneste eller program.
- ☐ For hvert program: leverandør og oplyst placering af data.
- ☐ Hvor brugerne logges ind før og efter flytningen.
- ☐ Integrationer, der skal rettes, når adresserne ændres.
- ☐ Et oplæg, der siger, hvad projektet løser, og hvad det lader ligge.
Kilder
- NIST, SP 800-145, The NIST Definition of Cloud Computing, september 2011, https://csrc.nist.gov/pubs/sp/800/145/final, læst 8. november 2026.
- Microsoft Learn, Determine your cloud identity model, https://learn.microsoft.com/en-us/microsoft-365/enterprise/deploy-identity-solution-identity-model, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Sæt de tre mærker ud for jeres systemer, og vis listen til ledelsen, før projektet får sit navn.
Læs også: Fra Azure til en europæisk udbyder · Forbindelsen mellem miljøer
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
