As Estratégias 6R: Entendendo o Framework
As estratégias 6R (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) são o alicerce de qualquer plano de migração para AWS. Cada estratégia representa uma abordagem diferente e deve ser escolhida considerando custo, complexidade e benefício esperado. Rehost ("lift-and-shift") é a migração mais rápida — você move a aplicação como está, ideal para MVPs ou quando o tempo é crítico. Replatform envolve otimizações leves, como mudar de servidor físico para RDS. Refactor é reescrever a aplicação para arquitetura cloud-native (microsserviços, containers). Repurchase significa trocar por um SaaS equivalente. Retire é desativar aplicações obsoletas. Retain é manter on-premise.
Na prática, a maioria das empresas usa uma combinação. Um monolith legado pode fazer Rehost com MGN, enquanto o banco de dados migra com DMS e a aplicação nova é desenvolvida em Refactor. O segredo é avaliar cada workload individualmente. Não existe estratégia universal — depende do business case, arquitetura atual e maturidade cloud da organização.
AWS MGN: Migração de Servidores Físicos e Virtuais
AWS Application Migration Service (MGN) é a ferramenta de choice para Rehost em larga escala. Ele replica seus servidores (físicos ou VMs) para AWS com downtime mínimo usando um agente lightweight. MGN converte automaticamente para AMIs otimizadas e valida a migração antes do cutover.
O processo é direto: você instala um agente de replicação contínua no servidor de origem, MGN replica o disco inteiro para EBS, você testa em staging, e depois executa o cutover com downtime de minutos. MGN suporta Windows, Linux e até mainframes.
Exemplo prático — instalação e uso:
#!/bin/bash
# Script de instalação do agente MGN (Linux)
# Baixar o agente
wget https://aws-application-migration-service.us-east-1.amazonaws.com/latest/linux/aws-mgn-installer-linux.tar.gz
# Extrair e instalar
tar -xzf aws-mgn-installer-linux.tar.gz
cd ./aws-mgn-installer
sudo ./install.sh \
--region us-east-1 \
--access-key-id YOUR_ACCESS_KEY \
--secret-access-key YOUR_SECRET_KEY
# Verificar status da replicação
aws mgn describe-replication-agents \
--region us-east-1 \
--query 'items[].{ServerID:serverId,Status:lastSeenByServiceDateTime}'
Após instalar, o agente começa replicação contínua. No console AWS MGN, você monitora o progresso, executa testes de inicialização (launch test) em um ambiente isolado, e quando confiante, executa o cutover final. O tempo de inatividade é tipicamente 15-30 minutos — o tempo para fazer failover do DNS/IP.
Vantagens e Limitações
MGN é ideal para migrar centenas de servidores rapidamente com risco mínimo. A limitação é que você não otimiza o workload nesta fase — é apenas um movimento. Depois de estável em AWS, você refatora.
AWS Database Migration Service: Movendo Dados com Precisão
DMS (Database Migration Service) é especializado em replicação de banco de dados homogênea (Oracle → RDS Oracle) ou heterogênea (Oracle → PostgreSQL). Diferente de dumps simples, DMS faz replicação contínua com zero ou mínimo downtime.
DMS usa uma replication instance (EC2 intermediária) que se conecta ao banco de origem e destino, captura mudanças e as aplica no alvo. Suporta full load + change data capture (CDC) — ele copia tudo de uma vez e depois sincroniza alterações em tempo real.
Exemplo funcional — migração Oracle para RDS PostgreSQL:
#!/usr/bin/env python3
import boto3
import json
dms_client = boto3.client('dms', region_name='us-east-1')
# Criar endpoint de origem (Oracle on-premise)
source_endpoint = dms_client.create_endpoint(
EndpointIdentifier='oracle-source-prod',
EndpointType='source',
EngineName='oracle',
ServerName='oracle-prod.company.com',
Port=1521,
DatabaseName='PROD',
Username='migration_user',
Password='SecurePassword123',
ExtraConnectionAttributes='heartbeatEnable=true'
)
# Criar endpoint de destino (RDS PostgreSQL)
target_endpoint = dms_client.create_endpoint(
EndpointIdentifier='postgres-target-rds',
EndpointType='target',
EngineName='postgres',
ServerName='mydb.123456789.us-east-1.rds.amazonaws.com',
Port=5432,
DatabaseName='production',
Username='postgres',
Password='RDSPassword456'
)
# Criar tarefa de migração
task_response = dms_client.create_replication_task(
ReplicationTaskIdentifier='oracle-to-postgres-full',
SourceEndpointArn=source_endpoint['Endpoint']['EndpointArn'],
TargetEndpointArn=target_endpoint['Endpoint']['EndpointArn'],
ReplicationInstanceArn='arn:aws:dms:us-east-1:123456789:rep:dms-repinstance-prod',
MigrationType='cdc', # Change Data Capture após full load
TableMappings=json.dumps({
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "migrate-all-tables",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
}
]
}),
ReplicationTaskSettings=json.dumps({
"TargetMetadata": {"SupportLobs": True},
"FullLoadSettings": {"CommitRate": 50000},
"LOBChunkSize": 64,
"ValidationSettings": {"EnableValidation": True}
})
)
# Iniciar tarefa
dms_client.start_replication_task(
ReplicationTaskArn=task_response['ReplicationTask']['ReplicationTaskArn'],
StartReplicationTaskType='start-replication'
)
print(f"Tarefa iniciada: {task_response['ReplicationTask']['ReplicationTaskIdentifier']}")
Este código cria endpoints, define mapeamento de tabelas, habilita CDC e inicia a migração. DMS capturará o full load da origem em horas/dias (dependendo do tamanho) e depois sincronizará mudanças em tempo real. Você monitora no console ou via API, valida dados com DMS validators, e quando confiante, faz cutover do aplicativo.
Estratégia de Migração Homogênea vs Heterogênea
Migrações homogêneas (mesmo engine) são mais rápidas e com menos risco de incompatibilidade. Heterogêneas exigem schema conversion — AWS oferece Schema Conversion Tool (SCT) para analisar incompatibilidades e sugerir transformações. Sempre use validação de dados pós-migração.
Integrando as Estratégias: Um Caso Real
Uma abordagem híbrida típica funciona assim: servidores de aplicação migram via MGN (Rehost), banco de dados legado migra via DMS (Replatform para gerenciado), e novas funcionalidades são desenvolvidas em Lambda/containers (Refactor). Isso equilibra velocidade de migração com otimização gradual.
Começar com Rehost via MGN permite que você desative data centers rapidamente e gera ROI imediato. Paralelamente, DMS sincroniza bancos de dados com risco mínimo. Depois de 3-6 meses estável, você refatora aplicações críticas para microsserviços. Essa progressão reduz risco e mantém negócio operacional.
Conclusão
Os três pilares da migração AWS são complementares: estratégias 6R definem a abordagem, MGN executa rehost em massa, e DMS garante integridade de dados. Escolha a estratégia certa por workload, use MGN para infraestrutura com downtime mínimo, e confie em DMS para bancos de dados críticos com replicação contínua. Validação de dados e testes de failover são essenciais — não confie apenas em automatização. Por fim, planeje migração com mentalidade de otimização futura, não como evento único.