6-R-migrationsframeworket

6-R-migrationsrammeværket er en struktureret tilgang til at kategorisere, hvordan hver lokal arbejdsbelastning skal flyttes til skyen. Microsoft og branchen generelt bruger disse seks strategier — også kaldet migrationsmønstre — til at træffe effektive og ensartede beslutninger for applikationsporteføljen. I stedet for at anvende en ensartet tilgang vurderer arkitekter hver applikation individuelt og tildeler den det mest passende R.

Rehost (Lift and Shift) betyder, at en arbejdsbelastning flyttes til Azure uden kodeændringer. Du tager det eksisterende VM-image eller den eksisterende programbinær og kører den på Azure IaaS. Dette er den hurtigste strategi og bruges typisk til ældre applikationer, der er vanskelige at ændre, eller af organisationer med stramme migrationsfrister. Azure Migrates replikeringsmotor automatiserer rehosting for de fleste Windows- og Linux-VM'er.

Replatform (også kaldet Lift, Tinker, and Shift) indebærer mindre optimeringer under migrationen uden at ændre kernearkitekturen. Eksempler omfatter at flytte en selvadministreret MySQL-database fra en VM til Azure Database for MySQL eller udskifte en selvhostet SMTP-relay med Azure Communication Services. Du får fordelene ved administrerede tjenester — opdateringer, sikkerhedskopier og skalering — uden at omskrive applikationslogikken.

Rearchitect (eller Refactor) betyder, at applikationens arkitektur ændres markant for at udnytte cloud-native-funktioner. En monolitisk .NET-applikation kan opdeles i mikrotjenester, der udrulles på Azure Container Apps, eller et batchsystem baseret på cron-job kan implementeres på ny som Azure Functions. Rearchitecting giver de største langsigtede fordele med hensyn til skalerbarhed og omkostninger, men kræver den største investering.

Rebuild betyder, at den eksisterende applikation kasseres helt, og at der bygges en ny cloud-native-løsning. Denne strategi vælges, når den ældre applikation er for dyr at vedligeholde, bruger en teknologistak, der er udgået, eller ganske enkelt ikke kan opfylde forretningskravene, selv efter en migration. Rebuild giver den største cloud-native-fordel, men har den længste tid til værdiskabelse. Azure PaaS- og serverløse tjenester som Azure App Service, Azure Functions og Cosmos DB er almindelige mål.

Replace betyder, at en eksisterende lokal applikation erstattes med et kommercielt tilgængeligt SaaS-produkt, der leverer tilsvarende eller bedre funktionalitet. Det kan for eksempel være at erstatte et lokalt CRM-system med Dynamics 365 eller en ældre filserver med SharePoint Online. Replace eliminerer administration af infrastruktur fuldstændigt. Ulempen er mindre mulighed for tilpasning og potentielt en betydelig indsats til datamigration og forandringsstyring.

Retire er den enkleste strategi — du identificerer applikationer, der ikke længere bruges, er overflødige eller er blevet afløst, og afvikler dem i stedet for at migrere dem. Opdagelsesdata indsamlet af Azure Migrate viser ofte, at en betydelig andel (nogle gange 20–30 %) af lokale servere har meget lav udnyttelse eller ingen aktive brugere. Afvikling af disse applikationer reducerer migrationsomfanget, licensomkostningerne og den driftsmæssige kompleksitet.

Valg af det rette R kræver analyse af fire faktorer for hver applikation: forretningskritikalitet, teknisk kompleksitet, migrationsplan og samlede ejeromkostninger. En simpel webfrontend uden integrationsafhængigheder er en god kandidat til Rehost. En applikation med hundredvis af lagrede procedurer og tilpassede databasefunktioner kan have brug for Rearchitect eller Rebuild. Interne værktøjer med lav værdi er oplagte kandidater til Retire eller Replace.

Azure Migrate har en funktion kaldet Business Case, der automatisk foreslår en migrationsstrategi for opdagede servere baseret på udnyttelsesdata, licenser og Azure-priser. Den grupperer arbejdsbelastninger i kategorierne Rehost, Replatform og End-of-Support og giver dig et forspring i klassificeringen efter 6-R-modellen. Du kan tilsidesætte enhver anbefaling og tilføje din egen forretningskontekst, før du færdiggør migrationsplanen.

Når hver applikation har fået tildelt et R, grupperer du dem i migrationsbølger. Rehost-kandidater med lav risiko udgør typisk den første bølge, så teamet kan opbygge tillid og fortrolighed med værktøjerne. Rearchitect- og Rebuild-projekter kører i parallelle arbejdsspor med længere tidsplaner. Afhængigheder mellem applikationer — for eksempel et weblag, der kalder en delt database — skal respekteres, så relaterede apps migreres sammen eller i den korrekte rækkefølge.

6-R-modellen stemmer overens med fasen Adopt i Microsofts Cloud Adoption Framework. CAF indeholder skabeloner til bølgeplanlægning, RACI-matricer og spørgeskemaer til vurdering af arbejdsbelastninger, som gør 6-R-modellen operationel i stor skala. De styringsmæssige sikkerhedsforanstaltninger, der blev etableret i fasen Ready — landingszoner, politikker og identitet — skal være på plads, før migrationsbølgerne begynder, så migrerede arbejdsbelastninger fra første dag placeres i et miljø, der overholder kravene.

I denne lektion har du lært, at 6-R-rammeværket (Rehost, Replatform, Rearchitect, Rebuild, Replace, Retire) giver et fælles ordforråd til migrationsbeslutninger, at hvert R indebærer en forskellig afvejning mellem omkostninger og hastighed, og at Azure Migrates Business Case automatisk kan foreslå strategier baseret på udnyttelsesdata. Dernæst ser vi på, hvordan Azure Migrate opdager og vurderer lokale servere.