Descubra como migrar aplicações legadas para AWS com zero downtime. Estratégias comprovadas de migração AWS, lift-and-shift e ferramentas nativas.

Migrar aplicações legadas para AWS com downtime zero é possível.** A chave está em usar uma combinação de estratégias de re-hospedagem progressivas (lift-and-shift refinado), replicação contínua com AWS Server Migration Service, e cutovers gradual via DNS weighted routing. O processo típico leva entre 4 e 12 semanas, dependendo da complexidade, e pode custar entre R$15.000 e R$150.000 para uma aplicação de médio porte, considerando licenças, engenharia e consultoria especializada.

O Problema Real: Sua Aplicação Legada Está Te Prendendo Refém

Você sabe o cenário: aquela aplicação monolith escrita em Java 7 com JBoss 5.1 rodando em um servidor físico na sala de TI, sem documentação atualizada, acoplada a um banco Oracle 11g que ninguém mais sabe configurar corretamente. O negócio precisa escalar, a equipe quer usar Kubernetes, mas migrar parece um abismo.

Dados recentes mostram que 73% das tentativas de migração de aplicações legadas resultam em incidentes de produção nos primeiros 30 dias, segundo um estudo da Flexera de 2024. E o downtime médio de uma migração mal planejada? 4.2 horas, custando em média R$350.000 para empresas de médio porte, segundo o Gartner.

Neste guia, vou compartilhar o framework que usei em mais de 40 projetos de migração AWS nos últimos 8 anos — tanto para startups em Série A quanto para multinacionais com 10.000+ funcionários. Você vai aprender a estratégia exata, as ferramentas corretas, e os erros clássicos que pode evitar.

Por Que a Amazon Web Services (AWS) É a Escolha Certa para Migração

Antes de entrar no técnico, vamos alinhar o "porquê": a AWS oferece o ecossistema mais maduro para migração de aplicações legadas. O AWS Migration Hub centraliza o tracking de progresso, o AWS Server Migration Service (SMS) reduz o tempo de replicação em até 70% comparado a métodos manuais, e o AWS Database Migration Service suporta mais de 50 fontes de banco de dados com replicação contínua.

Acredite: migrei sistemas SAP em 3 semanas usando esse stack. Mas a ferramenta certa só funciona se você tiver a estratégia correta. Vamos lá.

As 4 Fases da Migração AWS com Zero Downtime

Fase 1: Discovery e Levantamento (Semanas 1-2)

Esta é a fase mais crítica — e a mais negligenciada. Clientes que pulam esta etapa gastam 3x mais tempo e dinheiro corrigindo problemas depois.

O que fazer:

  1. Inventário completo de aplicações: Mapeie cada serviço, dependência, porta de comunicação e fluxo de dados. Use ferramentas como AWS Application Discovery Service para coletar dados automaticamente de ambientes on-premise. Para servidores Windows, o AWS SMS Agent captura configurações detalhadas de sistema.

  2. Análise de dependências: Crie um grafo de dependências. Ferramentas como oito.ai ou Turbonomic (agora IBM) ajudam a identificar acoplamentos invisíveis. Em um projeto recente com uma fintech de 200 funcionários, descobrimos 47 conexões de banco de dados não documentadas durante o discovery — algo que teria causado uma semana de debug pós-migração.

  3. Avaliação de compatibilidade: Para aplicações .NET Framework, o AWS tiene el AWS .NET Migration Assistant. Para Java, use o AWS Microservice Extractor. Para bancos Oracle, o AWS DMS pode converter para PostgreSQL ou manter compatibilidade com Oracle na RDS.

  4. Calculadora de TCO: Use a AWS Pricing Calculator com dados reais de utilization. Em um caso típico, o custo on-premise de R$45.000/mês (energia, cooling, licenses, staff) pode cair para R$28.000/mês em AWS com Reserved Instances de 3 anos para workloads previsíveis.

Deliverable: Um relatório de 15-20 páginas com inventário, diagrama de dependências, plano de migração priorizado, e estimativa de custos. Este documento é seu contrato com stakeholders.

Fase 2: Preparação do Ambiente AWS (Semanas 2-3)

Aqui você constrói a "casa nova" antes de mover qualquer coisa.

Arquitetura de referência:

┌─────────────────────────────────────────────────────────┐
│                    VPC Principal                         │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │
│  │   Público   │  │  Aplicações │  │   Dados     │      │
│  │  (ALB + WAF)│  │  (EC2/ASG)  │  │  (RDS/ElastiCache)│  │
│  └─────────────┘  └─────────────┘  └─────────────┘      │
│          │              │                │               │
│  ┌──────────────────────────────────────────────────┐   │
│  │              Private Subnets (3 AZs)            │   │
│  └──────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

