Cloud-migrering trin for trin

Hvornår giver cloud-migrering mening?

Skyen er ikke et mål i sig selv. En cloud-migrering giver mening, når den løser et konkret problem, I allerede har. Det kan være hardware, der nærmer sig sin levetid, en server i et lokale ingen længere vil have ansvaret for, eller en løsning, der ikke kan skalere, når trafikken stiger. Det kan også være ønsket om bedre backup, højere oppetid eller adgang til data uden for kontoret.

Skyen er til gengæld sjældent svaret på alt. Et system, der kører stabilt på fast, forudsigelig belastning, bliver ikke nødvendigvis billigere i skyen — flytter man det uændret, betaler man ofte for fleksibilitet, man ikke bruger. Skalering er en reel fordel, når belastningen svinger, men en omkostning, hvis den er konstant. Derfor bør beslutningen bygge på jeres faktiske drift, ikke på en generel forventning om, at cloud altid er både billigere og bedre.

Skriv derfor målet ned, før projektet begynder. Hvad skal være bedre bagefter, og hvordan måler I det? Lavere driftsrisiko, kortere gendannelsestid, mulighed for at vokse uden nyindkøb af hardware, eller mindre intern tid brugt på servere. Et tydeligt mål gør det muligt at vælge den rigtige migreringsstrategi frem for at flytte alt, blot fordi det er teknisk muligt.

Kortlæg det nuværende miljø

De fleste mislykkede migreringer skyldes ikke selve flytningen, men det, ingen vidste var der. Derfor er kortlægningen det vigtigste trin. Lav en oversigt over servere, tjenester, databaser, integrationer og de data, der faktisk bruges. Notér, hvad hvert system afhænger af, hvem der ejer det, og hvor kritisk det er, hvis det er nede. Skjulte afhængigheder — en gammel delt mappe, et planlagt job eller en integration til et fagsystem — er det, der oftest overrasker undervejs.

Kortlægningen bør også omfatte datamængder og datakvalitet. Hvor mange gigabyte skal flyttes, hvor hurtigt ændrer de sig, og hvad kan arkiveres eller slettes i stedet for at følge med? En migrering er en god anledning til at rydde op frem for at flytte år gammelt roderi over i en ny infrastruktur. Jo bedre I kender jeres data, desto lettere er det at estimere både overførselstid og den nødvendige kapacitet.

• Servere, tjenester og databaser — med ejer og kritikalitet for hver.
• Integrationer og afhængigheder mellem systemer, også de udokumenterede.
• Datamængder, ændringstakt og hvad der kan arkiveres eller slettes.
• Krav til oppetid, svartid og hvornår systemet må være utilgængeligt.
• Licenser, certifikater og adgange, der skal følge med eller fornyes.

Vælg målarkitektur og strategi

Når kortlægningen er på plads, kan I vælge, hvordan hvert system skal flyttes. Den enkleste metode er at løfte og flytte en server næsten uændret til en tilsvarende server i skyen. Det er hurtigt og risikoen er lav, men I får ikke skyens fulde fordele, og omkostningen kan blive højere end forventet. Alternativt kan systemet tilpasses undervejs, så det udnytter administrerede databaser, automatisk skalering eller standardtjenester frem for at drive alt selv.

For nogle systemer er den rigtige beslutning slet ikke at flytte dem. Et ældre system tæt på udfasning kan fint blive stående, indtil det erstattes, og en standardfunktion kan nogle gange dækkes bedre af en færdig cloud-tjeneste end af jeres egen server. En god målarkitektur er sjældent ren — den er en blanding, hvor hvert system er placeret der, hvor det giver mest mening for drift, sikkerhed og økonomi.

Vær samtidig opmærksom på leverandørafhængighed. Jo tættere en løsning bindes til én cloud-udbyders særlige tjenester, desto sværere kan den være at flytte igen. Det er ikke i sig selv forkert, men det bør være et bevidst valg. Overvej fra begyndelsen, hvordan I kommer ud igen, hvis behov, priser eller strategi ændrer sig — og notér det som en del af arkitekturbeslutningen.

Planlæg data, nedetid, test og rollback

Selve migreringen bør planlægges i afgrænsede bølger frem for som ét stort spring. Start med et system, der er vigtigt nok til at være en reel test, men ikke så kritisk, at en fejl lammer forretningen. Flyt det, kør det parallelt et stykke tid, og brug erfaringen til at justere planen for de næste bølger. En trinvis migrering gør fejl mindre og lærdommen større.

Data og nedetid kræver særlig planlægning. Store datamængder tager tid at overføre, og for systemer, der ændrer sig hele tiden, skal I beslutte, hvordan de sidste ændringer synkroniseres, uden at noget går tabt. Læg migreringen i et vindue, hvor nedetid gør mindst skade, og aftal på forhånd, hvor lang nedetid der er acceptabel. For nogle systemer er få minutter fint; for andre skal overgangen være næsten umærkelig, hvilket kræver mere forberedelse.

Test og rollback er det, der gør en migrering tryg. Definér på forhånd, hvordan I ved, at systemet virker efter flytningen — ikke bare at det starter, men at brugere, integrationer og data opfører sig korrekt. Og hav altid en rollback-plan: hvis noget går galt, hvordan kommer I så tilbage til udgangspunktet uden datatab? Behold det gamle miljø, indtil det nye er bevist stabilt. En migrering uden en vej tilbage er et væddemål, ikke en plan.

Sikkerhed, GDPR og drift bagefter

Sikkerheden ændrer sig, når systemer flytter til skyen — den forsvinder ikke, men ansvaret fordeles anderledes. Udbyderen sikrer den underliggende infrastruktur, mens I fortsat er ansvarlige for konti, adgange, konfiguration og selve dataene. Gennemgå derfor rettigheder efter princippet om mindst mulig adgang, slå to-faktor til, og undgå de fejlkonfigurationer — for eksempel åbne lagerspande eller alt for brede adgange — der er blandt de hyppigste årsager til brud i skyen.

Datalokation og GDPR skal med i beslutningen fra begyndelsen. Under GDPR er I dataansvarlige for personoplysninger, og cloud-udbyderen, der behandler dem på jeres vegne, er databehandler. Det kræver en databehandleraftale og et klart billede af, hvor data fysisk opbevares. For mange virksomheder er det et bevidst valg at holde data inden for EU af hensyn til både lovgivning og kunders forventninger — så afklar datalokation, før I flytter, ikke efter.

Endelig fortsætter arbejdet efter migreringen. Skyen fjerner ikke behovet for drift; den ændrer den. Sæt overvågning op, så I opdager fejl før brugerne, tag stilling til backup og en testet gendannelse i det nye miljø, og hold øje med omkostningerne, der let vokser umærkeligt, når skalering er så let. Aftal, hvem der ejer driften, og hvem I ringer til, når noget går galt. En cloud-migrering er først lykkedes den dag, det nye miljø kører stabilt, sikkert og til en pris, I kender.