Migração para AWS

Estratégias de migração para a AWS: os 7 Rs e como escolher

Por Audizio Nunes · 8 de outubro de 2026

As estratégias de migração para a AWS são os caminhos que a documentação oficial descreve para levar cada aplicação à nuvem, de mover sem alterar nada até redesenhar a arquitetura. Esta página apresenta os sete Rs, quando cada um costuma ser escolhido e como decidir aplicação por aplicação.

Quais são as estratégias de migração para a AWS (os 7 Rs)

O guia de grandes migrações do AWS Prescriptive Guidance define estratégia de migração como a abordagem usada para migrar uma carga de trabalho para a AWS e lista sete, conhecidas como 7 Rs: retire, retain, rehost, relocate, repurchase, replatform e refactor ou re-architect. Outros materiais da AWS falam em seis, sem o relocate. A página é a versão atual do guia (About the migration strategies), lida em 8 de outubro de 2026.

Os nomes ficam em inglês porque a versão em português da página é tradução automática e usa termos diferentes para o mesmo R.

Rehost: mover a aplicação sem alterá-la

Rehost, também chamado de lift and shift, move a aplicação do ambiente de origem para a AWS sem mudar a aplicação. O tempo de indisponibilidade depende da estratégia de virada.

O guia da AWS para cargas Microsoft diz que o rehost costuma ser mais rápido e simples, porque não exige mudança de código ou de arquitetura, e que minimiza risco e interrupção para o negócio. O mesmo guia faz a ressalva: o rehost não aproveita plenamente os benefícios da nuvem, e um problema de plataforma existente continua depois da migração.

Um exemplo: um sistema .NET Framework em IIS numa VPS que passa a rodar numa instância Windows na AWS se enquadra no rehost quando não há mudança no código, o que depende das dependências do sistema. Ver como migrar de VPS para AWS.

Replatform: otimizar na migração sem redesenhar

Replatform, ou lift, tinker, and shift, move a aplicação e introduz algum nível de otimização para operar com mais eficiência, reduzir custo ou usar recursos da nuvem. Podem ser poucas ou muitas mudanças.

Entre os usos citados: levar um Microsoft SQL Server para o Amazon RDS for SQL Server, atualizar o sistema operacional, trocar Windows por Linux portando aplicações .NET Framework para o .NET moderno (a página usa o nome .NET Core) e colocar máquinas virtuais em contêineres. O guia da AWS para cargas Microsoft diz que o replatform costuma ter melhor custo-benefício que o rehost e reduz a carga operacional da equipe de operações, mas leva mais tempo e exige habilidades adicionais.

Refactor ou re-architect: quando a arquitetura muda

Refactor muda a arquitetura da aplicação para usar recursos nativos da nuvem, em busca de agilidade, desempenho e escalabilidade. Entre os casos citados estão um monólito que já atrapalha a entrega e uma aplicação que ninguém sabe manter ou sem código-fonte disponível.

A mesma página chama o refactor de a estratégia mais complexa e cara, porque a modernização acontece durante a migração, e recomenda usá-la em grandes migrações apenas quando as outras não forem aceitáveis. Outro guia da AWS, sobre cargas Microsoft, diz que o refactor costuma ser a abordagem de melhor custo-benefício, mas exige habilidades avançadas de código e automação e leva mais tempo. Os dois guias têm focos diferentes: grandes migrações de portfólio e modernização de cargas Microsoft.

Retire, retain, relocate e repurchase

• Retire: desativar ou arquivar a aplicação. A página cita falta de valor de negócio, sistema operacional sem suporte e aplicações ociosas, identificadas por dados de utilização.
• Retain: manter no ambiente de origem ou adiar. Motivos citados: residência de dados, alto risco, dependências que precisam migrar antes e hardware sem equivalente na nuvem.
• Relocate: transferir servidores para a versão em nuvem da mesma plataforma, ou mover instâncias ou objetos para outra VPC, Região ou conta da AWS, sem comprar hardware, reescrever a aplicação ou mudar a operação.
• Repurchase: substituir a aplicação por outra versão ou produto, como a troca de licença tradicional por SaaS.

Como escolher a estratégia de cada aplicação

A escolha parte dos objetivos de negócio e de TI. A AWS cita como motivadores comuns reduzir custo, reduzir risco, melhorar a eficiência, cobrir lacunas de habilidade e acelerar a inovação. No planejamento de portfólio, cada aplicação é classificada nos sete Rs e o resultado é cruzado com interdependências e complexidade técnica. O resultado esperado é uma estratégia definida para cada aplicação.

Perguntas úteis, derivadas dos critérios da documentação:

• Qual objetivo pesa mais?
• De que outras aplicações e componentes ela depende?
• Qual a criticidade, o ciclo de vida e o ciclo de negócio da aplicação?
• Quanta mudança o time tem habilidade para fazer e operar?
• Há exigência de conformidade ou de residência de dados?
• A aplicação ainda tem uso que justifique migrar?

O efeito de cada escolha na conta mensal está em quanto custa migrar para AWS, e as particularidades de .NET em migrar aplicação .NET para AWS.

Migrar agora e modernizar se fizer sentido: a posição do autor

Na minha abordagem, o princípio é migrar agora e modernizar se fizer sentido, evitando mudar infraestrutura e código ao mesmo tempo sem necessidade. Em termos dos Rs, isso significa começar por rehost ou por um replatform pontual e deixar o refactor para quando houver um motivo claro.

Há apoio parcial na documentação: para grandes migrações, a AWS recomenda rehost, relocate ou replatform e modernizar depois da migração, e diz que as aplicações ficam mais fáceis de otimizar quando já rodam na nuvem. Essa recomendação vale para grandes migrações; estendê-la a uma aplicação isolada é a minha escolha, não uma regra. Veja o serviço de migração para a AWS.

Quando a estratégia muda no meio do projeto e o que esta página não resolve

A documentação descreve o plano por aplicação como iterativo: ele amadurece conforme a migração avança. Como prática de planejamento, e não regra da AWS, vale registrar por que cada estratégia foi escolhida e que fato a faria mudar, como uma dependência não mapeada, uma licença ou um teste que falha. Assim, a mudança vira revisão de plano e de custo.

Esta página não escolhe a estratégia da sua aplicação, não cobre a execução (ferramentas, virada, reversão) e se apoia em guias pensados para portfólios, que podem ir além do que um sistema isolado precisa. Também não diz que migrar é sempre a melhor resposta: retain e retire são estratégias válidas. Para o caso de servidor local, veja migrar on-premises para AWS.