Migração para cloud sem surpresas: por onde começar e o que não migrar

Migrar tudo de uma vez é o erro mais caro

Projetos de nuvem falham menos por tecnologia e mais por sequenciamento. Mover o ambiente inteiro em um fim de semana concentra risco, impede aprendizado e costuma terminar em rollback. Migração boa é feita em ondas.

Fase 1 — Inventário e dependências

Antes de qualquer coisa: quais sistemas existem, quem os usa, com quem eles conversam e qual o impacto de cada um ficar fora do ar por uma hora. Sem esse mapa, qualquer estimativa de custo e prazo é chute.

Fase 2 — Classificar cada carga de trabalho

• Rehost: sobe como está. Rápido, bom para ganhar tempo e sair de hardware vencido.
• Replatform: sobe com ajustes, como trocar um banco local por serviço gerenciado.
• Refactor: vale para o que é diferencial competitivo e vai crescer.
• Reter ou aposentar: nem todo sistema merece migração. Alguns só precisam ser desligados.

O que normalmente não deve ir para a nuvem

• Aplicações com latência crítica ligada a equipamento local, como chão de fábrica.
• Sistemas legados sem fornecedor ativo e sem suporte a virtualização moderna.
• Grandes volumes de dados de acesso constante cuja transferência custa mais do que o próprio armazenamento.

Controlar o custo desde o primeiro dia

• Marcar todos os recursos por centro de custo e projeto.
• Definir orçamento com alerta automático antes do fechamento do mês.
• Desligar ambientes de teste fora do horário comercial.
• Revisar o dimensionamento no 30º e no 90º dia — quase sempre há recurso sobrando.

Ambientes híbridos são a realidade da maioria das empresas brasileiras: parte na nuvem, parte no data center local. O objetivo não é estar 100% na nuvem, é colocar cada carga onde ela custa menos e entrega mais.