Migração para AWS

Como migrar do on-premises para a AWS

Por Audizio Nunes · 8 de outubro de 2026

Migrar do on-premises para a AWS é levar aplicações e servidores que hoje rodam em servidor local, datacenter próprio ou ambiente virtualizado para a nuvem da AWS. O caminho pode ser copiar o servidor como está, ajustá-lo na chegada ou reescrever parte do sistema.

O que significa migrar do on-premises para a AWS

On-premises é a infraestrutura que a empresa mantém por conta própria, da sala de servidores ao datacenter. A AWS descreve sete estratégias, entre elas rehost (mover sem alterar), replatform (mover com alguma otimização), refactor (rearquitetar para a nuvem), retain (manter) e retire (desativar), no guia de migração de cargas Microsoft.

Em migrações grandes, a AWS organiza o trabalho em avaliar, mobilizar e migrar e modernizar, e recomenda migrar primeiro e modernizar depois.

Antes de começar: o levantamento do ambiente

Registre, para cada servidor:

• sistema operacional e versão, discos e tamanho dos volumes;
• aplicações, serviços e tarefas agendadas, e bancos de dados com tamanho e acessos;
• integrações, certificados, domínio (Active Directory) e conexões entre servidores.

A ferramenta de descoberta do AWS Transform lê servidores de VMware vCenter e de hosts Microsoft Hyper-V, ou de uma lista importada por planilha CSV, e mostra a coleta de servidores, bancos e conexões. Guias antigos citam o AWS Application Discovery Service e o AWS Migration Hub, que a AWS informa não aceitarem mais novos clientes.

Replicar, ajustar ou reescrever: como escolher o método

Segundo a AWS, rehost costuma ser mais rápido e simples porque não exige mudança de código, mas leva junto os problemas que o ambiente já tem. Replatform aproveita melhor a nuvem, por exemplo trocando o banco por um serviço gerenciado, e demora mais. Refactor exige mais habilidade de desenvolvimento e mais tempo.

Se o sistema é .NET, veja levar uma aplicação .NET para a AWS. Se o servidor é uma VPS contratada, leia migrar de VPS para AWS.

Como a replicação e o teste funcionam com o AWS Transform MGN

O AWS Application Migration Service, nome que ainda aparece em guias, foi renomeado para AWS Transform MGN. Ele migra servidores físicos, virtuais e de outras nuvens. O fluxo documentado é:

1. Instala-se o agente de replicação no servidor de origem. A cópia inicial começa sozinha.
2. Os dados são replicados de forma contínua, em nível de bloco, compactados e criptografados, para uma sub-rede de preparação na AWS.
3. Com a cópia concluída e a replicação saudável, o servidor fica pronto para teste e se lança uma instância de teste.
4. Depois de validar, marca-se o servidor como pronto para o corte e lança-se a instância de corte.

A AWS recomenda testar pelo menos duas semanas antes da virada. Instâncias de teste são cobradas; encerre as que não usar.

O MGN aceita só arquitetura x86 e volumes de até 16 TB, e não aceita servidores totalmente paravirtualizados. Sistemas operacionais antigos podem sair da lista de suporte do MGN; confira a lista vigente antes de planejar.

Conectividade e segurança durante a migração

• A replicação pode usar a internet, uma VPN ou o AWS Direct Connect.
• Cada servidor de origem precisa alcançar a API do MGN na porta 443 (a documentação lista os endpoints a liberar no firewall) e os servidores de replicação na porta 1500. Não aplique inspeção SSL nessa comunicação.
• A comunicação usa TLS, e há opção de criptografar os volumes de preparação.
• Para instalar o agente, use credenciais temporárias do IAM, não de usuário permanente (no exemplo da AWS, expiram em uma hora).
• Com Active Directory, a rede de destino precisa alcançar os controladores de domínio; ao testar um controlador, isole a rede de teste da produção.

Como migrar o banco de dados do servidor local

Replicar o servidor inteiro com o MGN leva o banco para uma instância do Amazon EC2, mantendo versão do banco, sistema e código, e a AWS cita SQL Server e Oracle entre as aplicações suportadas. Outro caminho é migrar só o banco com o AWS Database Migration Service (DMS), que faz carga completa, carga completa com captura contínua de mudanças, ou só a captura. A AWS avisa que essa replicação não é em tempo real e não tem garantia (SLA) de latência.

Para SQL Server em Amazon RDS, a AWS cita o backup e restore nativo como método mais usado quando a parada é aceitável, e backups diferenciais e de log para reduzi-la. Detalhes em migrar SQL Server para Amazon RDS. A orientação oficial é ter um plano de reversão antes de migrar o banco.

O dia da virada e como voltar atrás

Não desligue nem reinicie o servidor de origem até o corte terminar. No MGN, a instância de corte nasce do estado mais recente do servidor; depois dela, o que for gravado na origem não chega à instância já lançada.

O plano de reversão é prática de planejamento. Defina antes quem decide, o critério que dispara a volta, como o tráfego retorna ao ambiente antigo e o que fazer com os dados gravados na AWS nesse intervalo.

No console do MGN, a opção de reverter o corte volta o servidor ao estado de pronto para o corte, para você lançar novas instâncias de corte. Ela não devolve tráfego nem dados ao ambiente antigo: o retorno para a origem é parte do seu plano, não do MGN. Finalizar o corte encerra a replicação e descarta os dados replicados na área de preparação; a instância de corte continua. Depois disso você não tem mais essa cópia contínua da origem, então só finalize depois de validar.

Antes de finalizar, ative a proteção contra encerramento da instância. Depois, acompanhe erros e desempenho e mantenha o ambiente antigo pelo período combinado. No RDS, se Multi-AZ e retenção de backup foram desligados durante a carga, reative-os. O efeito na conta está em quanto custa migrar para a AWS.

Quando migrar do on-premises não é o indicado agora

• Aplicação sem justificativa de negócio para migrar, ou que exige reescrita que você quer adiar. A AWS chama isso de retain (manter onde está); quando a aplicação já não é necessária, retire (desativar).
• Sistema operacional fora da lista do MGN, hardware que não seja x86 ou volumes acima do limite ficam fora do MGN; para sistema em fim de vida a AWS recomenda atualizar, e há a opção de instalar a aplicação do zero.

Esta página não calcula custo, não trata de licenças e não substitui o levantamento do seu ambiente. Se quiser ajuda com esse diagnóstico, veja o serviço de migração para a AWS.