Flytter I servere og data fra Azure til en europæisk udbyder, mens medarbejderne bliver på Microsoft 365, bliver identiteten hos Microsoft. Det skyldes, at Microsoft 365 bruger Entra ID til brugere og login, så den nye platform skal enten stole på Entra ID eller have sin egen identitet ved siden af, og det valg er det vigtigste i målarkitekturen.
Det er den store forskel fra en flytning væk fra en udbyder, der kun leverer infrastruktur. I Azure hænger servere, lager og netværk sammen med kontorpakken gennem identiteten. Planen for at kunne komme ud af Azure står på exit-plan.dk. Det, der binder i aftalen, står på vendor-lock-in.dk. Navne og fakta nedenfor er pr. november 2026.
Hvorfor identiteten bliver
Microsoft beskriver på Microsoft Learn (opdateret 30. oktober 2026), at Microsoft 365 bruger Microsoft Entra ID til identiteter og godkendelse. Entra ID er en cloudbaseret identitets- og godkendelsestjeneste, der følger med abonnementet. Der er to modeller. I den ene findes brugerne kun i skyen. I den anden, den hybride, synkroniseres brugere fra et lokalt Active Directory til Entra ID, og Entra ID godkender enten selv eller sender godkendelsen videre til en anden identitetsudbyder.
Bliver Microsoft 365, bliver Entra ID altså også. Det er vores konklusion af Microsofts beskrivelse. Serverne kan flytte til Europa, og identitetslaget, som alle logger på igennem, ligger stadig hos samme udbyder som før.
Tre måder at lægge identiteten
Den nye platform stoler på Entra ID. Administratorer og brugere logger på den nye udbyder og på programmerne der med deres Microsoft-konto. Det er enkelt for brugerne og bevarer ét sted at styre adgang. Til gengæld bliver Microsoft en forudsætning for adgang til de systemer, I flyttede.
En egen identitet til platformen. Den nye platform og dens systemer får en selvstændig identitetstjeneste, I driver eller køber hos en europæisk udbyder. Administratorer har konti, der ikke afhænger af Microsoft. Det giver adskillelse og betyder to steder at styre konti og to sæt regler, der skal holdes i takt.
Lokalt Active Directory som kilde. Har I stadig et lokalt Active Directory, kan det være kilden for både Entra ID og den nye platform. Så ejer I selv kilden til identiteterne, og I skal stadig drive den. Det kræver servere, opdateringer og et Active Directory, der er sikret.
Der er ikke ét rigtigt svar. Spørgsmålet er, hvad I vil opnå med flytningen. Handler det om, hvor data ligger, kan den første model være nok. Handler det om at kunne drive systemerne uden Microsoft, er den anden eller tredje nødvendig, i det mindste for administratorerne.
Administratorer først
Uanset model er administratorkontiene de vigtigste. Den, der kan logge ind som administrator på den nye platform, kan ændre alt. Overvej at give administratorerne konti, der ikke er afhængige af Entra ID, også hvis brugerne bliver der. Så kan platformen drives, selv om forbindelsen til Microsoft er nede, eller adgangen er spærret. Se Hvem kan logge ind?
Det øvrige, der er særligt for Azure
Licenser. Windows Server og SQL Server på servere hos andre udbydere har deres egne licensregler. Vi har ikke læst Microsofts produktvilkår for det og beskriver dem derfor ikke. Licensartiklen om Windows og SQL hos andre udbydere er stedet at begynde, og Microsofts egne vilkår skal læses og dateres, før der regnes.
Kildekode og byggekæde. Bruger udviklerne Azure DevOps eller tilsvarende, er det en tjeneste for sig, som kan blive eller flytte uafhængigt af serverne. Se Kildekode og byggekæde.
Enheder og politikker. Pc’er og telefoner, der styres gennem Microsofts værktøjer, kan være knyttet til Entra ID. De bliver, hvor de er, når serverne flytter.
Netværket. Forbindelser mellem kontor, Azure og andre miljøer skal lægges om. Planlæg, hvordan brugerne når systemerne hos den nye udbyder, og hvad der skal tale med Microsoft 365 bagefter. Se Forbindelsen mellem miljøer.
Hvad det kræver, og hvad det koster at lade være
Valget af identitetsmodel er et arkitekturarbejde på nogle uger, fordi det berører alle systemer, administratorer og brugere. Det skal tages, før den første server flytter. En egen identitet til platformen er en varig driftsopgave med konti, regler, sikring og overvågning.
Lader I identiteten ligge uden at have valgt, ender I med en platform i Europa, som kun kan nås gennem en tjeneste hos den udbyder, I ville gøre jer mindre afhængige af. Det kan være fint. Er det ikke, viser det sig først, når forbindelsen er nede, eller en kunde spørger, hvem der styrer adgangen. Så skal identiteten lægges om på en kørende platform, og det er dyrere end at gøre det fra start.
Det skal I lade være med
- At flytte serverne og glemme login · identiteten afgør, hvem der kan nå dem.
- At lade administratorerne afhænge af samme konto som brugerne · platformen skal kunne drives uden.
- At regne på licenser uden at have læst vilkårene · reglerne er Microsofts og skal læses med dato.
Det skal valget kunne vise
- ☐ Den valgte identitetsmodel og begrundelsen.
- ☐ Hvordan administratorer logger på den nye platform.
- ☐ Hvad der bliver hos Microsoft, og hvad der flytter.
- ☐ Licensvilkårene læst hos Microsoft med dato.
Kilder
- Microsoft Learn, Determine your cloud identity model, opdateret 30. oktober 2026, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find ud af, om I bruger kun skyen eller den hybride model i dag. Det er udgangspunktet for valget af identitet på den nye platform.
Læs også: Fra AWS til en europæisk udbyder · Sikkerhedsmodellen følger ikke med
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
