Por que a maioria das migrações cloud não entrega o ROI prometido — e o que fazer diferente

Q: Por que a maioria das migrações cloud não entrega o ROI prometido?

As 5 causas mais frequentes: 1) Lift-and-shift sem otimização — mover o servidor para cloud sem refatorar é pagar por cloud ao custo de on-premise sem os benefícios. 2) Subestimar custos de egress e licenças. 3) Ausência de FinOps — sem governança de custo, a conta cresce 30-50% além do previsto no primeiro ano. 4) Migração sem app modernization — sistemas legados na cloud têm performance igual ao datacenter, com custo maior. 5) Escopo de migração maior que a capacidade do time.

Q: Como evitar os erros mais comuns em migração cloud?

1) Faça um TCO honesto antes de começar — com egress, licenças, retrabalho. 2) Comece com workloads não-críticos para aprender antes de migrar o core. 3) Implante FinOps desde o dia 1 — not depois que a conta estourar. 4) Defina KPIs de sucesso antes da migração, não depois. 5) Planeje a saída — contratos de cloud sem estratégia de saída viram lock-in.

Q: Quando faz sentido voltar do cloud para on-premise (cloud repatriation)?

Quando o custo total na cloud supera consistentemente o custo de on-premise por 2+ anos sem perspectiva de otimização. Casos comuns: workloads com uso previsível e alto (melhor amortizar hardware), aplicações com alto tráfego de egress, sistemas de armazenamento de dados frios em grande volume. Repatriação não é fracasso — é decisão financeira baseada em dados. O erro é não calcular o TCO real antes de migrar.

70% das migrações cloud ficam acima do orçamento. Não é azar. São os mesmos 5 erros se repetindo. Veja quais são e como evitar.

Pesquisa da Gartner que circulou outro dia: 70% das migrações cloud ficam acima do orçamento original e abaixo do benefício projetado.

Esse número não é azar coletivo. É padrão. Os mesmos 5 erros se repetindo em empresas diferentes.

Vou listar quais são, e o que separa as migrações que entregam o ROI prometido das que não entregam.

Lift-and-shift: o motivo principal de ROI negativo

Lift-and-shift é mover aplicações on-premise para máquinas virtuais cloud sem mudança arquitetural significativa. "Pega como está e coloca em VM na AWS".

É a forma mais rápida de migrar. É também a forma mais cara de operar.

Por quê?

Aplicação on-premise foi desenhada para infraestrutura on-premise. Geralmente assume servidor sempre ligado, tem componentes monolíticos, faz uso intensivo de memória, não escala horizontalmente.

Em cloud, isso significa:

VMs grandes ligadas 24/7 (mesmo quando não estão sendo usadas intensivamente)
Armazenamento provisionado conservadoramente
Nenhum benefício de serverless ou auto-scaling
Custo de licenças que poderiam ser substituídas por serviços nativos cloud

Resultado: você paga cloud com perfil de utilização on-premise. É como alugar um Uber só para ter ele parado na garagem. Você paga sem usar o que tem de melhor.

Cliente real, indústria de transformação: lift-and-shift completo em 2023. Em 2025, custo cloud era 28% acima do que era no datacenter próprio. Refactoring para cloud-native (microserviços onde fazia sentido, serverless para batch jobs, armazenamento em camadas) reduziu o custo em 41% ao longo de 14 meses.

Lift-and-shift como meio temporário é ok. Lift-and-shift como destino final é caro.

Superprovisionamento que nunca é revisado

Em on-premise, você provisionou conservador porque acrescentar capacidade era difícil. Em cloud, ajustar é fácil. Mas só se você ajustar.

Padrão que vejo: equipe migra estimando alto "para garantir". Aplicações sobem em instâncias 30-50% maiores do que precisariam. Ninguém volta para revisar.

Em 6 meses, isso vira hábito. Em 12, vira política tácita. Em 24, vira parte do baseline orçamentário.

O que separa empresas que economizam das que não:

Empresas que economizam

Revisão semanal de utilização nos primeiros 90 dias
Revisão mensal a partir do 4º mês
Métricas de utilização média por workload no dashboard executivo
Time dedicado à otimização (FinOps)

Empresas que não economizam

Provisionam e esquecem
Revisão de custos só quando a fatura vem alta demais
Sem responsável claro pela otimização
"A gente vê isso no próximo trimestre" (que nunca chega)

A diferença não é tecnológica. É de processo e disciplina.

A falta de FinOps nos primeiros 12 meses

FinOps é a prática de gerenciar financeiramente o consumo cloud. Não é só ferramenta. É processo, papel, e cultura.

