Migration strategy: os 7 Rs + DMS + SMS
- ⬜🌐 Advanced networking: RAM, Cloud WAN, Transit Gateway(AWS Solutions Architect Professional (SAP-C03))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Os 7 Rs em ordem crescente de esforço
Retire: Desliga — sistema obsoleto, ninguém usa. Economia imediata.
Retain: Mantém on-prem por ora (compliance, latency, contrato).
Relocate: VMware Cloud on AWS — move vSphere inteiro sem mudar ferramentas.
Rehost: Lift-and-shift com Application Migration Service (MGN).
Repurchase: Troca por SaaS (ex: Exchange on-prem → Microsoft 365).
Replatform: Mantém código, ganha managed (MySQL → RDS, Tomcat → Beanstalk).
Refactor: Reescreve cloud-native (monolito → serverless + microserviços).- → máximo aqui
- → máximo aqui
- Fora da AWS
- Compute
- Rede e entrega
- Banco de dados
- Gestão e governança
A questão de SAP-C03 sempre dá uma restrição — prazo, orçamento, licença, regulação — e espera o R compatível. "Datacenter fecha em 4 meses" nunca é Refactor; "reduzir custo de licença Oracle" é Replatform.
- Comece perguntando o que NÃO migra. Retire é o R mais rentável e o mais esquecido: parque típico tem 10 a 20% de servidor que ninguém usa. Migrar lixo custa dinheiro duas vezes — no projeto e na fatura mensal.
- Rehost tira você do datacenter rápido. MGN replica o servidor inteiro e faz cutover com downtime de minutos. Nenhum benefício de nuvem além de sair do datacenter — e é exatamente por isso que funciona: prazo curto, risco baixo.
- Replatform é o ponto ótimo mais comum. Trocar Oracle por Aurora PostgreSQL, ou MySQL self-managed por RDS. Ganha backup, patch e Multi-AZ gerenciados sem reescrever a aplicação. É a resposta de "reduzir esforço operacional sem refatorar".
- Repurchase quando existe SaaS. CRM próprio virando Salesforce, e-mail virando Workmail. Nenhum código seu sobrevive — e às vezes é a decisão certa, porque o software não era diferencial competitivo.
- Refactor por último, e por motivo de negócio. Reescrever para serverless dá o maior ganho e o maior risco. Fazer isso DURANTE a migração é o que transforma projeto de 6 meses em projeto de 3 anos. O padrão é rehost primeiro, refactor depois.
Em migração real 1.000 servidores: ~30% Retire (surpreendentemente alto após descoberta), 40% Rehost (quick wins), 20% Replatform, 5% Refactor, 5% Retain. Refactor é caro, faça só onde ROI é claro (app crítico que se beneficia de serverless scale).
Onde isso entra no exame
Domain 4 é quase todo aqui: dado um inventário e uma restrição (licença, prazo, dependência entre sistemas), escolher entre as 7 Rs. Replatform troca o gerenciamento sem reescrever; refactor é o único que muda o código. Saiba a ferramenta de cada R — MGN para rehost, DMS com SCT para banco heterogêneo, DataSync para arquivo.
Ferramentas de migração
Application Migration Service (MGN):
- Sucessor do SMS + CloudEndure
- Replica bloco-nível de VM on-prem → EBS em AWS
- Cutover em minutos; rollback simples
- Free por 90 dias pra cada servidor
Database Migration Service (DMS):
- Origem: Oracle, SQL Server, MySQL, PostgreSQL, MongoDB
- Destino: RDS, Aurora, Redshift, S3, DynamoDB
- Full load + CDC contínuo
- Serverless DMS disponível (escalar on-demand)
Schema Conversion Tool (SCT):
- Converte schema + código procedural heterogêneo
- Relatório de items não-convertíveis (com sugestão)
- Funciona standalone ou integrado a DMS
DataSync:
- Transfer de dados em file-level (NFS/SMB → S3/EFS/FSx)
- 10x mais rápido que rsync/scp em escala
Snow Family (Snowcone/Snowball/Snowmobile):
- Transfer offline pra volumes maciços ou locais
sem largura de bandaUma aplicação roda em Oracle com licença perpétua paga, o contrato do datacenter vence em 4 meses, e o time é pequeno. Qual estratégia?
Cutover estratégico sem downtime zero
Zero downtime é miragem cara. Objetivo real: cutover curto (<15min pra apps críticos, <2h pra batch). Receita: DMS CDC mantendo réplica sincronizada → Route 53 weighted routing gradualmente deslocando tráfego → monitoring com rollback pronto. Se algo quebra na primeira hora pós-cutover, volta tráfego pra on-prem em minutos.
Antipattern clássico: cutover de sexta à noite, engenheiros de plantão, sem plano de rollback. Faça wave migrations (apps em grupos), rehearsals em staging clone da prod, e mantenha on-prem por 2-4 semanas após cutover como fallback.
Ordem didática: descoberta (Application Discovery Service 2-4 sem) → portfolio analysis (decidir R de cada app) → foundation AWS (Landing Zone, networking) → wave 1 (menos crítico) → rehearsals → waves de produção → decom on-prem.
Perguntas frequentes
❓ Como escolher entre os 7 Rs numa migração real?
❓ Por que mover como está antes de modernizar?
❓ Como migrar banco de dados grande com pouca indisponibilidade?
Fixando
Qual R descreve "trocar o servidor de e-mail próprio pelo Microsoft 365"?
Por que Retire costuma ser o R de maior retorno imediato?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…