Vou migrar de on-premise para cloud por completo

Decidir migrar tudo, parte ou nada

"Migrar 100%" não é a única opção. Antes de decidir fechar o data center, considere três cenários. Migrar tudo: melhor quando o data center está envelhecendo, o time quer e o portfólio de aplicações cabe bem na cloud. Migrar a maior parte e manter um núcleo no on-premise: faz sentido para empresas com cargas muito específicas (compliance estrito de localização, latência extrema, hardware especializado). Migrar nada: ainda existe gente que faz a conta e decide que o retorno não compensa o risco, especialmente em ambientes muito estáveis com cargas previsíveis. A pergunta certa é "qual é o melhor uso do nosso dinheiro e da nossa atenção pelos próximos cinco anos", não "todo mundo está indo para cloud, vamos também".

Quando a migração total faz mais sentido

Quatro condições combinadas costumam justificar o programa de migração completa. O hardware está perto do fim de vida útil — o próximo refresh seria caro e o capital se converteria em opex na cloud. O portfólio de aplicações é majoritariamente compatível — sem muitos sistemas que dependem de hardware especializado. A liderança quer focar atenção em produto e cliente, não em data center. O time tem disposição para aprender o novo paradigma — ou a empresa está disposta a investir em capacitação e renovação parcial. Faltando alguma dessas condições, vale reconsiderar.

As seis estratégias de migração por carga

Cada aplicação se encaixa em uma das seis estratégias. Rehost (lift-and-shift): copiar a máquina como está para cloud, sem refatorar. Mais rápido, menos otimizado. Replatform (lift-and-reshape): pequenas mudanças para usar serviços gerenciados (banco gerenciado em vez de instalado em VM, por exemplo). Refactor: reescrever para cloud-native, aproveitando serviços específicos do provedor. Repurchase: trocar pela versão SaaS equivalente (CRM próprio vira CRM cloud, e-mail próprio vira Microsoft 365 ou Google Workspace). Retire: descontinuar — frequentemente 10% a 30% das aplicações descobertas no inventário estão sem uso real. Retain: manter no on-premise por enquanto, com motivo específico. Um portfólio típico mistura várias estratégias.

A conta verdadeira da migração

A modelagem financeira ingênua compara "custo do data center hoje" com "custo da cloud equivalente amanhã". A modelagem honesta inclui mais variáveis. Custo do programa em si: parceiro, ferramentas de migração, capacitação, ondas e cutovers. Custo de operação dupla: o data center continua existindo durante meses ou anos enquanto cargas saem progressivamente. Custo da cloud em uso estável: não o consumo do primeiro mês, mas o consumo em regime, depois que o time aprendeu a otimizar (FinOps maduro costuma reduzir significativamente o custo inicial). Custo de descomissionamento: encerrar contratos, descartar hardware conforme política ambiental, liberar espaço, eventualmente recolocar equipe. A comparação justa é entre o TCO do próximo ciclo on-premise (com refresh de hardware incluído) e o TCO da cloud em uso estável.

Capacitar o time é parte do programa, não anexo

Operar cloud não é operar data center com outro nome. Práticas mudam: provisionamento via código, custo gerido continuamente (FinOps), segurança em modelo de responsabilidade compartilhada, observabilidade ao invés de monitoramento clássico, automação como padrão e não como exceção. O time existente precisa aprender essas práticas; algumas pessoas vão prosperar, outras vão preferir trilhas diferentes. Plano explícito de capacitação — certificações, treinamentos práticos, mentoria por parceiro, projetos guiados — protege o programa. Empresas que tratam capacitação como "vamos aprendendo no caminho" costumam terminar a migração com time desmotivado e operação cara.