Migração para cloud computing deixou de ser projeto de futuro e virou pressão de conselho. As seções abaixo entregam um roteiro de decisão com custos reais, os modelos de migração comparados e os riscos que derrubam projetos antes do go-live.
Resumo
- A escolha entre lift-and-shift e re-architecting define o custo e o prazo da migração, e a maioria das empresas subestima o segundo.
- Governança de custos e compliance com a LGPD precisam, principalmente, entrar no projeto antes da primeira carga de trabalho subir para a nuvem.
- ROI mensurável aparece entre 12 e 18 meses quando a empresa define métricas de baseline antes de migrar.
Introdução
Migração para cloud computing responde hoje por mais de 60% do orçamento de infraestrutura das grandes empresas brasileiras, de acordo com o levantamento da IDC de 2026. O mercado de nuvem no Brasil deve fechar 2026, aliás, em R$ 28 bilhões, crescimento de 22% sobre o ano anterior. Quem ainda planeja a primeira migração, portanto, compete com pares que já estão na segunda ou terceira onda.
O problema não é falta de vontade. É que a maioria dos projetos começa pelo provedor e termina no custo surpresa. A fatura do primeiro trimestre em nuvem costuma ser 35% maior do que o projetado, pois as equipes não mapeiam o consumo real antes de migrar.
A boa notícia: projetos que seguem um roteiro estruturado entregam redução de 25% a 40% no custo de infraestrutura em dois anos. A má notícia é que esse roteiro exige disciplina antes, durante e sobretudo depois da migração, não só no dia do corte.
Por que a migração para cloud computing falha antes de começar
O erro mais caro acontece na fase de descoberta. Empresas sobem para a nuvem cargas de trabalho que não foram mapeadas, com dependências ocultas e licenças que não seguem o modelo cloud. O resultado, por conseguinte, é retrabalho que consome de 20% a 30% do orçamento original.
Três falhas concentram a maioria dos projetos que não entregam o ROI prometido:
- Ausência de inventário completo: aplicações legadas com dependências não documentadas criam surpresas no corte.
- Licenças incompatíveis com cloud: softwares de ERP e banco de dados têm cláusulas que proíbem ou encarecem o uso em infraestrutura de terceiros.
- Falta de baseline de desempenho: sem métricas do ambiente atual, a empresa não consegue, por isso, provar o ROI depois da migração.
A fase de descoberta precisa de quatro a seis semanas e deve produzir um mapa de dependências, um inventário de licenças e um relatório de baseline. Pular essa etapa, contudo, economiza tempo no papel e custa o dobro na execução.
Os modelos de migração para cloud e o que cada um custa de verdade
A framework dos 7 R’s da IBM organiza as opções de migração em sete estratégias. Na prática corporativa brasileira, entretanto, três concentram mais de 85% dos projetos.
Lift-and-shift: velocidade com custo escondido
O lift-and-shift move a aplicação para a nuvem sem alterar o código. A migração é rápida, de quatro a doze semanas por bloco de aplicações. O custo inicial é baixo porque não exige desenvolvimento.
O trade-off aparece na fatura mensal. Aplicações não otimizadas para nuvem consomem de 40% a 60% mais recursos do que o necessário, pois foram projetadas para servidores físicos com capacidade reservada. O custo de operação em dois anos, ainda assim, supera o de uma migração mais profunda.
Lift-and-shift faz sentido quando a empresa precisa sair de um data center com contrato vencendo ou quando a aplicação será descontinuada em menos de 18 meses.
Re-platforming: o equilíbrio que poucos calculam
O re-platforming ajusta a aplicação para usar serviços gerenciados da nuvem, como banco de dados PaaS ou filas de mensagem nativas. Não reescreve o código de negócio, mas troca a camada de infraestrutura.
O custo de execução é de 30% a 50% maior do que o lift-and-shift. O ganho operacional, porém, aparece já no sexto mês: redução de 20% a 35% na fatura de computação, pois o serviço gerenciado escala conforme a demanda real.
Re-architecting: o investimento que gera vantagem competitiva
O re-architecting reescreve a aplicação para arquitetura nativa de nuvem, com microsserviços, containers e escalabilidade automática. O custo de desenvolvimento é alto, de seis a dezoito meses por sistema crítico.
O retorno, todavia, é o único que entrega vantagem competitiva de longo prazo. Empresas que re-arquitetaram seus sistemas core, com efeito, reportam redução de 50% a 70% no custo de infraestrutura e tempo de entrega de novas funcionalidades três vezes menor. Esse modelo vale para sistemas que vão crescer e que diferenciam o negócio.
Para entender como cada modelo impacta a escolha do parceiro de execução, veja como escolher o parceiro certo para sua jornada cloud.
Custo de migração para cloud computing: o que entra na conta real
O orçamento de migração tem três camadas. A maioria das propostas comerciais, no entanto, cobre apenas a primeira.
Os componentes que compõem o custo total de migração são:
- Custo de execução: horas de engenharia, ferramentas de migração e testes. Representa de 40% a 50% do total.
- Custo de operação paralela: período em que a empresa paga o data center antigo e a nuvem ao mesmo tempo. Dura de dois a quatro meses e representa de 20% a 30% do total.
- Custo de otimização pós-migração: ajustes de sizing, revisão de licenças e treinamento de equipes. Representa de 20% a 30% do total e quase nunca entra na proposta inicial.
Uma migração de porte médio, com 50 a 150 cargas de trabalho, custa entre R$ 800 mil e R$ 3 milhões no Brasil em 2026, de acordo com dados de mercado. Projetos sem governança de custos desde o início estouraram, de fato, 50% acima do orçamento em 40% dos casos registrados pela Gartner no último ciclo.
A estratégia de migração inteligente da Gartner recomenda, sobretudo, definir um teto de gasto por carga de trabalho antes de migrar. Sem esse teto, a equipe não tem critério para escolher o modelo certo por aplicação.
Depois da migração, a governança de custos precisa continuar ativa. O artigo sobre governança de custos em nuvem, aliás, detalha os controles que evitam que a fatura cresça mês a mês sem explicação.
Segurança e LGPD na migração de dados para nuvem
Compliance não é etapa final. Empresas que deixam LGPD e segurança para depois do go-live precisam refazer a arquitetura de dados, o que, em razão disso, custa de duas a quatro vezes mais do que projetar certo desde o início.
O que a LGPD exige na migração de dados para nuvem
A LGPD não proíbe armazenar dados pessoais em nuvem. Ela exige que a empresa saiba onde cada dado está, quem acessa e por quanto tempo fica retido. A migração para nuvem, portanto, é uma oportunidade para mapear e classificar dados, já que o inventário de cargas de trabalho já precisa acontecer.
Os provedores principais, AWS, Azure e GCP, oferecem, aliás, regiões de dados no Brasil. Manter dados sensíveis em região brasileira reduz o risco regulatório e simplifica a resposta a auditorias da ANPD.
Controles de segurança que precisam entrar no projeto
Quatro controles são inegavelmente obrigatórios em qualquer migração corporativa:
- Criptografia em trânsito e em repouso: padrão mínimo para dados classificados como sensíveis ou pessoais.
- Gestão de identidade e acesso (IAM): cada serviço na nuvem precisa de uma identidade própria, com permissão mínima necessária.
- Monitoramento de eventos de segurança: logs centralizados com alertas automáticos para acessos fora do padrão.
- Plano de resposta a incidentes: testado antes do go-live, não depois do primeiro incidente.
A IBM descreve segurança como camada zero da migração, não como add-on. Projetos que tratam segurança como add-on gastam, de fato, em média 60% a mais em correções no primeiro ano de operação.
Como estruturar a estratégia de migração para cloud em cinco etapas
Um roteiro claro reduz o risco de retrabalho e dá ao conselho a visibilidade que ele precisa para aprovar o investimento. Assim, as cinco etapas abaixo cobrem do diagnóstico ao steady state.
- Descoberta e inventário: mapeie todas as cargas de trabalho, dependências e licenças. Produza o baseline de desempenho e custo atual. Prazo: quatro a seis semanas.
- Classificação e priorização: defina o modelo de migração por aplicação. Priorize cargas de menor risco e maior ganho para as primeiras ondas. Prazo: duas a três semanas.
- Prova de conceito: migre duas ou três aplicações não críticas para validar ferramentas, processos e equipe. Prazo: quatro a oito semanas.
- Migração em ondas: execute em blocos de quatro a oito semanas, com critério de go/no-go antes de cada onda. Mantenha, de qualquer forma, o ambiente legado ativo até a validação completa.
- Otimização e governança: ajuste sizing, revise reservas de capacidade e implante governança de custos. Prazo contínuo a partir do primeiro mês de operação.
Para um detalhamento do roteiro de decisão antes de iniciar o projeto, o artigo sobre migração para nuvem para CIOs traz os critérios de priorização por tipo de carga de trabalho.
Como escolher entre AWS, Azure e GCP na migração para cloud
A escolha do provedor impacta custo, suporte e capacidade de integração por anos. Três critérios objetivos guiam a decisão melhor do que qualquer ranking de analistas.
O primeiro critério é o portfólio de serviços gerenciados que a empresa vai usar. AWS lidera em variedade e maturidade de serviços, com mais de 240 serviços disponíveis. Azure tem vantagem clara para empresas com licenças Microsoft ativas, porque o Azure Hybrid Benefit reduz o custo de migração de Windows Server e SQL Server em até 40%. GCP se diferencia em cargas de dados e machine learning, com preços de computação em geral 10% a 15% abaixo dos concorrentes em workloads de análise.
O segundo critério é a presença de parceiros certificados no Brasil. A qualidade do suporte local, sobretudo, define o tempo de resolução de incidentes críticos. Empresas que escolhem provedor sem avaliar o ecossistema de parceiros locais pagam mais caro em sustentação.
O terceiro critério é o modelo de precificação conforme o perfil de consumo da empresa. Cargas estáveis se beneficiam de instâncias reservadas, com desconto de 30% a 60% sobre o preço sob demanda. Cargas variáveis funcionam melhor com spot ou preemptible instances, com desconto de até 80%, mas com risco de interrupção.
A documentação oficial do Azure Migration Hub e os guias equivalentes de AWS e GCP oferecem, ademais, calculadoras de custo que permitem comparar cenários antes de assinar qualquer contrato.
Para cargas que rodam em EC2 na AWS, o artigo sobre EC2 AWS detalha como justificar cada tipo de instância para o conselho financeiro.
Conclusão
Migração para cloud computing bem executada entrega redução de custo, velocidade de entrega e capacidade de escala. Mal executada, contudo, entrega fatura crescente e retrabalho que consome o time por meses.
A diferença está em três decisões: fazer o inventário antes de subir qualquer carga, escolher o modelo de migração por aplicação e não por conveniência, e implantar governança de custos desde o primeiro dia em nuvem.
O CIO que apresenta ao conselho um roteiro com baseline, teto de gasto por onda e critério de go/no-go tem muito mais chance de aprovação do que quem apresenta só a promessa de redução de custo. Conselho aprova projeto, principalmente, com número, prazo e critério de sucesso, não com narrativa.
A integração dos sistemas migrados com o restante da operação é, igualmente, o próximo desafio. O artigo sobre integração de sistemas mostra o que separa empresas que escalam das que travam depois da migração.
Perguntas frequentes
Quanto tempo leva uma migração para cloud computing de porte médio?
Uma migração de 50 a 150 cargas de trabalho leva de seis a dezoito meses, conforme a complexidade das aplicações e o modelo escolhido. Lift-and-shift é mais rápido, de quatro a doze semanas por bloco. Re-architecting de sistemas críticos pode levar de seis a dezoito meses por sistema. O prazo total depende, igualmente, do tamanho da equipe e da qualidade do inventário inicial.
Como calcular o ROI da migração para cloud computing?
O ROI começa com o baseline: custo atual de infraestrutura, custo de manutenção, custo de licenças e horas de operação. Depois da migração, a empresa compara esses números com a fatura de nuvem mais os custos de suporte. Projetos com baseline bem documentado, com efeito, reportam ROI positivo entre 12 e 18 meses. Sem baseline, a empresa não consegue provar o retorno, mesmo quando ele existe.
A migração de dados para nuvem viola a LGPD?
A migração de dados para nuvem não viola a LGPD por si mesma. A lei exige que a empresa saiba onde os dados estão, quem acessa e por quanto tempo ficam retidos. Provedores como AWS, Azure e GCP têm, certamente, regiões no Brasil e oferecem contratos de processamento de dados alinhados à LGPD. O risco de violação, dessa forma, surge quando a empresa migra sem classificar os dados e sem definir controles de acesso, não pela nuvem em si.
Qual é a diferença entre migração lift-and-shift e re-architecting?
Lift-and-shift move a aplicação para a nuvem sem alterar o código. É rápido e barato na execução, contudo mantém o custo operacional alto porque a aplicação não foi otimizada para nuvem. Re-architecting reescreve a aplicação para usar serviços nativos de nuvem, com escalabilidade automática e custo proporcional ao uso real. O custo de execução é maior, mas o custo de operação em dois anos é de 50% a 70% menor. A escolha certa, portanto, depende do ciclo de vida da aplicação e do quanto ela diferencia o negócio.