Migração para cloud não é um evento — é um projeto com fases definidas, dependências técnicas e riscos que precisam ser gerenciados. A maioria das falhas não acontece por problema de tecnologia. Acontece por falta de assessment, planejamento superficial de rede e ausência de critérios de reversão.
Os 6 Rs: as seis estratégias de migração
O framework dos 6 Rs (originalmente descrito pela AWS e ampliado pelo Gartner) classifica como cada aplicação ou serviço pode ser migrado. Aplicar o Rs correto para cada workload é a decisão mais importante do planejamento.
| Estratégia | O que significa | Esforço | Risco | Benefício |
|---|---|---|---|---|
| Rehost (Lift & Shift) | Mover a VM como está, sem alterar o código | Baixo | Baixo | Migração rápida, base para otimizações futuras |
| Replatform (Lift & Reshape) | Ajustes pontuais para usar serviços gerenciados (ex: trocar MySQL local por RDS) | Médio | Médio | Redução de overhead operacional sem reescrever |
| Repurchase | Trocar aplicação por versão SaaS equivalente (ex: migrar CRM on-prem para Salesforce) | Baixo | Médio | Elimina manutenção de aplicação, curva de aprendizado no novo produto |
| Refactor / Re-architect | Redesenhar a aplicação para arquitetura cloud-native (containers, microsserviços, serverless) | Alto | Alto | Máxima escalabilidade e uso eficiente de cloud, mas longa execução |
| Retire | Descomissionar sistemas que não têm mais usuários ou valor de negócio | Nenhum | Nenhum | Reduz custo e complexidade antes de migrar |
| Retain | Manter on-premises por limitação técnica, legal ou de custo | Nenhum | Nenhum | Evita migrar o que não deve ser migrado agora |
Na prática, um ambiente corporativo típico vai usar quatro ou cinco Rs simultaneamente. A maioria das cargas vai para Rehost primeiro — e Refactor vem depois, quando a operação em cloud já está estabilizada.
Assessment e inventário: o passo que não pode ser pulado
Antes de qualquer decisão de migração, você precisa saber o que existe no ambiente. Um assessment mal feito é a causa número um de surpresas durante a migração.
O que mapear:
- Inventário de servidores: físicos, virtuais, sistemas operacionais, versões
- Dependências entre aplicações: qual sistema chama qual, em qual porta, com qual protocolo
- Consumo de recursos: CPU, memória, disco, IOPS — idealmente coletados por 30 a 90 dias
- Dados: volumes totais, taxa de crescimento, frequência de acesso (hot/warm/cold)
- Licenças de software: quais são portáveis para cloud, quais exigem nova aquisição
- SLAs e janelas de manutenção: quais sistemas têm tolerância zero a downtime
Ferramentas de assessment: Ferramentas como AWS Application Discovery Service, Azure Migrate e soluções de terceiros (Movere, CloudHealth) automatizam parte desse levantamento. Para ambientes menores, um inventário manual em planilha com os campos acima já é suficiente.
Saída esperada do assessment: uma tabela com cada aplicação classificada por complexidade, dependências, Rs recomendado e janela estimada de migração.
Definição de prioridades: o que migrar primeiro
A ordem de migração importa tanto quanto a estratégia. Não existe fórmula universal, mas existem princípios sólidos:
Comece pelo que tem menor risco e maior aprendizado. Sistemas internos sem SLA crítico (ferramentas de desenvolvimento, ambientes de teste, wikis, sistemas de RH) são candidatos ideais para a primeira onda. O objetivo é a equipe aprender a operar em cloud antes de migrar sistemas críticos.
Migrate sistemas dependentes juntos. Se a aplicação A chama a aplicação B com latência sensível, migre as duas na mesma janela ou planeje uma fase de coexistência com link dedicado.
Adie sistemas com alto risco e baixo benefício. Aplicações legadas sem documentação, sistemas com integrações desconhecidas ou fornecedores que não suportam cloud devem ir para o final — ou para o Rs “Retain”.
Sequência recomendada:
- Ambientes de dev/test
- Sistemas internos não críticos
- Sistemas críticos com janela de manutenção clara
- Sistemas de missão crítica com plano de rollback detalhado
- Banco de dados e storage (geralmente os últimos — mais complexos)
Planejamento de rede e segurança antes de mover qualquer VM
Esse planejamento precisa acontecer antes da migração, não durante.
Conectividade: Como os usuários e sistemas on-premises vão acessar os recursos em cloud durante a fase híbrida? As opções são VPN site-to-site (mais simples, custo baixo, latência variável) ou link dedicado como Direct Connect / ExpressRoute (custo mais alto, latência previsível). Para sistemas críticos, link dedicado é recomendado.
Segmentação de rede: Defina VPCs ou redes virtuais, sub-redes por camada (apresentação, aplicação, dados), regras de firewall e grupos de segurança antes de criar as primeiras VMs em cloud. Retroajustar rede em cloud depois que VMs estão rodando é trabalhoso e arriscado.
Identity e acesso: Defina como identidades on-premises vão se federar com a cloud (Active Directory com LDAP sync, SAML, OpenID Connect). Evite criar contas locais isoladas na cloud — elas geram shadow IT e complicam auditorias.
Criptografia: Defina política de criptografia em trânsito (TLS mínimo 1.2) e em repouso (criptografia de disco habilitada por padrão) antes de migrar dados.
Logging e monitoramento: Configure coleta de logs e alertas antes de migrar sistemas críticos. Descobrir um problema de performance ou segurança sem logs já está custando tempo e reputação.
Migração em fases vs. big bang
Big bang: Todos os sistemas migram em uma única janela de manutenção. Minimiza o tempo de ambiente híbrido, mas concentra o risco. Adequado apenas para ambientes pequenos e bem documentados, com equipe experiente e plano de rollback testado.
Migração em fases: Sistemas migram em ondas ao longo de semanas ou meses. Permite aprendizado incremental, correção de problemas antes que afetem sistemas críticos e menor impacto por evento. É a abordagem recomendada para a maioria dos casos.
Na fase híbrida — quando parte do ambiente está em cloud e parte on-premises — é essencial manter visibilidade unificada de métricas, logs e alertas. Ferramentas como Zabbix, Prometheus/Grafana, Datadog ou New Relic funcionam bem em ambientes híbridos.
Testes e validação antes do cutover
O cutover (virada de produção) não pode ser a primeira vez que você testa o sistema em cloud.
Checklist de validação antes do cutover:
- Todos os serviços necessários estão rodando e respondendo
- Latência de rede entre componentes está dentro do baseline esperado
- Banco de dados sincronizado com produção (zero ou mínimo lag)
- Testes funcionais executados (smoke tests, testes de integração)
- Performance testada sob carga (ao menos uma simulação de carga representativa)
- Plano de rollback documentado e testado — você sabe como voltar se der errado?
- Comunicação preparada para usuários sobre a janela de manutenção
- Equipe de plantão durante e após o cutover
DNS cutover: A maioria das migrações usa DNS como ponto de virada. Reduza o TTL dos registros críticos para 60–300 segundos com antecedência (24–48 horas antes). Isso permite reverter rapidamente se necessário.
Erros comuns que causam falha na migração
Pular o assessment: A equipe acha que conhece o ambiente e não documenta dependências. Na migração, descobre integração desconhecida que quebra o sistema.
Migrar banco de dados junto com a aplicação: Banco de dados tem complexidade própria — replicação, sincronização, janela de corte. Migre aplicação e banco em fases separadas.
Não testar o rollback: Plano de rollback existe no papel, mas nunca foi executado. No dia do cutover, o rollback não funciona e o problema se arrasta.
Ignorar o custo de egresso: O tráfego de saída do datacenter tem custo em praticamente todo provedor cloud. Sistemas que movem grandes volumes de dados (backup, replicação) podem gerar surpresas na fatura.
Manter credenciais on-premises em sistemas cloud: Secrets e credenciais hardcoded em código ou configuração são risco de segurança em qualquer ambiente. Em cloud, o risco é maior porque a superfície de exposição é maior.
Não planejar capacidade: Mover uma VM com 8 vCPUs para um tipo de instância equivalente em cloud pode ser mais caro ou mais barato dependendo do perfil de uso real. Dimensione com base nos dados do assessment, não na configuração atual.
Precisa de apoio técnico para assessment e planejamento de migração? O time de arquitetura da Adentro conduz esse processo com metodologia estruturada.