Cloud & Infraestrutura

Guia Completo de Migração para AWS: Estratégias 6R, MGN e Database Migration Service

8 min de leitura

Guia Completo de Migração para AWS: Estratégias 6R, MGN e Database Migration Service

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

<h2>As Estratégias 6R: Entendendo o Framework</h2>

<p>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. <strong>Rehost</strong> (&quot;lift-and-shift&quot;) é a migração mais rápida — você move a aplicação como está, ideal para MVPs ou quando o tempo é crítico. <strong>Replatform</strong> envolve otimizações leves, como mudar de servidor físico para RDS. <strong>Refactor</strong> é reescrever a aplicação para arquitetura cloud-native (microsserviços, containers). <strong>Repurchase</strong> significa trocar por um SaaS equivalente. <strong>Retire</strong> é desativar aplicações obsoletas. <strong>Retain</strong> é manter on-premise.</p>

<p>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.</p>

<h2>AWS MGN: Migração de Servidores Físicos e Virtuais</h2>

<p>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.</p>

<p>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.</p>

<p><strong>Exemplo prático — instalação e uso:</strong></p>

<pre><code class="language-bash">#!/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 &#039;items[].{ServerID:serverId,Status:lastSeenByServiceDateTime}&#039;</code></pre>

<p>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.</p>

<h3>Vantagens e Limitações</h3>

<p>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.</p>

<h2>AWS Database Migration Service: Movendo Dados com Precisão</h2>

<p>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.</p>

<p>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.</p>

<p><strong>Exemplo funcional — migração Oracle para RDS PostgreSQL:</strong></p>

<pre><code class="language-python">#!/usr/bin/env python3

import boto3

import json

dms_client = boto3.client(&#039;dms&#039;, region_name=&#039;us-east-1&#039;)

Criar endpoint de origem (Oracle on-premise)

source_endpoint = dms_client.create_endpoint(

EndpointIdentifier=&#039;oracle-source-prod&#039;,

EndpointType=&#039;source&#039;,

EngineName=&#039;oracle&#039;,

ServerName=&#039;oracle-prod.company.com&#039;,

Port=1521,

DatabaseName=&#039;PROD&#039;,

Username=&#039;migration_user&#039;,

Password=&#039;SecurePassword123&#039;,

ExtraConnectionAttributes=&#039;heartbeatEnable=true&#039;

)

Criar endpoint de destino (RDS PostgreSQL)

target_endpoint = dms_client.create_endpoint(

EndpointIdentifier=&#039;postgres-target-rds&#039;,

EndpointType=&#039;target&#039;,

EngineName=&#039;postgres&#039;,

ServerName=&#039;mydb.123456789.us-east-1.rds.amazonaws.com&#039;,

Port=5432,

DatabaseName=&#039;production&#039;,

Username=&#039;postgres&#039;,

Password=&#039;RDSPassword456&#039;

)

Criar tarefa de migração

task_response = dms_client.create_replication_task(

ReplicationTaskIdentifier=&#039;oracle-to-postgres-full&#039;,

SourceEndpointArn=source_endpoint[&#039;Endpoint&#039;][&#039;EndpointArn&#039;],

TargetEndpointArn=target_endpoint[&#039;Endpoint&#039;][&#039;EndpointArn&#039;],

ReplicationInstanceArn=&#039;arn:aws:dms:us-east-1:123456789:rep:dms-repinstance-prod&#039;,

MigrationType=&#039;cdc&#039;, # Change Data Capture após full load

TableMappings=json.dumps({

&quot;rules&quot;: [

{

&quot;rule-type&quot;: &quot;selection&quot;,

&quot;rule-id&quot;: &quot;1&quot;,

&quot;rule-name&quot;: &quot;migrate-all-tables&quot;,

&quot;object-locator&quot;: {

&quot;schema-name&quot;: &quot;%&quot;,

&quot;table-name&quot;: &quot;%&quot;

},

&quot;rule-action&quot;: &quot;include&quot;

}

]

}),

ReplicationTaskSettings=json.dumps({

&quot;TargetMetadata&quot;: {&quot;SupportLobs&quot;: True},

&quot;FullLoadSettings&quot;: {&quot;CommitRate&quot;: 50000},

&quot;LOBChunkSize&quot;: 64,

&quot;ValidationSettings&quot;: {&quot;EnableValidation&quot;: True}

})

)

Iniciar tarefa

dms_client.start_replication_task(

ReplicationTaskArn=task_response[&#039;ReplicationTask&#039;][&#039;ReplicationTaskArn&#039;],

StartReplicationTaskType=&#039;start-replication&#039;

)

print(f&quot;Tarefa iniciada: {task_response[&#039;ReplicationTask&#039;][&#039;ReplicationTaskIdentifier&#039;]}&quot;)</code></pre>

<p>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.</p>

<h3>Estratégia de Migração Homogênea vs Heterogênea</h3>

<p>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.</p>

<h2>Integrando as Estratégias: Um Caso Real</h2>

<p>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.</p>

<p>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.</p>

<h2>Conclusão</h2>

<p>Os três pilares da migração AWS são complementares: <strong>estratégias 6R definem a abordagem</strong>, <strong>MGN executa rehost em massa</strong>, e <strong>DMS garante integridade de dados</strong>. 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.</p>

<h2>Referências</h2>

<ul>

<li><a href="https://docs.aws.amazon.com/mgn/" target="_blank" rel="noopener noreferrer">AWS Application Migration Service Documentation</a></li>

<li><a href="https://docs.aws.amazon.com/dms/" target="_blank" rel="noopener noreferrer">AWS Database Migration Service User Guide</a></li>

<li><a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-framework/welcome.html" target="_blank" rel="noopener noreferrer">AWS 6 Rs Migration Strategies</a></li>

<li><a href="https://docs.aws.amazon.com/sct/" target="_blank" rel="noopener noreferrer">AWS Schema Conversion Tool</a></li>

<li><a href="https://docs.aws.amazon.com/wellarchitected/latest/migration-lens/welcome.html" target="_blank" rel="noopener noreferrer">AWS Well-Architected Framework — Migration Lens</a></li>

</ul>

Comentários

Mais em Cloud & Infraestrutura

Dominando Redshift e Athena: Data Warehouse e Query Serverless em S3 em Projetos Reais
Dominando Redshift e Athena: Data Warehouse e Query Serverless em S3 em Projetos Reais

Entendendo Redshift e Athena: Duas Abordagens para Data Warehouse Redshift e...

Boas Práticas de CloudWatch em Profundidade: Métricas, Logs, Alarms e Dashboards para Times Ágeis
Boas Práticas de CloudWatch em Profundidade: Métricas, Logs, Alarms e Dashboards para Times Ágeis

Fundamentos do CloudWatch para Times Ágeis CloudWatch é o serviço nativo da A...

CloudWatch Container Insights e Lambda Insights na Prática: Do Básico ao Avançado
CloudWatch Container Insights e Lambda Insights na Prática: Do Básico ao Avançado

CloudWatch Container Insights: Observabilidade para Contêineres Container Ins...