Como Migrar para AWS: Passo a Passo Completo 2026

Migrar para a AWS é o processo de transferir aplicações, dados e infraestrutura de um ambiente on-premises (ou de outro provedor) para a nuvem da Amazon Web Services, utilizando estratégias como lift-and-shift, replatform ou refactoring para minimizar riscos e maximizar os benefícios da nuvem. Este guia passo a passo cobre todas as fases de uma migração bem-sucedida em 2026, desde o planejamento até a otimização pós-migração.

A migração para a nuvem contínua sendo uma prioridade estratégica para empresas brasileiras. Segundo pesquisas de mercado, mais de 70% das empresas de médio porte no Brasil planejam acelerar suas estratégias de cloud até 2027. No entanto, muitas migrações falham por falta de planejamento adequado ou escolha errada de estratégia.

Neste artigo, vamos detalhar cada etapa do processo de migração para a AWS, apresentar as ferramentas nativas disponíveis e compartilhar lições aprendidas de projetos reais.

Os 7 Rs da migração para cloud

A AWS define 7 estratégias de migração, conhecidas como os "7 Rs". A escolha da estratégia certa para cada workload é fundamental para o sucesso do projeto:

• Rehost (Lift-and-Shift): mover a aplicação para a nuvem sem alterações. É a estratégia mais rápida e de menor risco. Ideal para migrações urgentes ou aplicações legadas que funcionam bem como estão. Ferramentas: AWS Application Migration Service (MGN)
• Replatform (Lift-Tinker-and-Shift): fazer ajustes mínimos para aproveitar serviços gerenciados. Exemplo: migrar um banco MySQL on-premises para Amazon RDS, ganhando backups automáticos e alta disponibilidade sem reescrever a aplicação
• Refactor / Re-architect: reescrever a aplicação para ser cloud-native. Oferece o maior benefício a longo prazo (escalabilidade, resiliência), mas exige mais tempo e investimento. Ideal para aplicações estratégicas com longo ciclo de vida
• Repurchase: trocar a aplicação atual por uma solução SaaS. Exemplo: migrar de um CRM on-premises para Salesforce ou de um e-mail server próprio para Microsoft 365
• Retire: descomissionar aplicações que não são mais necessárias. Em média, 10% a 20% dos servidores em um datacenter rodam aplicações obsoletas
• Retain: manter temporariamente on-premises. Aplicações com restrições regulatorias ou técnicas que impedem a migração no momento. Reavaliar em 6 a 12 meses
• Relocate: mover workloads VMware diretamente para VMware Cloud on AWS sem conversão

Fase 1: Assessment e Discovery (Semanas 1 a 3)

O primeiro passo é mapear todo o ambiente atual. Essa fase é crítica e não deve ser apressada, pois erros no inventário geram problemas em todas as fases seguintes.

• Inventário de servidores: liste todos os servidores, suas configurações (CPU, memória, storage), sistemas operacionais e aplicações instaladas
• Mapeamento de dependências: identifique como as aplicações se comunicam entre si e com sistemas externos. O AWS Application Discovery Service automatiza esse processo
• Análise de tráfego: métricas de rede, latência e volume de dados transferidos entre componentes
• Requisitos de compliance: identifique exigências regulatorias (LGPD, PCI DSS, HIPAA) que impactam a arquitetura de destino
• Análise de custos: calcule o TCO (Total Cost of Ownership) atual e o custo estimado na AWS usando o AWS Pricing Calculator

"O assessment é a fase mais importante da migração. Cada hora investida em discovery economiza dias de retrabalho nas fases seguintes."

Fase 2: Planejamento e Design (Semanas 3 a 6)

Com o inventário completo, é hora de definir a estratégia de migração para cada workload e desenhar a arquitetura de destino na AWS:

• Classificação dos workloads: aplique os 7 Rs para cada aplicação. Priorize pelo impacto no negócio e pela complexidade técnica
• Design da rede: projete a VPC (Virtual Private Cloud) com subnets públicas e privadas, security groups, NACLs e conexão com o ambiente on-premises via VPN ou AWS Direct Connect
• Estratégia de segurança: defina IAM policies, criptografia (KMS), logs de auditoria (CloudTrail) e monitoramento (GuardDuty)
• Plano de disaster recovery: defina RPO e RTO para cada workload e projete a estratégia de DR adequada
• Cronograma de ondas: divida a migração em ondas (waves). Comece com workloads de menor criticidade para ganhar experiência antes de migrar sistemas críticos

