Migreringsrammeverket med de seks R-ene

6-Rs-migreringsrammeverket er en strukturert tilnærming for å kategorisere hvordan hver lokale arbeidsbelastning skal flyttes til skyen. Microsoft og bransjen ellers bruker disse seks strategiene — også kalt migreringsmønstre — for å gjøre porteføljebeslutninger effektive og konsistente. I stedet for å bruke en tilnærming som passer for alle, vurderer arkitekter hver applikasjon individuelt og tildeler den den mest egnede R-en.

Rehost (Lift and Shift) betyr å flytte en arbeidsbelastning til Azure med ingen kodeendringer. Du tar det eksisterende VM-imaget eller applikasjonsbinærfilen og kjører den på Azure IaaS. Dette er den raskeste strategien og brukes vanligvis for eldre applikasjoner som er vanskelige å endre, eller for organisasjoner med stramme migreringsfrister. Replikeringsmotoren i Azure Migrate automatiserer rehosting for de fleste Windows- og Linux-VM-er.

Replatform (også kalt Lift, Tinker, and Shift) innebærer mindre optimaliseringer under migreringen uten å endre kjernearkitekturen. Eksempler inkluderer å flytte en selvadministrert MySQL-database fra en VM til Azure Database for MySQL, eller å bytte ut en selvhostet SMTP-relé med Azure Communication Services. Du får fordelene med administrerte tjenester — oppdateringer, sikkerhetskopiering og skalering — uten å skrive om applikasjonslogikken.

Rearchitect (eller Refactor) betyr å endre applikasjonens arkitektur vesentlig for å dra nytte av skybaserte funksjoner. En monolittisk .NET-applikasjon kan deles opp i mikrotjenester som distribueres på Azure Container Apps, eller et batchsystem basert på cron-jobber kan implementeres på nytt som Azure Functions. Rearchitect gir de største langsiktige fordelene innen skalerbarhet og kostnader, men krever også størst investering.

Rebuild betyr å forkaste den eksisterende applikasjonen fullstendig og bygge en ny skybasert løsning. Denne strategien velges når den eldre applikasjonen er for kostbar å vedlikeholde, bruker en teknologistakk som har nådd slutten av livssyklusen, eller rett og slett ikke kan oppfylle virksomhetskravene selv etter migrering. Rebuild gir maksimal fordel av skybasert teknologi, men har lengst tid til verdi. Azure PaaS- og serverløse tjenester som Azure App Service, Azure Functions og Cosmos DB er vanlige mål.

Replace betyr å erstatte en eksisterende lokal applikasjon med et kommersielt tilgjengelig SaaS-produkt som gir tilsvarende eller bedre funksjonalitet. Du kan for eksempel erstatte et lokalt CRM-system med Dynamics 365, eller en eldre filserver med SharePoint Online. Replace eliminerer behovet for infrastrukturadministrasjon fullstendig. Avveiningen er redusert tilpasningsmulighet og potensielt betydelig innsats knyttet til datamigrering og endringsledelse.

Retire er den enkleste strategien — du identifiserer applikasjoner som ikke lenger brukes, er overflødige eller er erstattet, og avvikler dem i stedet for å migrere dem. Innsiktsdata samlet inn av Azure Migrate viser ofte at en betydelig andel (noen ganger 20–30 %) av lokale servere har svært lav utnyttelse eller ingen aktive brukere. Å avvikle disse applikasjonene reduserer migreringsomfanget, lisenskostnadene og den driftsmessige kompleksiteten.

For å velge riktig R må du analysere fire faktorer for hver applikasjon: forretningskritikalitet, teknisk kompleksitet, migreringstidslinje og totalkostnad for eierskap. En enkel webfront-end uten integrasjonsavhengigheter er en god kandidat for Rehost. En applikasjon med hundrevis av lagrede prosedyrer og tilpassede databasefunksjoner kan trenge Rearchitect eller Rebuild. Interne verktøy med lav verdi er gode kandidater for Retire eller Replace.

Azure Migrate har funksjonen Business Case, som automatisk foreslår en migreringsstrategi for oppdagede servere basert på utnyttelsesdata, lisensiering og Azure-priser. Den grupperer arbeidsbelastninger i kategoriene Rehost, Replatform og End-of-Support, slik at du får et forsprang i 6-Rs-klassifiseringen. Du kan overstyre enhver anbefaling og legge til din egen forretningskontekst før du fullfører migreringsplanen.

Når hver applikasjon har fått tildelt en R, grupperer du dem i migreringsbølger. Rehost-kandidater med lav risiko utgjør vanligvis den første bølgen for å bygge opp teamets trygghet og kjennskap til verktøyene. Rearchitect- og Rebuild-prosjekter kjører i parallelle arbeidsstrømmer med lengre tidslinjer. Avhengigheter mellom applikasjoner — for eksempel et weblag som kaller en delt database — må respekteres, slik at relaterte applikasjoner migreres sammen eller i riktig rekkefølge.

6-Rs samsvarer med Adopt-fasen i Microsofts Cloud Adoption Framework. CAF tilbyr maler for bølgeplanlegging, RACI-matriser og spørreskjemaer for vurdering av arbeidsbelastninger som operasjonaliserer 6-Rs i virksomhetsskala. Styringsmekanismer etablert i Ready-fasen — landingssoner, policyer og identitet — må være på plass før migreringsbølgene starter, slik at migrerte arbeidsbelastninger havner i et kompatibelt miljø fra første dag.

I denne leksjonen lærte du at: 6-Rs-rammeverket (Rehost, Replatform, Rearchitect, Rebuild, Replace, Retire) gir et vokabular for migreringsbeslutninger, hver R har en ulik avveining mellom kostnad og hastighet, og Business Case i Azure Migrate kan foreslå strategier automatisk basert på utnyttelsesdata. Deretter skal vi se på hvordan Azure Migrate oppdager og vurderer lokale servere.