O roteiro de migração para a AWS, do planejamento ao go-live

A AWS define sete estratégias de migração, conhecidas como os "7 Rs". Cada workload do seu portfolio deve ser avaliado individualmente para determinar qual estratégia oferece o melhor equilibrio entre custo, risco e benefício. Na prática, um projeto de migração típico utiliza uma combinação de várias dessas estratégias.

1. Rehost (Lift-and-Shift)

Consiste em mover servidores e aplicações para a AWS sem modificações significativas. É a estratégia mais rápida e de menor risco, ideal para a primeira fase de migração. Ferramentas como o AWS Transform MGN (antigo AWS Application Migration Service) automatizam grande parte do processo, replicando servidores inteiros para a nuvem com downtime mínimo. Rehost é recomendado para aplicações legadas que precisam sair do datacenter rapidamente, com otimização planejada para uma segunda fase.

2. Replatform (Lift-Tinker-and-Shift)

Envolve migrar com pequenas otimizações para aproveitar serviços gerenciados, sem refatorar o código da aplicação. Exemplos clássicos incluem: migrar um banco MySQL on-premises para Amazon RDS (ganhando backups automáticos, réplicas de leitura e Multi-AZ), ou mover uma aplicação de VMs para Amazon ECS com containers. O replatform oferece ganhos rápidos de operação e custo com risco moderado.

3. Refactor / Re-architect

A aplicação e redesenhada para aproveitar recursos nativos da nuvem. É a estratégia com maior potencial de benefícios (escalabilidade, custo, performance), mas também a que exige mais tempo e investimento. Exemplos incluem decompor um monolito em microsserviços com ECS/EKS, adotar arquitetura serverless com Lambda e API Gateway, ou migrar para banco NoSQL com DynamoDB. Reserve o refactor para aplicações estratégicas que justifiquem o investimento.

4. Repurchase (Drop and Shop)

Consiste em substituir a aplicação atual por uma solução SaaS ou produto do AWS Marketplace. Exemplos comuns: trocar um servidor de e-mail Exchange por Amazon WorkMail, substituir um CRM on-premises por Salesforce, ou migrar um ERP legado para uma solução cloud-native. Avalie o TCO em 3 anos é o custo de integração antes de decidir.

5. Retire (Descomissionar)

Identifique aplicações e servidores que não são mais necessários. Em nossa experiência, entre 10% e 20% dos servidores de um datacenter típico podem ser descomissionados durante o assessment de migração. Servidores de testes antigos, aplicações substituidas e ambientes duplicados são candidatos comuns.

6. Retain (Manter)

Algumas aplicações podem não ser candidatas a migração no momento, seja por restrições regulatórias, dependências de hardware específico ou complexidade técnica. A estratégia Retain significa manter o workload on-premises por enquanto, com plano de revisão futura. Aplique-a para mainframes, sistemas com requisitos de latência ultra-baixa ou aplicações próximo ao fim de vida.

7. Relocate (VMware Cloud on AWS)

Para empresas com investimento significativo em VMware, o VMware Cloud on AWS permite mover VMs usando vMotion sem converter o formato. Isso preserva os processos operacionais existentes e permite uma transição gradual. E uma opção especialmente relevante para empresas que precisam evacuar datacenters com prazo apertado.

O planejamento é a fase mais crítica de qualquer projeto de migração. Erros nesta etapa se multiplicam durante a execução, gerando atrasos, custos extras e riscos desnecessários. Um bom assessment cobre três pilares: discovery (inventário), análise de TCO e plano de migração.

Discovery: mapeando seu ambiente atual

O primeiro passo é criar um inventário completo da infraestrutura existente. O AWS Transform faz a descoberta sem agente, coleta inventário e utilização e mapeia dependências de rede; o AWS Application Discovery Service e o AWS Migration Hub estão fechados a novos clientes desde 07/11/2025 (aviso oficial da AWS) e não entram em projeto novo.

Colete dados por pelo menos 2 a 4 semanas. Isso fornece métricas de CPU, memória, disco e rede em condições reais de uso, incluindo picos e períodos de baixa. Os dados ficam no AWS Transform, que monta o mapa de dependências e o plano de ondas; para o business case de custo e licença, use o Migration Evaluator.