Fase 3: Preparação do ambiente AWS (Semanas 4 a 7)

Antes de iniciar a migração dos workloads, o ambiente de destino precisa estar pronto e validado:

• Landing Zone: configure a estrutura de contas AWS usando AWS Organizations e AWS Control Tower. Separe contas para produção, staging, desenvolvimento e segurança
• Rede: crie VPCs, subnets, route tables, NAT Gateways e estabeleca a conectividade com o datacenter via VPN Site-to-Site ou Direct Connect
• Segurança: configure AWS IAM Identity Center (SSO), habilite CloudTrail, Config, GuardDuty e Security Hub
• Monitoramento: configure CloudWatch dashboards, alarmes e SNS topics para notificações
• Infrastructure as Code: use Terraform ou CloudFormation para provisionar tudo de forma reproduzível e auditável

Fase 4: Migração dos workloads (Semanas 6 a 14)

Com o ambiente preparado, inicie a migração dos workloads em ondas, começando pelos menos críticos:

Para servidores (Rehost/Replatform):

• AWS Application Migration Service (MGN): instale o agente de replicação nos servidores de origem. O MGN faz replicação contínua de blocos de disco para a AWS, permitindo testes e cutover com downtime mínimo (tipicamente menos de 1 hora)
• Testes pré-cutover: lance instâncias de teste a partir dos dados replicados e valide que a aplicação funciona corretamente na AWS
• Cutover: no dia da virada, pare a aplicação no servidor de origem, espere a última replicação sincronizar, lance a instância definitiva na AWS e atualize os DNS

Para bancos de dados:

• AWS Database Migration Service (DMS): suporta migração de bancos Oracle, SQL Server, MySQL, PostgreSQL e MongoDB. Permite full load + CDC (Change Data Capture) para replicação contínua com near-zero downtime
• AWS Schema Conversion Tool (SCT): converte schemas entre engines diferentes (exemplo: Oracle para PostgreSQL)
• Validação de dados: compare checksums e contagens de registros entre origem e destino para garantir integridade

Para storage:

• AWS DataSync: transfere dados de NFS/SMB para S3 ou EFS com até 10x mais velocidade que ferramentas de cópia tradicionais
• AWS Snow Family: para volumes muito grandes (dezenas de TB), use Snowball Edge para transferência offline

Fase 5: Validação e otimização (Semanas 12 a 16)

Após a migração, valide tudo e otimize o ambiente para performance e custo:

• Testes funcionais: valide todas as funcionalidades das aplicações migradas
• Testes de performance: compare métricas de latência, throughput e tempo de resposta com o baseline do ambiente anterior
• Rightsizing: análise as métricas reais de uso é ajuste os tipos de instância (o AWS Compute Optimizer ajuda nessa análise)
• Reservas: após 2 a 4 semanas de operação estável, compre Reserved Instances ou Savings Plans para workloads previsíveis
• Descomissionamento: desligue os servidores de origem somente após confirmar que tudo funciona na AWS por pelo menos 2 semanas

Erros comuns na migração para AWS

Na nossa experiência conduzindo projetos de migração, estes são os erros mais frequentes:

• Pular o assessment: migrar sem inventário completo gera surpresas desagradáveis (dependências desconhecidas, licenças não previstas, dados não mapeados)
• Migrar tudo de uma vez: a abordagem big-bang aumenta o risco exponencialmente. Migre em ondas, validando cada etapa
• Ignorar a segurança: security groups abertos (0.0.0.0/0), credenciais hardcoded no código e falta de criptografia são falhas comuns em ambientes recém-migrados
• Não treinar a equipe: a equipe de operações precisa ser capacitada para operar na AWS antes da migração, não depois
• Não planejar custos: sem AWS Budgets e tagging desde o primeiro dia, os custos podem sair do controle rapidamente
• Usar tamanhos de instância iguais ao on-premises: a nuvem permite elasticidade. Comece menor e escale conforme a demanda real

Timeline típica de migração

Para um ambiente de 10 a 30 servidores com bancos de dados e storage:

• Semanas 1 a 3: Assessment e discovery
• Semanas 3 a 6: Planejamento e design da arquitetura
• Semanas 4 a 7: Preparação do ambiente AWS (em paralelo com planejamento)
• Semanas 6 a 14: Migração em ondas (3 a 5 ondas)
• Semanas 12 a 16: Validação, otimização e descomissionamento

Total: 12 a 16 semanas para uma migração de médio porte com abordagem estruturada.

Comandos essenciais para migração