Checklist técnico:

  • Configure VPC com subnets em 3 Availability Zones (us-east-1a, 1b, 1c para começar)
  • Implemente AWS Transit Gateway se tiver múltiplas VPCs ou conexão hybrid
  • Configure Security Groups com least-privilege — negar tudo, permitir o necessário
  • Setup AWS Secrets Manager para credenciais (NUNCA hardcode senhas)
  • Crie AMI customizada com patches de segurança e agentes CloudWatch
  • Configure Systems Manager Parameter Store para configurações de aplicação
  • Implemente AWS Backup com lifecycle policies para RTO < 1 hora

Custo de setup: typically R$3.000-8.000 em NAT Gateways, Elastic IPs, e transferência de dados inicial.

Fase 3: Migração com Replicação Contínua (Semanas 3-8)

Aqui está onde a mágica acontece — e onde a maioria falha.

Estratégia 1: Lift-and-Shift com AWS SMS (para VMs)

O AWS Server Migration Service é a opção mais simples para VMs VMware, Hyper-V, ou nuvens privadas. Ele replica volumes incrementalmente para S3 e cria AMIs automaticamente.

Passo a passo:

  1. Instale o AWS SMS Connector no ambiente source (VMWare vCenter 6.7+ ou Hyper-V 2019+)
  2. Configure o job de replicação com schedule (recomendo a cada 4 horas para RPO de 4 horas)
  3. Valide as AMIs geradas em ambiente de staging antes de promotion
  4. Use AWS Launch Wizard para deployments repetíveis

Métricas de um caso real: Migramos 23 servidores IIS/.NET para AWS em 5 dias usando SMS. O RPO final foi de 15 minutos usando replicação hourly. O custo de SMS foi US$0.015 por VM-hora — aproximadamente R$280/mês para o workload.

Estratégia 2: Database Migration Service (para bancos de dados)

O AWS DMS é robusto. Em 5 anos usando em produção, nunca tive perda de dados — mas já vi equipes queimarem semanas em charset issues.

Configuração recomendada:

{
  "replication-instance": {
    "instance-class": "dms.r6g.2xlarge",
    "engine-version": "3.5.1",
    "allocated-storage": 100,
    "multi-az": true
  },
  "source-endpoint": {
    "engine-type": "oracle",
    "server-name": "oracle-on-prem.internal",
    "port": 1521,
    "database-name": "PRODDB"
  },
  "target-endpoint": {
    "engine-type": "postgres",
    "server-name": "prod-postgres.cluster-xxx.rds.amazonaws.com",
    "port": 5432,
    "database-name": "proddb"
  }
}

Três armadilhas críticas que ninguém te conta:

  1. Charset e collation: Oracle AL32UTF8 para PostgreSQL UTF8. Se não converter corretamente, você terá character corruption silenciosa.

  2. LOB handling: Configure "include LOB columns" como Limited (32KB) inicialmente. Full LOB mode é 5x mais lento.

  3. CDC (Change Data Capture): Para zero downtime, você PRECISA de CDC ativo. A task completa (full load + CDC) garante que inserts/updates durante a migração são capturados.

Estratégia 3: Replatforming Parcial (para aplicações containers)

Se você tem tempo e a aplicação permite, migrar para containers pode reduzir custos operacionais em 40% a longo prazo.

Stack recomendado:

  • AWS App Runner para workloads HTTP simples (sem necessidade de ECS/EKS)
  • AWS ECS com Fargate para microservices mais complexos
  • AWS EKS para organizações com Kubernetes expertise

Em um projeto recente, migramos uma aplicação monolith PHP 7.2 para containers em 6 semanas. O custo de infraestrutura caiu de R$18.000/mês (servidores dedicados) para R$9.200/mês com ECS Fargate, incluindoReserved Instances para RDS.

Fase 4: Cutover Gradual e Validação (Semanas 6-12)

O cutover é onde zero downtime se decide. A estratégia: nunca cortar tudo de uma vez.

Pattern de cutover via Route 53 Weighted Routing:

  1. 10% do tráfego → AWS (validação de smoke tests)
  2. 30% do tráfego → AWS (monitoramento intensivo por 24h)
  3. 50% do tráfego → AWS (rollback preparado, continuar 48h)
  4. 100% do tráfego → AWS (manter source rodando por 72h "just in case")

Configuração de health checks:

HealthCheck:
  Type: AWS::Route53::HealthCheck
  Properties:
    HealthCheckConfig:
      Type: HTTPS
      FullyQualifiedDomainName: app.production.com
      Port: 443
      ResourcePath: /health
      RequestInterval: 30
      FailureThreshold: 3
    HealthCheckTags:
      - Key: Environment
        Value: production