Análise de TCO (Total Cost of Ownership)

Uma análise de TCO honesta compara o custo real do datacenter atual com o custo projetado na AWS. Para o cenário on-premises, inclua todos os custos diretos e indiretos: servidores, storage, networking, licenças de software, energia elétrica, refrigeração, espaco físico, seguros, equipe de operações e custo de capital. Muitas empresas subestimam esses custos em 40% a 60%.

Para o cenário AWS, use a AWS Pricing Calculator com os dados do discovery. Considere o uso de Reserved Instances ou Savings Plans para workloads estáveis (economia de até 72%), Spot Instances para cargas tolerantes a interrupção (economia de até 90%) e serviços gerenciados que reduzem o esforco operacional.

Plano de migração: waves e dependências

Divida a migração em waves (ondas), agrupando workloads por dependência, criticidade e complexidade. A primeira wave deve conter aplicações de baixa criticidade e poucas dependências, servindo como piloto para validar processos e ferramentas. Waves subsequentes aumentam gradualmente a complexidade.

Para cada wave, defina: critérios de sucesso (métricas de performance, disponibilidade), plano de rollback, janela de cutover, equipes responsáveis e comunicação. Documente tudo no plano de ondas do AWS Transform para visibilidade centralizada.

Com o planejamento finalizado, é hora de executar. A fase de execução envolve configurar a infraestrutura de destino na AWS (landing zone), preparar as ferramentas de migração, executar as waves e validar cada workload migrado.

Landing zone: a fundação na AWS

Antes de migrar o primeiro servidor, configure uma landing zone segura e bem-arquitetada. Use o AWS Control Tower para criar uma estrutura multi-account com guardrails de segurança e compliance. Uma landing zone típica inclui: conta de gerenciamento (Organizations), conta de log centralizado (CloudTrail, Config), conta de segurança (GuardDuty, Security Hub), conta de rede compartilhada (Transit Gateway, VPN/Direct Connect) e contas de workload separadas por ambiente (dev, staging, prod).

AWS Transform MGN (antigo AWS Application Migration Service)

O AWS Transform MGN é a ferramenta recomendada para rehost de servidores. Ele instala um agente leve no servidor de origem que replica dados continuamente para a AWS. O processo funciona assim:

1. Instale o agente de replicação no servidor de origem
2. O MGN replica o disco inteiro para a AWS em segundo plano (replicação inicial)
3. Após a sincronização inicial, mudanças incrementais são replicadas em tempo quase real
4. Execute testes de launch para validar que o servidor funciona na AWS
5. No dia do cutover, faca o launch final e redirecione o tráfego

A janela de corte depende da validação da aplicação e da troca de DNS, e é medida no teste de corte (dry run) antes da virada. Para servidores Linux e Windows, o MGN lida automaticamente com a conversão de drivers e bootloader.

AWS Database Migration Service (DMS)

Para bancos de dados, o AWS DMS suporta migração homogenea (ex: MySQL para RDS MySQL) e heterogenea (ex: Oracle para PostgreSQL). Em migrações heterogeneas, use o AWS Schema Conversion Tool (SCT) primeiro para converter o schema, stored procedures e funções. O DMS suporta replicação contínua (CDC - Change Data Capture), permitindo manter origem e destino sincronizados até o momento do cutover.

# Criar uma replication instance do DMS
aws dms create-replication-instance \
  --replication-instance-identifier minha-migração \
  --replication-instance-class dms.r5.large \
  --allocated-storage 100 \
  --region sa-east-1

# Verificar status da tarefa de migração
aws dms describe-replication-tasks \
  --filters Name=replication-instance-arn,Values=arn:aws:dms:sa-east-1:123456789012:rep:EXAMPLE

Fases de teste e validação

Cada wave de migração deve passar por três fases de teste:

• Teste funcional: valide que a aplicação funciona corretamente na AWS. Execute os mesmos testes que são usados em releases normais.
• Teste de performance: compare métricas de latência, throughput e tempo de resposta entre o ambiente original é o AWS. Use ferramentas como Apache JMeter ou Locust para carga simulada.
• Teste de cutover (dry run): simule todo o processo de cutover, incluindo mudança de DNS, verificação de conectividade e validação de integridade de dados. Cronometre cada passo para estimar a janela de downtime real.