Empresas que pulam FinOps acreditando que "o time de TI cuida disso" pagam caro.

O que FinOps faz na prática:

Aloca custos por área de negócio (chargeback) — área que gera custo, paga custo
Compra reservas inteligentes — Reserved Instances, Savings Plans, Committed Use
Identifica e elimina recursos órfãos — volumes não montados, IPs não usados, instâncias paradas
Negocia descontos com fornecedor — em alto volume, há margem de negociação
Antecipa picos sazonais e ajusta capacidade

Empresa de médio porte pode economizar 25-40% do custo cloud com FinOps maduro. Sem FinOps, esses 25-40% ficam no fornecedor.

O ROI de implementar FinOps geralmente é < 6 meses para empresas com gasto cloud acima de R$ 200 mil/mês.

Dependências que aparecem depois da migração

"A gente vai economizar X% migrando para cloud."

Aí migra. Aí descobre que precisa de:

Datadog ou New Relic para monitoramento (não vem com cloud) — R$ 30-100 mil/mês
Wiz ou Prisma Cloud para segurança — R$ 20-80 mil/mês
CloudHealth ou similar para gestão de custos — R$ 10-40 mil/mês
SnapLogic ou Mulesoft para integrações — R$ 50-200 mil/ano
Backup terceirizado (o backup do cloud nativo é insuficiente para muitos cenários) — R$ 15-60 mil/mês

Esses são custos verdadeiros que aparecem quando você está rodando, não na proposta original.

Cliente real: gasto cloud projetado de R$ 35 mil/mês. Gasto real depois de 12 meses incluindo todas as ferramentas auxiliares: R$ 67 mil/mês. Não foi mentira do fornecedor — foi proposta incompleta na origem.

O TCO honesto inclui essas ferramentas desde o cálculo inicial.

Calcule o ROI esperado da sua migração com a calculadora gratuita.

Calcular meu ROI de migração cloud →

Como estruturar a migração para realmente entregar o ROI prometido

Depois de auditar dezenas de migrações cloud, vejo um padrão claro do que diferencia as que entregam ROI das que não entregam.

1. Decisão consciente sobre lift-and-shift

Migrações bem-sucedidas decidem desde o início: lift-and-shift é meio (para sair do datacenter rapidamente) ou destino?

Se meio, há plano explícito de refactoring com prazo e responsável. Aplicação X vai ser refeita em containers até dezembro/2026. Aplicação Y vai ser serverless até março/2027.

Se destino, ok — mas o cálculo de TCO precisa refletir lift-and-shift como permanente, sem prometer economia que vem só com refactoring.

2. FinOps desde o dia 1

Migrações bem-sucedidas têm prática FinOps desde antes da migração começar. Tags em todos os recursos. Alocação por área. Alertas configurados. Revisão semanal.

Migrações que falham implementam FinOps depois de 18 meses de estouro orçamentário, quando o dano já está feito.

3. Refactoring incremental

Não tente refatorar tudo de uma vez. Identifique os 3-5 workloads de maior custo e refatore eles primeiro. ROI rápido financia o próximo ciclo.

Empresas que tentam refatorar tudo simultaneamente raramente concluem.

4. Treinamento e mudança cultural

Cloud bem operado exige mentalidade diferente. "Servidor é caro, código é barato" em on-premise vira "servidor é barato, mas se ligado 24/7 é caro" em cloud. "Provisionar grande" vira "provisionar pequeno e ajustar".

Treinamento formal de equipe, hire de talento cloud-native, e mudança de processos internos são pré-requisitos para ROI real.

5. Governança executiva

Migrações que entregam ROI têm CFO e CIO/CTO juntos olhando os números mensalmente nos primeiros 24 meses. Não trimestralmente — mensalmente.

Sem essa governança, desvios acumulam silenciosamente.

ROI de migração cloud não é resultado da decisão de migrar. É resultado da disciplina depois de migrar. Migrar é fácil. Operar com ROI é o que separa as empresas que economizam das que pagam mais.

Repatriação: quando voltar é a melhor decisão

Repatriação é o movimento contrário: voltar workloads de cloud para on-premise ou colocation.

Era tabu falar disso. Não é mais. Várias empresas grandes (37Signals, Dropbox em parte) repatriam workloads onde cloud não compensa.

Quando avaliar repatriação:

Workload estável e previsível com custo cloud consistentemente alto
Aplicações que não foram refatoradas e operam em lift-and-shift caro
Bancos de dados grandes com I/O intensivo

Não é decisão simples. Tem custo de retorno. Mas para alguns workloads específicos, economia em 3-5 anos pode ser significativa.

