Migrera från on-prem till Azure på 90 dagar: Spelboken

Nittio dagar låter knappt för att flytta ett datacenter, och det är det också om man tror att man ska migrera allt. Men 90 dagar räcker gott för att gå från eget datacenter till en första produktionsvåg i Azure med en grund som resten kan följa. Nyckeln är att inte försöka göra allt på en gång, utan att lägga grunden rätt och flytta i vågor. Här är spelboken jag följer, fas för fas.

Dag 1-20: Assessment och beroendekarta

De migrationer som spårar ur gör det sällan av tekniska skäl - de spårar ur för att ingen tog reda på vad som faktiskt körde i datacentret. Den första fasen ägnas därför åt en assessment med Azure Migrate som kartlägger servrar, beroenden och resursförbrukning. Det viktiga är beroendekartan: vilka system pratar med vilka. Det är beroenden som avgör vad som måste flyttas tillsammans, och här upptäcks de bortglömda servrarna som ändå gör något.

Assessmenten ger också det första kostnadsunderlaget. När du ser den faktiska resursförbrukningen kan du dimensionera målmiljön rätt från början, i stället för att lyfta in överstora servrar och betala för luft. Jag brukar passa på att klassa systemen redan här - vad är kritiskt, vad är beroende av vad, vad kan stängas av helt. Den klassningen styr både vilken ordning systemen migreras i och vilken strategi varje system får, och den sparar mycket tid längre fram.

Dag 15-40: Landningszonen ska stå klar

Parallellt bygger jag landningszonen, för att migrera in i ett oförberett Azure är att flytta problemen med sig. Styrning, identitet, nätverk och loggning ska stå klart innan första arbetsbelastningen kommer. Då landar varje migrerat system i en miljö som redan följer kraven. Nätverket kopplas mot det lokala datacentret via en dedikerad förbindelse eller VPN, samlat i en hubb. Att grunden är klar i tid är det som gör resten av tidslinjen möjlig.

Dag 30-60: Välj väg per arbetsbelastning

Varje arbetsbelastning förtjänar ett eget vägval. I praktiken landar jag oftast i några strategier:

• Rehost - lyft och flytta som den är. Snabbast, minskar datacenterberoendet.
• Replatform - mindre anpassningar, till exempel byte till en hanterad databas.
• Refactor - bygg om för molnnytta. Mest värde, störst insats.
• Retire - stäng av det ingen längre behöver. Ofta tillämpligt.

Frestelsen att refaktorera allt direkt är den vanligaste orsaken till att en migration drar ut på tiden. På 90 dagar rehostar jag det som bara behöver bort från datacentret och sparar refaktoreringen till där den verkligen betalar sig.

Retire förtjänar ett särskilt omnämnande, för den är förvånansvärt ofta tillämplig. I nästan varje datacenter finns servrar som ingen längre använder men som ingen heller vågat stänga av. En migration är det perfekta tillfället att äntligen reda ut det - varför flytta och betala för något som inte gör nytta? Att stänga av i stället för att migrera är den billigaste optimeringen som finns, och beroendekartan från assessmenten är det som gör det tryggt att veta vad som faktiskt kan släckas.

Dag 50-80: Första vågen i produktion

Jag migrerar aldrig allt på en gång. Arbetsbelastningarna grupperas i vågor efter beroenden och risk, och den första vågen väljs medvetet liten och okontroversiell. Den vågen är till lika mycket för att slipa processen som för att flytta system. Varje våg avslutas med verifiering: fungerar systemet, är prestandan rätt, är kostnaden som väntat. När första vågen sitter har ni en mall för resten.

Dag 80-90: Rightsizing och plan för avveckling

Två saker missas ofta. Det första är kostnad - en server som var rätt dimensionerad on-prem är sällan rätt i molnet, så rightsizing hör hemma redan i migrationen. Det andra är avveckling av det gamla. Datacenter som lever kvar parallellt äter både pengar och fokus. Sista fasen ägnas åt att justera storlekar och sätta ett datum för avstängning av det migrerade, så att besparingen faktiskt realiseras. Hur man jobbar vidare med kostnad har jag skrivit om i min FinOps-genomgång.

Vad spelboken faktiskt ger

Det som gör 90-dagarsupplägget värt att hålla sig till är att det tvingar fram fokus. Genom att börja med en assessment, ha landningszonen klar i tid och flytta i vågor undviker du de två klassiska fällorna: att försöka flytta allt samtidigt och att migrera in i en oförberedd miljö. Resultatet efter 90 dagar är inte ett tomt datacenter, men en första produktionsvåg i drift, en beprövad process och en grund som resten av portföljen kan följa i samma takt. Det är en betydligt mer förutsägbar väg än ett stort projekt utan etappmål, och den ger något körbart att visa upp redan tidigt.

Relaterat

• Container security: Snyk, Trivy och Falco för runtime-säkerhet i K8s
• Service mesh med Istio vs Linkerd: Trafikkontroll och mTLS i Kubernetes
• Disaster Recovery i molnet: RTO/RPO-design och automatiserade failover-tester

Vill du ta det vidare?

Planerar ni en flytt från eget datacenter till Azure hjälper jag er från assessment till avveckling. Läs om min molninfrastruktur, se exempel i casebook, eller boka ett samtal.