A migração não termina no go-live. A fase de otimização pós-migração e onde você captura o verdadeiro valor da nuvem. Nos primeiros 90 dias após a migração, concentre-se em três areas: FinOps, observabilidade e segurança.

FinOps: otimização contínua de custos

Logo após a migração, e normal que os custos AWS fiquem acima do estimado. Isso acontece porque servidores migrados via rehost mantêm o mesmo dimensionamento do on-premises. Implemente um ciclo de FinOps com as seguintes ações:

• Rightsizing: use o AWS Compute Optimizer para identificar instâncias superdimensionadas. Após 2 semanas de métricas, ajuste os tipos de instância para o tamanho adequado.
• Savings Plans: para workloads estáveis já validados, adquira Compute Savings Plans com compromisso de 1 ano. Economia média de 30% a 40%.
• Spot Instances: mova workloads tolerantes a interrupção (batch, CI/CD, dev/test) para Spot. Economia de até 90%.
• Tags de custo: implemente uma política rigorosa de cost allocation tags (projeto, equipe, ambiente, centro de custo) para visibilidade granular dos gastos.
• Budget alerts: configure AWS Budgets com alertas em 50%, 80% e 100% do orçamento previsto.

Observabilidade e monitoramento

Migrar para a AWS exige uma mudança na abordagem de monitoramento. Em vez de monitorar apenas infraestrutura, adote observabilidade completa com os três pilares: métricas, logs e traces.

• Amazon CloudWatch: configure dashboards customizados, alarmes para métricas críticas (CPU, memória, disco, latência) e Container Insights para workloads containerizados.
• AWS X-Ray: implemente tracing distribuido para mapear o fluxo de requisições entre microsserviços e identificar gargalos de performance.
• CloudWatch Logs Insights: centralize logs de todas as aplicações e crie queries para detectar erros e anomalias em tempo real.

Security hardening

Após a migração, revise a postura de segurança com base no AWS Well-Architected Framework (pilar de segurança). Ações prioritárias:

• Habilite AWS GuardDuty em todas as contas para detecção de ameaças
• Configure AWS Security Hub com os padroes CIS AWS Foundations Benchmark
• Implemente IAM Access Analyzer para identificar permissões excessivas
• Ative AWS Config Rules para compliance automatizado e detecção de desvios
• Revise Security Groups e NACLs, removendo regras excessivamente permissivas (0.0.0.0/0)
• Habilite criptografia em repouso (KMS) e em trânsito (TLS) para todos os dados sensíveis

Use este checklist como referência durante todo o projeto de migração. Cada item representa uma ação concreta que contribui para o sucesso da iniciativa.

Pre-migração

1. Executar descoberta completa com AWS Transform (sem agente)
2. Classificar cada workload com uma das 7 estratégias de migração (7 Rs)
3. Calcular TCO comparativo (on-premises vs. AWS) incluindo custos indiretos
4. Definir waves de migração com prioridades, dependências e cronograma
5. Configurar landing zone com AWS Control Tower e estrutura multi-account
6. Estabelecer conectividade híbrida (VPN Site-to-Site ou AWS Direct Connect)
7. Definir estratégia de DNS e plano de cutover para cada wave
8. Treinar equipe nas ferramentas de migração (MGN, DMS, SCT)

Durante a migração

1. Instalar agentes de replicação (MGN) e validar sincronização inicial
2. Configurar endpoints de DMS e iniciar replicação de bancos de dados
3. Executar testes funcionais em cada workload migrado
4. Realizar testes de performance comparativos (antes vs. depois)
5. Executar dry run de cutover com cronometragem de cada etapa
6. Documentar e testar plano de rollback para cada wave
7. Comunicar janela de cutover para stakeholders e usuários

Pós-migração

1. Monitorar métricas de performance por 72 horas após cada cutover
2. Executar rightsizing com AWS Compute Optimizer (após 2 semanas de dados)
3. Implementar cost allocation tags em todos os recursos
4. Configurar AWS Budgets e alertas de custo
5. Habilitar GuardDuty, Security Hub e Config em todas as contas
6. Adquirir Savings Plans para workloads estáveis validados
7. Well-Architected Review 90 dias depois do corte
8. Descomissionar infraestrutura on-premises após período de validação