A diferença entre migração que entrega ROI e migração que decepciona

Resumindo o que vi em mais de 30 migrações auditadas:

Migrações que entregam ROI compartilham 5 características:

Decisão consciente por workload (não migração em massa)
FinOps desde o dia 1
Plano de refactoring com prazo e orçamento
Treinamento intensivo da equipe
Governança executiva mensal

Migrações que decepcionam quase sempre falham em 3 ou mais desses pontos.

Não é sorte. É processo.

O caso especial de empresas reguladas

Empresas em setores fortemente regulados (financeiro, saúde, telecom) enfrentam camada adicional de complexidade em cloud.

Requisitos típicos:

Localização de dados em território nacional (alguns dados não podem sair do país)
Certificações específicas do fornecedor (SOC 2, ISO 27001, certificações setoriais)
Direito de auditoria do regulador sobre o fornecedor
Plano de continuidade aprovado pelo regulador
Notificação prévia ao regulador antes de migrações relevantes

Esses requisitos não impedem cloud. Mas impedem cloud feito sem cuidado.

Em setor regulado, ROI de migração precisa incluir custos de compliance contínuo, certificações que precisam ser mantidas, e overhead regulatório.

Quando bem feito, cloud em setor regulado entrega ROI positivo. Quando mal feito, vira fonte permanente de risco regulatório.

Em resumo: as 5 disciplinas que separam sucesso de fracasso

Decisão consciente sobre lift-and-shift (meio ou destino)
FinOps desde o dia 1, não depois do estouro
Refactoring incremental priorizado pelos workloads de maior custo
Treinamento intensivo e mudança cultural
Governança executiva mensal nos primeiros 24 meses

Migração que aplica essas 5 disciplinas tem alta probabilidade de entregar ROI. Migração que falha em 3 ou mais dificilmente entrega.

O que separa sucesso e fracasso em migração cloud não é tecnologia. É disciplina de execução pós-migração. E disciplina exige liderança que entende o jogo.

Indicadores de saúde de migração

Como saber se sua migração está no caminho certo? Indicadores chave:

Custo unitário (custo / transação processada) caindo trimestre a trimestre
Percentual de workloads em arquitetura cloud-native crescendo
Reservas/commitments aplicados em 60-80% do baseline
Recursos órfãos identificados e removidos mensalmente
Equipe interna ganhando certificações cloud (% certificado)

Migração saudável tem esses 5 indicadores tendendo na direção positiva ao longo dos primeiros 24 meses. Migração doente tem indicadores estagnados ou em direção contrária.

Monitorar esses indicadores mensalmente é mais valioso que olhar só a fatura mensal. Fatura é resultado. Indicadores são causa.

O fator humano: equipe pronta vs equipe forçada

Migração cloud falha frequentemente pelo lado humano, não tecnológico.

Sinais de equipe não pronta: resistência passiva, sabotagem velada, perda de talento sênior, retrabalho excessivo.

O que funciona:

Trazer equipe para a decisão desde o início, não comunicar depois
Investir em treinamento formal (não apenas "o pessoal vai aprendendo")
Reconhecer perdas (alguns conhecimentos viram obsoletos, é difícil aceitar)
Celebrar marcos para sustentar moral

Migração tecnológica é projeto humano. Equipe que abraça leva o sucesso. Equipe que resiste sabota silenciosamente.

Antes de qualquer movimento — ou se sua migração já aconteceu e o ROI não está vindo — vale a pena rodar a calculadora. Te dá um norte realista sobre o que esperar e onde concentrar esforço.

Veja também

Guia Completo

ROI de cloud: como calcular de verdade — não o que o fornecedor mostra na proposta

A proposta do fornecedor de cloud sempre mostra economia. O TCO real aparece 18 meses depois, quando as otimizações não aconteceram e os custos variáveis explodiram.

Como Implementar

Como apresentar ROI de migração cloud para o CFO — e conseguir aprovação

CTO quer migrar para cloud. CFO quer saber quando paga e quando economiza. A maioria das apresentações não responde isso. Veja como montar a que responde.

Perguntas frequentes

Por que a maioria das migrações cloud não entrega o ROI prometido?

As 5 causas mais frequentes: 1) Lift-and-shift sem otimização — mover o servidor para cloud sem refatorar é pagar por cloud ao custo de on-premise sem os benefícios. 2) Subestimar custos de egress e licenças. 3) Ausência de FinOps — sem governança de custo, a conta cresce 30-50% além do previsto no primeiro ano. 4) Migração sem app modernization — sistemas legados na cloud têm performance igual ao datacenter, com custo maior. 5) Escopo de migração maior que a capacidade do time.