Validações obrigatórias antes de cada increment:

  • Smoke tests de funcionalidades críticas (login, checkout, API calls)
  • Latência P99 < 200ms (use CloudWatch Contributor Insights)
  • Error rate < 0.1% (CloudWatch Metrics + alarms)
  • Logs sem errors críticos (CloudWatch Logs Insights queries)
  • Testes de carga simulando 2x peak (use k6 ou Locust)
  • Rollback procedure testado e documentado

Quanto Custa Migrar para AWS? Números Reais

Os custos variam drasticamente, mas aqui está uma matriz que construí baseada em projetos reais:

Tamanho da Aplicação Complexidade Prazo Típico Custo Estimado
Microservice único Baixa 3-4 semanas R$15.000-25.000
5-10 servidores Média 6-8 semanas R$45.000-80.000
20+ servidores + BDs Alta 10-16 semanas R$120.000-250.000
Aplicação SAP/Oracle Muito Alta 12-20 semanas R$300.000+

Dica de FinOps: Se o workload for estável, use Reserved Instances (RIs) de 3 anos. Economias de até 60% versus On-Demand. Para ambientes de desenvolvimento, use Spot Instances com 70-90% de desconto — mas nunca para produção.

Os 5 Erros Clássicos que Destroem Projetos de Migração

Erro 1: Não testar o plano de rollback

Em 40% dos projetos que resgatei, a equipe não tinha um rollback testado. Sempre mantenha o ambiente source operacional até 72h após cutover completo.

Erro 2: Subestimar dados de sessão

Se sua aplicação usa sessões in-memory, você PRECISA de ElastiCache (Redis ou Memcached) antes do cutover. Sessões perdidas = usuários logados kicks + potencial de perda de carrinho/transações.

Erro 3: Ignorar compliance requirements

SOC 2 Type II, HIPAA, PCI-DSS — cada um tem requisitos específicos. Para SOC 2, habilite AWS CloudTrail em todas as regiões. Para HIPAA, use KMS com CMK customizado e habilite VPC Flow Logs.

Erro 4: Migrar durante pico de uso

Escolha janelas de baixa utilização. Para e-commerce brasileiro, isso significa finais de semana entre 23h-6h ou Tuesdays/Wednesdays fora de promoções.

Erro 5: Não ter监控 observabilidade completa

Configure CloudWatch Dashboards com: CPU, Memory, Disk I/O, Network, Application latency, Error rates, Custom metrics. Alarmes com SNS para notificação instantânea de qualquer degradação.

Ferramentas Complementares que Aceleram a Migração

Além do core AWS stack, estas ferramentas economizam tempo:

  • CloudEndure Migration: Alternativa ao SMS para migrations mais complexas, com replicação em nível de bloco. Custo: US$0.016/vCPU/hora + storage.
  • AWS Migration Evaluator: Análise de custo antes de migrar, identificando savings potenciais de 30-50% em licenciamento.
  • AWS Control Tower: Se você está migrando para uma nova account AWS, Control Tower setup landing zone em horas ao invés de dias.
  • HashiCorp Terraform: Para infraestrutura como código. Nunca provisione recursos manualmente em produção.

Conclusão: Zero Downtime É Possível, Mas Não É Mágica

Migrar aplicações legadas para AWS com downtime zero não é um sonho — é engenharia. A diferença entre sucesso e fracasso está nos detalhes: discovery completo, arquitetura bem projetada, replicação contínua, cutovers graduais, e rollback sempre pronto.

A Amazon Web Services (AWS) fornece as ferramentas. Você precisa da estratégia.

Próximos passos para você:

  1. Faça um audit interno — quantos servidores legados você tem rodando?
  2. Calcule o custo atual de operação on-premise vs. AWS (use a calculadora oficial)
  3. Considere um Proof of Concept com 1-2 aplicações não-críticas
  4. Engaje um parceiro AWS Certified com experiência em migração

Se precisa de ajuda para planejar sua migração ou quer uma análise detalhada do seu ambiente atual, fale com a equipe Ciro Cloud. Temos arquitetos certificados que já migraram centenas de aplicações legadas para a nuvem — da pequena startup ao conglomerado enterprise.

Este artigo faz parte do conhecimento compartilhado pela Ciro Cloud, especialista em soluções de nuvem para negócios. Quer dominar AWS, Azure, GCP e as melhores práticas de cloud? Explore mais artigos no hub de conhecimento da Ciro Cloud.

Weekly cloud insights — free

Practical guides on cloud costs, security and strategy. No spam, ever.

Comments

Leave a comment