Estes comandos e configurações são fundamentais durante cada fase da migração para AWS.

Assessment com AWS Application Discovery Service

# Instalar o agente de discovery em servidores on-premises (Linux)
curl -o aws-discovery-agent.tar.gz \
  https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz
tar -xzf aws-discovery-agent.tar.gz
sudo bash install -r sa-east-1 -k ACCESS_KEY -s SECRET_KEY

# Listar servidores descobertos
aws discovery describe-servers \
  --query 'servers[*].[serverId,hostName,osName,cpuType,totalCpuCores,totalRamInMB]' \
  --output table

# Exportar dados de discovery para análise
aws discovery start-export-task --export-data-format CSV
aws discovery describe-export-tasks --output table

Migração com AWS MGN (Application Migration Service)

# Inicializar o MGN na região destino
aws mgn initialize-service --region sa-east-1

# Listar servidores de origem em replicação
aws mgn describe-source-servers \
  --query 'items[*].[sourceServerID,sourceProperties.identificationHints.hostname,lifeCycle.state,dataReplicationInfo.lagDuration]' \
  --output table --region sa-east-1

# Verificar status de replicação detalhado
aws mgn describe-source-servers \
  --filters '{"sourceServerIDs":["s-1234567890abcdef0"]}' \
  --query 'items[0].dataReplicationInfo' \
  --region sa-east-1

# Iniciar teste de migração (sem afetar produção)
aws mgn start-test --source-server-ids "s-1234567890abcdef0" --region sa-east-1

# Executar cutover final
aws mgn start-cutover --source-server-ids "s-1234567890abcdef0" --region sa-east-1

Migração de banco de dados com DMS

# Criar instância de replicação DMS
aws dms create-replication-instance \
  --replication-instance-identifier migracao-prod \
  --replication-instance-class dms.r5.large \
  --allocated-storage 100 \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --availability-zone sa-east-1a \
  --no-multi-az

# Testar conexão com o endpoint de origem
aws dms test-connection \
  --replication-instance-arn arn:aws:dms:sa-east-1:123456789012:rep:ABCDEF \
  --endpoint-arn arn:aws:dms:sa-east-1:123456789012:endpoint:SOURCE123

# Monitorar progresso da tarefa de migração
aws dms describe-table-statistics \
  --replication-task-arn arn:aws:dms:sa-east-1:123456789012:task:TASK123 \
  --query 'TableStatistics[*].[SchemaName,TableName,FullLoadRows,Inserts,Deletes,Updates,TableState]' \
  --output table

Gotchas da migração

• Banda de upload é o gargalo: para 10 TB de dados, um link de 100 Mbps leva aproximadamente 10 dias. Para volumes acima de 5 TB, considere AWS Snowball ou DataSync com Direct Connect. Calcule: (dados em GB * 8) / (banda em Gbps * 3600) = horas.
• Licenças de software mudam na cloud: licenças de Windows Server, SQL Server e Oracle têm regras diferentes na AWS. O modelo BYOL (Bring Your Own License) exige hosts dedicados para SQL Server Enterprise. Verifique com o fornecedor antes de migrar.
• MGN tem requisitos de rede específicos: o agente de replicação precisa de conectividade TCP 443 e TCP 1500 para os endpoints do MGN. Firewalls corporativos frequentemente bloqueiam a porta 1500. Teste a conectividade antes de começar.
• DMS não migra stored procedures e triggers: o DMS migra dados, não schema objects. Use AWS SCT (Schema Conversion Tool) primeiro para converter procedures, triggers, views e functions. Teste extensivamente em staging.
• Rollback precisa ser planejado antes do cutover: defina critérios claros de go/no-go e mantenha o ambiente on-premises funcional por pelo menos 2 semanas após o cutover. Replique dados de volta se necessário.

Na Prática: indústria migrando ERP e banco Oracle

Próximos passos

A migração para a AWS é um projeto transformador que, quando bem executado, traz ganhos significativos em agilidade, segurança e redução de custos. O mais importante é investir tempo no planejamento e contar com profissionais experientes para guiar o processo.

Na RFX Tecnologia, oferecemos consultoria especializada em migração AWS e já conduzimos dezenas de projetos para empresas brasileiras de todos os portes. Nosso time acompanha cada fase da migração, do assessment ao pós-go-live, garantindo uma transição segura e sem surpresas.

Se você está planejando migrar para a AWS, entre em contato conosco ou agende uma reunião gratuita. Consulte também nosso guia detalhado de migração AWS para informações adicionais.