Netværk, identitet og backup skal stå klar hos den nye udbyder, før det første system flytter. Det er fundamentet, alle senere flytninger bygger på, og et system, der flytter før fundamentet, skal ofte flyttes eller omkonfigureres en gang til.
Rækkefølgen er vores egen fremgangsmåde og følger af, hvad hver del afhænger af. Arbejdsbelastningerne, altså de servere og databaser, forretningen bruger, kan først drives sikkert, når de kan nås, når nogen kan logge ind på dem på en styret måde, og når der findes en kopi, der kan gendannes.
Netværket først
Det nye miljø skal kunne tale med det gamle, så længe begge kører. Det kræver en forbindelse mellem de to, enten krypteret over internettet eller som fast forbindelse. Læs forbindelsen mellem miljøer.
Adresseplanen skal laves, før nogen opretter en server. Overlapper de interne adresser i det nye miljø med dem, I allerede bruger, kan de to miljøer ikke rute til hinanden uden omveje. Det er svært at rette, når der først står systemer i drift.
Til netværket hører også navneopslag, firewallregler og adgangen udefra. Beslut, hvor DNS skal styres fra under og efter flytningen, og hvem der må ændre det. Skal kunder eller samarbejdspartnere åbne for jeres nye adresser, skal de have besked i god tid. Det står i omstillingen.
Identiteten dernæst
Hvem må logge ind i det nye miljø, og hvordan? Det skal være på plads, før der ligger data derinde. Det gælder administratorerne, de tjenestekonti, som systemerne bruger til at tale sammen, og de konti, en eventuel partner skal have under flytningen.
Vælg, om administratorerne skal logge ind med den identitet, I allerede har, eller med særskilte konti hos den nye udbyder. Den første model er lettere i hverdagen og binder det nye miljø til jeres nuværende identitetsløsning. Den anden giver adskillelse og flere konti at holde styr på. Begge kan være rigtige. Det afgørende er, at valget træffes, før der oprettes konti i hast.
Totrinsgodkendelse for alle administratorer, en nødadgang, der er beskrevet og afprøvet, og en log over, hvem der gør hvad, hører med fra første dag. Ligger identiteten i dag hos den udbyder, I forlader, er den en afhængighed i sig selv. Den kan blive tilbage, selv om serverne flytter.
Backup før første system
Den første server i det nye miljø skal have en backup, der virker, og en gendannelse, der er prøvet. Backupløsningen kan være den samme som i dag eller en ny, men den skal kunne nå det nye miljø, og kopien skal ligge et andet sted end originalen. Læs backup i Europa.
Under flytningen findes data to steder, og det er fristende at regne det gamle miljø som backup. Det holder kun, indtil det gamle miljø lukkes, og det er ikke en kopi, der er beskyttet mod sletning eller kryptering. Brug det som tilbagefald, og hold backup for sig.
Overvågning og logs
Når fundamentet står, skal overvågningen med. Det nye miljø skal kunne ses fra samme sted som det gamle, så driften har ét billede under overgangen. Logs fra den nye udbyders platform skal sendes derhen, hvor I allerede samler dem. Læs overvågning og logs.
Så arbejdsbelastningerne
Først nu flytter systemerne. Begynd med et system, der betyder lidt for forretningen og ligner mange af de andre. Det tester fundamentet og metoden uden at sætte meget på spil. Derefter følger grupper af systemer, der hører sammen.
Systemer, der taler meget med hinanden, skal flytte samtidig eller tæt på hinanden. Står en applikation i det nye miljø og dens database i det gamle, går trafikken over forbindelsen imellem, og svartiden kan blive en anden, end brugerne er vant til. Det kan også give løbende udgående trafik, som udbyderen må tage betaling for. Læs datatyngde og svartid.
De mest kritiske systemer kommer sidst, når fundamentet er afprøvet af de andre. Det gamle miljø lukkes til allersidst, og først når backup, overvågning og adgang er bekræftet i det nye.
Har I også programmer, der skal skiftes, har europæiske-alternativer.dk en rækkefølge for et hus, der kører på Microsoft. Den handler om programmerne. Her er det infrastrukturen under dem.
Hvad det kræver, og hvad det koster at lade være
Fundamentet er et selvstændigt stykke arbejde, før noget flytter. Det kræver en netværksansvarlig, en, der ejer identiteten, og en, der ejer backup, og tid hos hver af dem i en periode, I selv sætter et lavt og et højt skøn på. Det synes ikke af meget for ledelsen, for der er intet system, der har skiftet sted, når det er færdigt.
Springes fundamentet over, flytter de første systemer ind i et miljø, der bygges om under dem. Adresser ændres, adgange laves om, og backup kommer bagefter. Det betyder ekstra nedetid, gentaget test og en periode, hvor data kun findes ét sted. Det er den slags arbejde, der ikke stod i planen, og som tager tid fra det, der gjorde.
Det skal I lade være med
- At flytte et system for at vise fremdrift · et system i et halvfærdigt miljø skal ofte flyttes igen.
- At regne det gamle miljø som backup · det er et tilbagefald, og det forsvinder, når det lukkes.
- At oprette administratorkonti efter behov · konti oprettet i hast bliver hængende med for mange rettigheder.
Det skal valget kunne vise
- ☐ En adresseplan uden overlap med de nuværende net.
- ☐ En beslutning om identitet for administratorer og tjenestekonti.
- ☐ En gendannelse fra backup, der er prøvet i det nye miljø, før første system flytter.
- ☐ En rækkefølge for systemerne med begrundelse for hver gruppe.
Senest gennemgået: november 2026.
Næste skridt
Skriv de tre dele af fundamentet op med en ansvarlig ud for hver, og sæt en dato, hvor de skal være klar.
Læs også: Sikkerhedsmodellen følger ikke med · Flyt, tilpas eller byg om
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
