Migração para nuvem é uma das decisões de infraestrutura com maior impacto financeiro e operacional de uma empresa. As seções abaixo trazem as seis estratégias reais de migração, bem como os custos ocultos que derrubam projetos e um roteiro de execução para quem precisa justificar cada etapa ao conselho.
Resumo
- Empresas que pulam o discovery antes da migração gastam, em média, 30% a mais no projeto final por retrabalho e dependências não mapeadas.
- A escolha da estratégia de migração (lift-and-shift, replatform ou refactor) define, portanto, o custo nos próximos três anos, além do impacto no projeto inicial.
- Governança de custos e gestão de identidade precisam, assim, estar prontas antes do primeiro workload migrado, não depois.
Introdução
Migração para nuvem deixou de ser projeto de TI e virou decisão de conselho. Empresas brasileiras de médio e grande porte enfrentam pressão dupla: reduzir custo de infraestrutura legada e ganhar velocidade para lançar produtos digitais. A nuvem resolve os dois problemas, mas só quando o projeto é conduzido com método.
O mercado global de cloud cresceu 22% em 2025 e deve manter ritmo semelhante até 2028, conforme projeções de analistas do setor. No Brasil, o avanço na digitalização acelerou esse ciclo. CIOs que adiaram a decisão nos últimos dois anos agora competem com rivais que já operam com custo variável e escala sob demanda.
O problema não é, aliás, a tecnologia. A maioria dos projetos que fracassa, fracassa por falta de planejamento, por escolha errada de estratégia ou por ausência de governança desde o início. As seções a seguir cobrem, então, cada um desses pontos.
As seis estratégias de migração para nuvem
A escolha da estratégia define o custo total de propriedade por anos. Não existe opção universalmente correta: cada workload pede uma abordagem. O modelo dos 6 Rs, consolidado por grandes provedores, organiza as opções de forma objetiva.
As seis estratégias são:
- Rehost (lift-and-shift): move a aplicação sem alterar código. É o caminho mais rápido, mas não entrega o melhor custo no longo prazo.
- Replatform: faz ajustes pontuais para aproveitar serviços gerenciados, como trocar banco de dados próprio por RDS. Equilibra velocidade e ganho operacional.
- Refactor (re-architect): reconstrói a aplicação para arquitetura nativa de nuvem. Exige mais tempo e custo inicial, contudo, entrega o maior ganho em escala e resiliência.
- Repurchase: abandona o sistema legado e adota um SaaS equivalente. Funciona bem para ERP, CRM e ferramentas de colaboração.
- Retain: mantém o workload on-premises por razão regulatória, latência ou custo. Nem tudo precisa migrar.
- Retire: desliga sistemas que não têm mais uso real. Empresas descobrem, em média, que 10% a 20% dos workloads mapeados se enquadram aqui.
A IBM documenta essas estratégias com profundidade em seu guia sobre os 7 Rs da migração para nuvem, que inclui uma sétima opção para casos de relocação física entre datacenters. Para a maioria das empresas brasileiras, os seis acima cobrem o cenário.
Etapas da migração para nuvem: o que o projeto precisa ter
Projetos bem-sucedidos seguem uma sequência clara. A ordem importa porque cada fase cria a base para a próxima. Pular etapas gera retrabalho caro.
Discovery e inventário de workloads
O discovery mapeia cada aplicação, sua dependência, seu consumo de recursos e seu nível de criticidade. Empresas que pulam essa fase, por pressão de prazo, gastam em média 30% a mais no projeto final. O motivo é simples: dependências ocultas entre sistemas causam falhas em produção logo após a migração.
Ferramentas como AWS Migration Hub, Azure Migrate e Google Cloud Rapid Assessment automatizam parte do inventário. Ainda assim, a análise de dependências entre aplicações exige revisão humana, pois ferramentas automatizadas não capturam integrações por arquivo, FTP ou chamadas diretas a banco de dados.
Definição da landing zone
A landing zone é a estrutura de contas, redes, identidade e políticas que recebe os workloads migrados. Configurar a landing zone depois da migração é, certamente, o erro mais caro que uma equipe pode cometer. O retrabalho de segurança e rede em ambiente já populado chega, de fato, a consumir 40% do orçamento original do projeto.
Uma landing zone bem construída define hierarquia de contas, zonas de rede, políticas de IAM, bem como controles de custo antes do primeiro servidor migrado. A governança de custos em nuvem começa aqui, não depois.
Migração em ondas
A migração em ondas divide os workloads em grupos por criticidade e complexidade. A primeira onda testa o processo com sistemas de baixo risco. As ondas seguintes, assim, migram sistemas críticos já com lições aprendidas.
Cada onda precisa de critério de sucesso definido antes de começar: tempo de resposta, disponibilidade, custo por hora de computação. Sem métrica, a equipe, portanto, não sabe quando a onda terminou com qualidade.
Validação e cutover
O cutover é a virada do tráfego de produção para a nuvem. A validação antes do cutover testa, sobretudo, performance, failover e integrações. O plano de rollback precisa estar documentado e testado, pois um cutover mal executado em sistema crítico pode custar horas de indisponibilidade e multa contratual.
Custos reais da migração para nuvem
O custo de migração para nuvem tem três camadas. A maioria dos orçamentos captura só a primeira.
A primeira camada cobre o projeto de migração em si: consultoria, ferramentas, horas de engenharia e treinamento. Para uma empresa com 200 a 500 servidores, esse custo varia entre R$ 800 mil e R$ 3 milhões, conforme a complexidade das aplicações e a estratégia escolhida.
A segunda camada é o custo de operação em nuvem no primeiro ano. Empresas que migram sem otimização de instâncias pagam, em média, 35% a mais do que o necessário. O motivo é, aliás, que o lift-and-shift replica o superdimensionamento do ambiente on-premises. Instâncias reservadas e Savings Plans cortam esse custo, mas exigem compromisso de um a três anos.
A terceira camada é o custo de egresso de dados. Provedores cobram pela saída de dados da nuvem para a internet ou para outro provedor. Em workloads de analytics com grandes volumes, esse custo pode, de fato, representar 15% a 25% da fatura mensal. Poucos projetos mapeiam isso no orçamento inicial.
Para entender o modelo de precificação de instâncias antes de fechar o orçamento, vale analisar como justificar cada centavo no EC2 da AWS, que detalha as opções de compra e os cenários de uso de cada uma.
Riscos da migração para nuvem e como mitigá-los
Todo projeto de migração carrega riscos. Conhecê-los antes é o que separa um projeto controlado de uma crise.
Os principais riscos são:
- Dependências não mapeadas: sistemas que se comunicam por caminhos não documentados falham silenciosamente após a migração. A mitigação é um discovery rigoroso com análise de tráfego de rede.
- Subestimação do tempo de refactor: aplicações legadas com código de 10 a 20 anos exigem mais trabalho do que o estimado. O risco aumenta, geralmente, quando a empresa não tem documentação técnica atualizada.
- Falha de segurança na configuração: buckets de armazenamento abertos, políticas de IAM permissivas e grupos de segurança mal configurados são as causas mais comuns de incidentes em nuvem. Segundo a McKinsey, erros de configuração respondem por mais de 60% dos incidentes de segurança em cloud.
- Ausência de plano de rollback: sem um plano testado, a equipe improvisa durante a crise. O improviso em produção sempre custa, certamente, mais do que o planejamento.
- Lock-in de provedor: arquiteturas que usam serviços proprietários sem abstração criam dependência difícil de reverter. A mitigação não é evitar serviços gerenciados, porém documentar as dependências e manter portabilidade nos dados.
A alta disponibilidade em infraestrutura de TI precisa ser projetada desde o início da arquitetura em nuvem, porque ajustar depois eleva o custo e a complexidade.
Como escolher o provedor e o parceiro de migração
AWS, Azure e Google Cloud dominam o mercado, contudo, a escolha do provedor depende do portfólio de aplicações da empresa, não da preferência do time de TI. Empresas com stack Microsoft se beneficiam de licenciamento híbrido no Azure. Empresas com foco em analytics e machine learning encontram mais profundidade no Google Cloud. A AWS lidera em amplitude de serviços e maturidade do ecossistema de parceiros.
O parceiro de migração, certamente, tem impacto direto no resultado. Um parceiro certificado reduz o tempo de projeto e antecipa problemas que uma equipe interna sem experiência prévia descobriria em produção. A escolha do parceiro certo para a migração merece tanta atenção quanto a escolha do provedor.
Critérios objetivos para avaliar parceiros incluem: número de certificações técnicas ativas, casos documentados no setor da empresa e modelo de suporte pós-migração. Parceiros que só entregam o projeto e saem deixam a equipe interna sem apoio no momento mais crítico, que é o primeiro mês de operação em produção.
A Microsoft detalha os conceitos e estratégias do processo em seu dicionário de migração para nuvem, útil para alinhar vocabulário entre equipes técnicas e executivas durante o projeto.
Benefícios da migração para nuvem além da redução de custo
Redução de custo é o argumento mais usado para justificar a migração. Entretanto, o ganho financeiro real aparece no segundo e no terceiro ano, não no primeiro. O primeiro ano costuma ser mais caro do que o ambiente on-premises, porque a empresa paga pelos dois ambientes em paralelo durante a transição.
Os benefícios que mudam a competitividade da empresa são outros. Velocidade de provisionamento cai de semanas para minutos. Equipes de desenvolvimento lançam ambientes de teste sem abrir chamado para infraestrutura. O time de produto acelera o ciclo de entrega.
Resiliência é outro ganho real. Provedores como AWS e Azure oferecem SLA de 99,99% em serviços gerenciados, com replicação entre zonas de disponibilidade. Replicar esse nível em datacenter próprio exige, sobretudo, investimento que pouquíssimas empresas conseguem justificar.
A supercomputação em nuvem abre acesso a capacidade de processamento que antes era exclusiva de grandes corporações. Empresas médias já usam instâncias de GPU sob demanda para treinar modelos de IA sem comprar hardware.
A McKinsey estima que empresas que executam a migração com método capturam 20% a 30% de redução no custo total de TI em três anos, além de ganhos de produtividade que superam o benefício financeiro direto. O estudo completo está disponível no guia da McKinsey sobre transformação cloud em seis meses.
Conclusão
Migração para nuvem não é um projeto de infraestrutura. É uma decisão estratégica que redefine custo, velocidade e capacidade competitiva da empresa pelos próximos cinco anos.
O CIO que conduz o projeto com discovery rigoroso, estratégia de migração por workload e governança desde o início entrega resultado mensurável ao conselho. O que falha não é a tecnologia, porém o planejamento.
O passo seguinte é concreto: mapear os workloads atuais, classificar por criticidade e escolher a estratégia certa para cada um. A primeira onda de migração, já que é a menor e a mais controlada, valida o processo para as ondas seguintes. Quem começa com método, logo, não precisa refazer.
Perguntas frequentes
Quanto tempo leva uma migração para nuvem em uma empresa de médio porte?
Uma empresa com 100 a 300 servidores leva, em média, de 6 a 18 meses para concluir a migração completa. O prazo varia conforme a complexidade das aplicações, o nível de documentação existente e a estratégia escolhida. Projetos que adotam lift-and-shift para a maioria dos workloads concluem, geralmente, mais rápido. Projetos com refactor de sistemas legados levam mais tempo, pois o redesenho de arquitetura exige ciclos de desenvolvimento.
É possível migrar para a nuvem sem interromper as operações?
Sim, embora exija planejamento detalhado. A abordagem mais comum usa replicação contínua de dados e cutover em janela de manutenção. Ferramentas como AWS Database Migration Service e Azure Site Recovery permitem, de fato, migrar workloads com tempo de indisponibilidade inferior a 30 minutos em muitos cenários. Sistemas com arquitetura monolítica e alto volume de transações exigem mais cuidado e, às vezes, refactor parcial antes do cutover.
Quais workloads não devem migrar para a nuvem?
Sistemas com requisitos de latência abaixo de 1 milissegundo, como controle industrial em tempo real, costumam permanecer on-premises ou em edge computing. Aplicações com restrição regulatória de soberania de dados, aliás, também podem exigir nuvem privada ou modelo híbrido. A decisão de reter um workload é tão estratégica quanto a de migrá-lo: o objetivo é, portanto, o melhor custo e desempenho para cada carga, não migrar tudo a qualquer custo.
Como justificar o custo da migração para nuvem ao conselho?
O argumento mais sólido combina três métricas: redução de custo de infraestrutura em três anos, ganho de velocidade de entrega de produto e redução de risco operacional. Empresas que apresentam só o custo do projeto, geralmente, perdem o argumento. Apresentar o custo de não migrar, como renovação de licença, manutenção de hardware e risco de indisponibilidade, muda, por conseguinte, o enquadramento da decisão para o conselho.