Como Planejar a Migração Cloud da Sua Empresa

“Vamos para a nuvem” é uma frase que aparece em toda reunião de diretoria. O problema é que, sem planejamento, migração cloud vira sinônimo de custo inesperado, performance pior e complexidade maior.

A cloud não é mágica. É uma mudança de modelo operacional que, bem planejada, transforma a TI. Mal planejada, cria um novo conjunto de problemas.

Antes de Migrar: O Assessment

Antes de comparar preços entre AWS e Azure, responda 3 perguntas:

1. O que temos hoje? Inventário completo: servidores (físicos e virtuais), aplicações, bancos de dados, dependências entre sistemas, volumes de dados e padrões de tráfego.

2. Por que migrar? Reduza a motivação a termos mensuráveis. “Modernizar” não é objetivo — “reduzir RTO de 24h para 1h” ou “eliminar CapEx de renovação de hardware de R$ 200K” são.

3. O que não deve ir? Nem todo workload pertence à cloud. Sistemas com requisitos de latência extrema, regulações de residência de dados, ou custos de licenciamento proibitivos podem ser melhores on-premises.

Os 6 Rs: Estratégia por Workload

Cada sistema merece sua própria estratégia. O framework dos 6 Rs classifica as opções:

Rehost (Lift & Shift)

Mover o servidor como está para uma VM na cloud. Não altera arquitetura, não otimiza — apenas muda de lugar.

Quando usar: Migração rápida, sistemas legados que precisam sair do datacenter mas não justificam redesenho. Boa para a primeira fase.

Limitação: Você paga preço de cloud por uma arquitetura on-premises. Não captura os benefícios de escalabilidade e eficiência.

Replatform (Lift & Optimize)

Move para cloud com ajustes pontuais: trocar banco de dados local por RDS/Azure SQL, usar load balancer gerenciado, mover storage para S3/Blob.

Quando usar: Sistemas que se beneficiam de serviços gerenciados sem reescrita significativa. Melhor custo-benefício para a maioria dos cenários.

Refactor (Re-architect)

Redesenhar a aplicação para ser cloud-native: containers, serverless, microsserviços.

Quando usar: Aplicações que precisam de escala elástica ou que serão investimento estratégico de longo prazo. Alto custo de migração, alto retorno futuro.

Repurchase (Drop & Shop)

Substituir o sistema on-premises por um SaaS equivalente. Exemplo: trocar servidor de email Exchange por Microsoft 365.

Quando usar: Quando existe SaaS maduro que entrega a funcionalidade, geralmente com custo menor que operar o sistema próprio.

Retire

Desligar. Sistemas que ninguém usa, servidores com funções duplicadas, aplicações legadas sem usuários ativos.

Quando usar: Assessment frequentemente revela 10-20% do ambiente que pode simplesmente ser desligado.

Retain

Manter on-premises. Decisão consciente de não migrar um workload específico — por custo, regulação ou requisito técnico.

Quando usar: Sistemas com licenciamento que penaliza cloud, dados com requisito de residência local, ou workloads que já funcionam bem e não justificam o custo de migração.

Análise Financeira: Além do Preço de Lista

O erro mais comum é comparar o preço mensal de uma VM na AWS com o custo de um servidor Dell. Essa comparação ignora componentes críticos:

Custos de cloud frequentemente subestimados:

• Egress (tráfego de saída) — Transferência de dados para fora da cloud é cobrada. Para aplicações com alto volume de downloads ou APIs públicas, esse custo surpreende.
• Storage em camadas — Dados quentes, mornos e frios têm preços diferentes. Sem gestão de ciclo de vida, tudo fica no tier mais caro.
• Suporte — Suporte enterprise da AWS/Azure custa 3-10% do consumo mensal. Sem ele, resolver um incidente crítico depende de fóruns públicos.
• Horas de engenharia — Cloud exige skills diferentes. Custo de treinamento, certificações e possivelmente novas contratações.

Custos on-premises frequentemente esquecidos:

• Depreciação de hardware (renovação a cada 3-5 anos)
• Energia elétrica e refrigeração
• Espaço físico do datacenter/sala de servidores
• Licenças de virtualização
• Tempo da equipe em manutenção de hardware

Use a Calculadora de Custo Cloud para uma estimativa realista que considera ambos os lados.

O Plano de Migração em 4 Fases

Fase 1: Piloto (Semana 1-4)

Migre um sistema não-crítico para validar o processo. Ambiente de desenvolvimento, servidor de arquivos secundário, ou aplicação interna de baixo impacto.

O objetivo não é migrar — é aprender: configuração de rede (VPN/ExpressRoute), IAM, monitoramento, backup cloud, e os processos da equipe.

Fase 2: Workloads Não-Críticos (Mês 2-3)

Com o aprendizado do piloto, migre sistemas que impactam pouco o negócio se houver problema: ambientes de homologação, servidores de arquivo, aplicações departamentais.

Fase 3: Workloads Críticos (Mês 4-6)

Agora que a equipe tem experiência e os processos estão rodando, migre os sistemas de negócio: ERP, banco de dados principal, aplicações de missão crítica.

Para cada sistema crítico:

• Defina janela de migração (preferencialmente fim de semana)
• Tenha rollback documentado e testado
• Comunique stakeholders com antecedência
• Monitore intensivamente nas primeiras 72 horas

Fase 4: Otimização (Mês 6+)

Após migrar, o trabalho muda de foco: right-sizing de instâncias, reserved instances ou savings plans, automação de scaling, e implementação de FinOps para controle contínuo de custos.

5 Armadilhas Comuns

1. Migrar tudo de uma vez. Big bang migrations falham catastroficamente. Migração faseada é mais lenta mas dramaticamente mais segura.

2. Ignorar a rede. Latência entre cloud e sistemas on-premises que ficaram pode quebrar aplicações. Teste a conectividade antes, não depois.

3. Não definir responsáveis. O modelo de responsabilidade compartilhada da cloud é frequentemente mal entendido. O provedor cuida da infraestrutura; você cuida de segurança, dados e configuração.

4. Esquecer o dia 2. O plano de migração termina no “go live”. Mas quem monitora? Quem otimiza custos? Quem responde a incidentes? O dia 2 precisa de planejamento igual ao dia 1.

5. Não ter estratégia de saída. Lock-in total em um provedor cria dependência. Mantenha dados exportáveis e, para workloads críticos, considere portabilidade.

Próximos Passos

1. Estime os custos — Use a Calculadora de Custo Cloud para comparar cenários on-premises vs cloud com TCO realista
2. Avalie seu ambiente — O Assessment de Maturidade de Infraestrutura mostra se sua base está pronta para cloud
3. Comece pelo piloto — Escolha um workload de baixo risco e execute. O aprendizado vale mais que qualquer planejamento teórico

Migração cloud não é um projeto de tecnologia — é um projeto de negócio com componentes técnicos. Trate como tal e as chances de sucesso aumentam dramaticamente.