Vou trocar de provedor de cloud
Resposta rápida
Trocar de provedor de cloud é projeto de meses, não de semanas, e dá errado quando começa pela escolha do novo provedor antes de entender o que existe no atual. A sequência que funciona tem cinco passos: inventário detalhado do que roda hoje (compute, dados, redes, identidades, integrações, dependências de serviços proprietários do provedor atual), análise de portabilidade workload por workload (o que é lift-and-shift, o que exige refatoração, o que faz sentido descontinuar), modelagem de custos comparáveis incluindo egress do provedor atual e taxa de entrada no novo, plano de migração em ondas por criticidade e dependência, e período de operação paralela para os workloads críticos. Sem essa sequência, a empresa descobre tarde demais que o que parecia equivalente custa o dobro ou exige reescrever sistema.
Na empresa pequena, "trocar de cloud" geralmente significa migrar poucas máquinas virtuais, um banco e algum SaaS conectado. A decisão costuma vir do dono ou do líder de TI por preço, suporte em português ou recomendação de parceiro. O risco principal não é a complexidade técnica e sim subestimar o custo de saída — o provedor atual cobra para você levar seus dados embora — e os dias de operação enquanto a migração acontece. Faça um inventário simples em planilha, peça orçamento real do egress ao provedor atual, escolha uma janela de baixa atividade (fim de semana ou feriado prolongado) e tenha um plano B claro: se a migração travar, como volta. Um parceiro com experiência em migração nesse porte costuma economizar mais do que cobra.
Na empresa média, a migração já envolve dezenas de workloads, integrações com sistemas de negócio e dependências de serviços específicos do provedor atual (filas, funções serverless, banco gerenciado, identidade). Patrocínio executivo claro é necessário — geralmente CFO ou COO — porque o custo de migração e o risco de operação afetam o resultado do trimestre. Comitê semanal de migração com TI, áreas de negócio impactadas e o fornecedor que apoia o projeto, plano em três a seis ondas por criticidade, ferramentas de IaC para reduzir a chance de configuração manual divergir. O erro característico desse porte é tratar a migração como projeto puro de TI: as áreas de negócio precisam saber quando seu sistema vai entrar em janela de risco e o que muda na operação.
Na empresa grande, troca de cloud é programa de seis a vinte e quatro meses, com governança formal patrocinada por CIO ou CTO em alinhamento com conselho e CFO. Centenas a milhares de workloads, dependências profundas com serviços proprietários, contratos com SLA forte, equipes inteiras dedicadas. A análise de portabilidade vira projeto próprio meses antes da migração começar. Modelo financeiro precisa contemplar custo de operação dupla, custo de egress, taxa de entrada no novo provedor, custo de refatoração de cargas que não fazem lift-and-shift, custo de capacitação do time. Governança em três camadas (executiva, tática, operacional), centro de excelência interno conduzindo, parceiro especializado apoiando. O risco a vigiar é o programa virar fim em si mesmo — perder de vista por que se migra e continuar migrando mesmo quando os números mudam.
- A fatura do provedor atual cresce mais do que o uso justifica
- Serviços proprietários do provedor amarram a empresa em decisões futuras
- Há mudança de estratégia (compliance, governança de dados, geografia)
- Outro provedor oferece condição comercial substancialmente melhor
- Empresa adquirida ou matriz exige consolidação em outro provedor
- Performance ou suporte do provedor atual deteriorou de forma persistente
Decidir migrar antes de escolher para onde
A primeira pergunta não é "qual provedor é melhor" — é "por que estamos migrando". As razões legítimas costumam cair em quatro famílias: custo (a conta atual virou problema material), bloqueio (dependência de serviços proprietários impede decisões futuras), risco (governança de dados, compliance, geografia), estratégia (matriz, fusão, integração com outro ecossistema). Cada razão exige análise diferente. Migrar por custo sem incluir egress e refatoração na conta costuma se reverter em alguns meses. Migrar por bloqueio sem mapear quais serviços proprietários estão em uso pode trocar um vendor lock por outro.
Quando não migrar
Existem casos em que a resposta certa é não migrar. Se a razão é insatisfação difusa com o suporte sem problema técnico identificável, renegociar o contrato com o provedor atual costuma ser mais barato do que migrar. Se a razão é "ouvimos que o concorrente é melhor" sem análise de custo total, é decisão emocional. Se a empresa está em momento de instabilidade operacional ou financeira, somar o risco de uma migração pode ser irresponsável. Migração de cloud é caro e arriscado — só vale quando o custo da inércia é maior do que o custo da mudança.
Inventário antes de qualquer plano
O inventário do que existe hoje é o trabalho mais subestimado do projeto. Não basta listar instâncias e bancos — precisa cobrir compute (VMs, containers, serverless), armazenamento (volumes, buckets, tipos de classe), bancos de dados (engine, versão, recursos específicos do provedor), rede (VPCs, peerings, gateways, IPs públicos), identidade (usuários, papéis, federação, integrações com diretório), serviços gerenciados (filas, eventos, busca, cache, ML), integrações (APIs internas e externas, webhooks, SaaS conectado), dados em trânsito e em repouso, certificados, segredos, jobs agendados, monitoramento, backup e recuperação. Um workload mal mapeado vira surpresa cara durante ou depois da migração.
- Inventário e dependências (1-3 meses). Mapear tudo o que roda hoje, identificar dependências entre workloads e com serviços proprietários do provedor atual.
- Análise de portabilidade workload por workload. Classificar em lift-and-shift, lift-and-reshape (mudança pequena), refator (mudança grande), retire (descontinuar) ou retain (manter no provedor atual por enquanto).
- Modelagem de custo comparável. Incluir uso projetado, egress de saída, taxa de entrada, custos de operação dupla durante migração, custo de refatoração, custo de capacitação. Comparar com o custo de não migrar.
- Plano de ondas e cronograma. Agrupar workloads por criticidade e dependência. Começar pelos menos críticos para aprender, terminar pelos mais críticos com mais segurança.
- Construção da landing zone no novo provedor. Rede, identidade, segurança, observabilidade, backup, IaC — tudo pronto antes do primeiro workload migrar.
- Migração em ondas com operação paralela. Cada onda migra, opera em paralelo o tempo necessário para validar, e só então corta o provedor antigo. Workloads críticos exigem janela maior.
- Descomissionamento limpo. Encerrar contratos, garantir que todos os dados foram movidos ou descartados conforme política, encerrar usuários, recuperar créditos pendentes.
Os custos que costumam aparecer só depois
A modelagem financeira ingênua compara "preço de hora de máquina A vs preço de hora de máquina B". A real precisa incluir cinco categorias frequentemente esquecidas. Egress de saída do provedor atual — mover terabytes ou petabytes não é grátis. Taxa de entrada no novo provedor — alguns oferecem crédito de migração, outros não. Operação dupla — durante a migração você paga os dois provedores ao mesmo tempo, às vezes por meses. Refatoração — workloads que dependiam de serviço proprietário do provedor atual precisam ser reescritos. Capacitação do time — engenheiros que dominavam o provedor antigo levam tempo para serem produtivos no novo.
Operação paralela e plano de retorno
Workloads críticos não saem do provedor antigo no dia em que entram no novo. Operam em paralelo pelo tempo necessário para validar comportamento, performance, custo real, integrações e procedimentos operacionais. Para alguns workloads, paralelo de dias resolve; para sistemas transacionais, podem ser semanas. Em paralelo a isso, plano de retorno escrito: se algo travar, como volta para o provedor antigo, em quanto tempo, com que perda. Sem plano de retorno, a equipe migra com medo e cria gambiarras de última hora que se tornam dívida permanente.
Escolher o destino antes do inventário. Decidir o novo provedor antes de saber o que vai migrar leva a contratos que não casam com o consumo real. Inventário primeiro, modelagem depois, contrato por último.
Ignorar serviços proprietários. Lambda, Cosmos DB, BigQuery, Pub/Sub e equivalentes não têm tradução automática para outros provedores. Cada um vira projeto de refatoração que pode dobrar o custo da onda em que aparece.
Subestimar egress de saída. Mover dados do provedor atual pode custar dezenas a centenas de milhares dependendo do volume. Esse número aparece na fatura do provedor antigo, não no contrato do novo.
Tratar como projeto puro de TI. Áreas de negócio precisam saber quando seu sistema entra em janela, o que pode mudar na performance e como reportar incidente. Sem comunicação organizada, a migração ganha fama de instabilidade.
Não medir o resultado pós-migração. Custo real no novo provedor, performance percebida pelos usuários, estabilidade. Sem medição, a empresa nunca aprende com o projeto e o próximo ciclo repete os mesmos erros.
- Inventário completo dos workloads atuais com dependências mapeadas
- Classificação de portabilidade workload por workload (shift, reshape, refator, retire, retain)
- Modelagem de custo incluindo egress, entrada, operação dupla, refatoração e capacitação
- Comparação com custo de não migrar (renegociar com o provedor atual)
- Cláusulas do novo contrato sobre crédito de migração, compromisso mínimo e portabilidade futura
- Plano de ondas validado por criticidade e dependência, com cronograma realista
- Plano de retorno escrito para cada onda crítica, com critério de acionamento
- Patrocinador executivo com mandato para sustentar o projeto por meses