Estrutura de migração dos 6 Rs

A estrutura de migração dos 6 Rs é uma abordagem estruturada para categorizar como cada carga de trabalho local deve ser transferida para a nuvem. A Microsoft e o setor em geral usam estas seis estratégias — também chamadas de padrões de migração — para tornar as decisões sobre o portfólio eficientes e consistentes. Em vez de aplicar uma abordagem única para todos os casos, os arquitetos avaliam cada aplicativo individualmente e atribuem a ele o R mais adequado.

Rehospedar (Lift and Shift) significa mover uma carga de trabalho para o Azure sem alterações no código. Você pega a imagem da VM ou o binário do aplicativo existente e o executa na IaaS do Azure. Essa é a estratégia mais rápida e costuma ser usada para aplicativos legados difíceis de modificar ou por organizações com prazos de migração apertados. O mecanismo de replicação do Azure Migrate automatiza a rehospedagem da maioria das VMs Windows e Linux.

Replataformar (também chamado de Lift, Tinker, and Shift) envolve pequenas otimizações durante a migração, sem alterar a arquitetura principal. Os exemplos incluem mover um banco de dados MySQL autogerenciado de uma VM para o Azure Database for MySQL ou substituir um retransmissor SMTP hospedado localmente pelo Azure Communication Services. Você obtém os benefícios dos serviços gerenciados — aplicação de correções, backups e dimensionamento — sem reescrever a lógica do aplicativo.

Rearquitetar (ou refatorar) significa alterar significativamente a arquitetura do aplicativo para aproveitar os recursos nativos da nuvem. Um aplicativo monolítico em .NET pode ser dividido em microsserviços implantados no Azure Container Apps, ou um sistema de processamento em lote baseado em tarefas cron pode ser reimplementado como Azure Functions. A rearquitetura oferece os maiores benefícios de longo prazo em escalabilidade e custo, mas exige o maior investimento.

Reconstruir significa descartar completamente o aplicativo existente e criar uma nova solução nativa da nuvem. Essa estratégia é escolhida quando o aplicativo legado é muito caro para manter, usa uma pilha tecnológica fora do período de suporte ou simplesmente não consegue atender aos requisitos de negócio, mesmo após a migração. A reconstrução oferece a máxima vantagem nativa da nuvem, mas tem o maior tempo até gerar valor. Serviços PaaS e sem servidor do Azure, como o Azure App Service, o Azure Functions e o Cosmos DB, são destinos comuns.

Substituir significa trocar um aplicativo local existente por um produto SaaS disponível comercialmente que ofereça funcionalidade equivalente ou superior. Por exemplo, substituir um CRM local pelo Dynamics 365 ou um servidor de arquivos legado pelo SharePoint Online. A substituição elimina completamente o gerenciamento da infraestrutura. A contrapartida é uma menor possibilidade de personalização e um esforço potencialmente significativo de migração de dados e gerenciamento de mudanças.

Desativar é a estratégia mais simples: você identifica aplicativos que não são mais usados, que são redundantes ou que foram substituídos e os descomissiona, em vez de migrá-los. Os dados de descoberta coletados pelo Azure Migrate frequentemente revelam que uma porcentagem significativa (às vezes de 20% a 30%) dos servidores locais tem utilização muito baixa ou nenhum usuário ativo. Desativar esses aplicativos reduz o escopo da migração, os custos de licenciamento e a complexidade operacional.

A seleção do R adequado exige a análise de quatro fatores para cada aplicativo: criticidade para o negócio, complexidade técnica, cronograma de migração e custo total de propriedade. Uma interface web simples, sem dependências de integração, é uma boa candidata à rehospedagem. Um aplicativo com centenas de procedimentos armazenados e recursos personalizados de banco de dados pode precisar ser rearquitetado ou reconstruído. Ferramentas internas de baixo valor são candidatas ideais à desativação ou substituição.

O Azure Migrate oferece um recurso de Business Case que sugere automaticamente uma estratégia de migração para os servidores descobertos com base nos dados de utilização, no licenciamento e nos preços do Azure. Ele agrupa as cargas de trabalho nas categorias Rehost, Replatform e End-of-Support, dando a você um ponto de partida para a classificação dos 6 Rs. Você pode substituir qualquer recomendação e adicionar seu próprio contexto de negócio antes de finalizar o plano de migração.

Depois que cada aplicativo recebe um R, você os agrupa em ondas de migração. As candidatas de baixo risco à rehospedagem normalmente formam a primeira onda, para aumentar a confiança da equipe e a familiaridade com as ferramentas. Os projetos de rearquitetura e reconstrução são executados em frentes de trabalho paralelas, com cronogramas mais longos. As dependências entre aplicativos — por exemplo, uma camada web que chama um banco de dados compartilhado — devem ser respeitadas, para que os aplicativos relacionados sejam migrados juntos ou na ordem correta.

Os 6 Rs estão alinhados à fase Adopt do Cloud Adoption Framework da Microsoft. O CAF fornece modelos de planejamento de ondas, matrizes RACI e questionários de avaliação de cargas de trabalho que operacionalizam os 6 Rs em escala empresarial. As proteções de governança estabelecidas durante a fase Ready — zonas de destino, políticas e identidade — devem estar implementadas antes do início das ondas de migração, para que as cargas de trabalho migradas cheguem a um ambiente em conformidade desde o primeiro dia.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que a estrutura dos 6 Rs (Rehost, Replatform, Rearchitect, Rebuild, Replace e Retire) fornece um vocabulário para as decisões de migração, que cada R envolve uma relação diferente entre custo e velocidade e que o Business Case do Azure Migrate pode sugerir estratégias automaticamente com base nos dados de utilização. Em seguida, veremos como o Azure Migrate descobre e avalia servidores locais.