Como evitar os erros mais comuns em migração cloud?

1) Faça um TCO honesto antes de começar — com egress, licenças, retrabalho. 2) Comece com workloads não-críticos para aprender antes de migrar o core. 3) Implante FinOps desde o dia 1 — not depois que a conta estourar. 4) Defina KPIs de sucesso antes da migração, não depois. 5) Planeje a saída — contratos de cloud sem estratégia de saída viram lock-in.

Quando faz sentido voltar do cloud para on-premise (cloud repatriation)?

Quando o custo total na cloud supera consistentemente o custo de on-premise por 2+ anos sem perspectiva de otimização. Casos comuns: workloads com uso previsível e alto (melhor amortizar hardware), aplicações com alto tráfego de egress, sistemas de armazenamento de dados frios em grande volume. Repatriação não é fracasso — é decisão financeira baseada em dados. O erro é não calcular o TCO real antes de migrar.

A causa #1 das migrações que falham: lift-and-shift sem refatoração

Padrão recorrente em migrações que estouram budget: empresa decide migrar tudo "lift-and-shift" — replicar a infraestrutura on-premises em servidores virtuais na cloud — sem refatoração das aplicações. Promete migração rápida e barata. Entrega o oposto.

O problema: aplicação projetada para infraestrutura tradicional não aproveita os benefícios de cloud. Custo de servidor virtual 24/7 frequentemente é maior que o custo de servidor físico equivalente on-premises. Não há ganho de elasticidade (a aplicação não escala dinamicamente). Não há ganho de resiliência (a arquitetura permanece monolítica). Custo total cresce, valor entregue não.

O que funciona: estratégia híbrida. Aplicações simples e estáveis seguem em lift-and-shift inicial. Aplicações críticas passam por refatoração antes ou durante a migração — adoção de serviços gerenciados, decomposição em microsserviços onde aplicável, automação de scaling, redesenho de armazenamento.

O esforço de refatoração varia: 20-80% do esforço da migração inicial. Mas é o que captura o valor real de cloud. Empresa que economiza no refatoramento paga depois — em custo recorrente maior do que o on-premises original.

A causa #2: governança financeira (FinOps) inexistente

Segunda causa estrutural de falha: ausência de governança financeira na operação cloud. Empresa migra, libera acesso aos times, e em 6 meses descobre que o custo dobrou em relação ao previsto.

Os mecanismos de desperdício são previsíveis: ambientes de desenvolvimento que ficam ligados 24/7 (deveriam desligar fora do horário comercial), recursos provisionados em tamanho excessivo (over-provisioning), storage acumulando sem expiração, ambientes esquecidos após projetos terminarem, escolhas de serviços caros quando alternativas mais baratas atenderiam.

FinOps é a prática de governança que mitiga isso. Componentes mínimos: indicadores mensais de custo por equipe/projeto; políticas automatizadas de tagging e enforcement; revisão trimestral de uso versus necessidade; rotina de identificação e desativação de recursos ociosos; treinamento de times de desenvolvimento sobre custo cloud.

Investimento típico em FinOps: 0,5-1,5 FTE dedicados + R$ 80-300 mil/ano em ferramentas. Retorno: redução típica de 15-30% no custo cloud — frequentemente paga o programa em poucos meses.

A causa #3: subestimar resistência cultural

Terceira causa, frequentemente ignorada: a migração para cloud não é apenas tecnológica — é cultural. Empresa que ignora esse fator tem times resistentes, projetos atrasados, qualidade comprometida.

A mudança cultural exigida: passar de operação reativa (servidor falhou? Cria chamado) para operação ativa (monitoramento, automação, prevenção); passar de planejamento de capacidade anual para gestão contínua; passar de aquisição de hardware via processo formal para provisionamento self-service; passar de operação isolada por equipe para colaboração entre dev, ops e segurança (DevSecOps).

Mudança cultural leva tempo. Tipicamente 18-36 meses para empresa de médio porte transitar plenamente. Empresa que tenta forçar em 6 meses gera atrito, perdas de talento, qualidade reduzida.

O que funciona: investimento sustentado em treinamento; estrutura organizacional que reconhece os papéis novos (SREs, engenheiros de plataforma, especialistas em cloud); modelo de evolução gradual com piloto, expansão, generalização; comunicação clara das expectativas; reconhecimento do esforço de adaptação.

Investimento típico em mudança cultural: R$ 300-800 mil/ano em treinamento e desenvolvimento, ao longo de 24-36 meses. Retorno: time de fato capacitado, sem rotatividade catastrófica.