Quero migrar para a nuvem
Resposta rápida
Migrar para a nuvem não é projeto único — é portfólio de decisões por sistema. Comece por inventariar todas as cargas de trabalho atuais (servidores, aplicações, bancos, arquivos) e classifique cada uma por uma das seis estratégias: rehost (lift-and-shift), replatform, refactor, repurchase (trocar por SaaS), retire (descomissionar) ou retain (manter on-premises por motivo justificado). Defina o provedor principal com base em ecossistema da empresa, custo realista e disponibilidade local, monte governança pós-migração antes de migrar (FinOps, segurança, identidade) e capacite a equipe. Cuidado com a promessa de economia automática: cloud mal governada custa mais que data center próprio em poucos meses. O ganho vem de elasticidade, velocidade e modernização, não de mensalidade baixa.
Na empresa pequena, "migrar para nuvem" geralmente significa adotar SaaS para o que dá (ERP vertical, e-mail, colaboração, CRM) e usar IaaS apenas para cargas específicas que não cabem em SaaS. A estratégia dominante é repurchase — trocar sistema próprio por solução em assinatura. O projeto é conduzido pelo MSP ou por consultoria pontual, em ondas curtas. Foco em poucas decisões: provedor de identidade único, política de backup que cubra o que está em SaaS (a maioria não tem backup nativo decente), e controle de acesso. O risco maior é assinar SaaS sem governança e descobrir trinta licenças órfãs daqui a dois anos, custando mensalmente sem uso.
Na empresa média, migração para nuvem vira projeto formal com mistura das seis estratégias. Sistemas legados modernizáveis vão para replatform (migrar e adaptar minimamente), aplicações críticas que justificam refactor entram em fila própria, e cargas commodity vão por lift-and-shift. Antes de migrar, monte governança de cloud: equipe de FinOps mesmo que pequena (uma pessoa cuidando de custo), política de tagging, identidade centralizada, segurança em camadas. Espere doze a vinte e quatro meses para a migração principal. O risco maior é tratar como projeto técnico: cloud bem feita exige mudança de operação, capacitação do time e revisão de processo. Sem isso, é só trocar data center pelo aluguel.
Na empresa grande, migração para nuvem é programa plurianual com sponsor executivo, escritório de projeto dedicado, comitê com áreas de negócio e parceiros estratégicos. A discussão multi-cloud aparece com força: um provedor principal para grosso das cargas e provedores secundários para serviços específicos ou redundância. Governança é pilar central: FinOps com equipe dedicada, landing zones por unidade de negócio, identidade federada, segurança zero-trust, processo formal de provisionamento. Espere três a cinco anos para migração ampla. O risco é dois lados: mover por mover (custo explode sem ganho de modernização) ou paralisia (estudar por anos sem migrar nada).
- O parque de servidores está envelhecendo e a renovação custa caro
- Picos de demanda derrubam sistema ou exigem superprovisionamento permanente
- A operação precisa de mais agilidade do que o data center entrega
- Novos sistemas adquiridos só funcionam bem em ambiente cloud
- Segurança e conformidade pedem capacidades que o on-premises não tem
- A diretoria pergunta sobre cloud e ninguém tem plano consolidado
As seis estratégias de migração — e quando cada uma serve
Migração para cloud não é uma decisão única; é uma decisão por carga de trabalho. O quadro mais usado descreve seis estratégias. Rehost (lift-and-shift) move a aplicação como está para a nuvem, rápido e barato no projeto, mas sem ganho de modernização. Replatform move com pequenas adaptações (trocar banco para serviço gerenciado, por exemplo) — equilíbrio entre rapidez e modernização. Refactor reescreve a aplicação para arquitetura cloud nativa — caro e longo, justificado quando o sistema é estratégico e estará na empresa por muitos anos. Repurchase substitui por SaaS — válido quando há solução de mercado madura. Retire descomissiona o que não é mais necessário. Retain mantém on-premises por motivo justificado (latência, regulação, custo).
O trabalho central é classificar cada carga em uma das seis. A maioria das empresas distribui: 20-40% em rehost, 20-30% em replatform, 5-15% em refactor, 10-20% em repurchase, 5-10% em retire, 5-15% em retain. Não existe migração 100% refactor — vira projeto que nunca termina.
Escolha do provedor principal
A escolha entre AWS, Azure, Google Cloud e provedores nacionais (ou regionais) depende de quatro fatores. Ecossistema atual da empresa: se Microsoft é padrão, Azure tende a ter integração mais barata. Maturidade local: presença em região brasileira, suporte em português, parceiros disponíveis. Custo realista comparado: cotação por carga de trabalho, não por preço de lista. Disponibilidade de talento: equipe própria e parceiros que dominem o ecossistema. Multi-cloud é tendência crescente, mas para a maioria das empresas começar com um provedor principal é mais barato e mais simples. Adote o segundo provedor quando houver razão específica (serviço único, redundância exigida, política de risco).
O custo real raramente é o que aparece na calculadora
Calculadoras de provedor mostram preço de lista por serviço, sem considerar comportamento real da operação. O custo realista soma seis componentes. Compute e storage com curva de uso real (não pico estimado). Egress de dados (saída de dados costuma ser cara). Backup, snapshots e arquivamento. Licenças (sistema operacional, banco de dados, software). Serviços gerenciados (que aceleram, mas custam). Capacidade da equipe (interna ou de parceiro) para operar. Antes de migrar, faça benchmark de três meses com cargas reais — não confie em estimativa de calculadora.
- Inventário das cargas de trabalho. Todos os servidores, aplicações, bancos, arquivos, com dependência, criticidade e dono de negócio.
- Classificação pelas seis estratégias. Cada carga recebe uma das opções (rehost, replatform, refactor, repurchase, retire, retain) com justificativa.
- Escolha do provedor e da arquitetura base. Provedor principal, landing zone, identidade, rede, segurança, observabilidade — antes de migrar a primeira carga.
- Onda piloto. Três a cinco cargas representativas migradas com tempo e custo medidos. Aprendizado vai para o playbook.
- Migração em ondas. Por bloco de risco e dependência, com critério de aceitação claro e rollback testado em cada onda.
- Governança pós-migração. FinOps, segurança, conformidade e operação ajustadas ao novo ambiente — em paralelo, não depois.
Equipe e operação na nova realidade
Cloud muda como TI opera. Perfis tradicionais (administradores de sistema, DBAs, rede) precisam evoluir para perfis cloud — engenheiro de plataforma, SRE, segurança em nuvem, FinOps. Algumas mudanças são incrementais (treinamento e certificação), outras exigem contratação ou parceiro. Subestimar essa transição é causa frequente de cloud mal operada: ferramenta nova, prática antiga. Planeje capacitação como parte do projeto, com tempo dedicado e metas de certificação, não como tarefa extra para a equipe atual.
Migrar sem governança de custo. Fatura cresce, recursos órfãos se acumulam, time perde a métrica e a economia esperada vira despesa maior. FinOps começa antes da primeira carga migrada.
Lift-and-shift como solução única. Mover tudo como está é rápido, mas perde quase todos os ganhos de cloud. Sem replatform e repurchase no mix, a empresa só trocou de data center.
Refactor sem critério. Reescrever tudo para cloud nativo é caro, longo e nem sempre vale. Limite refactor a sistemas estratégicos com vida longa garantida.
Subestimar mudança de operação. Cloud sem time capacitado em FinOps, segurança e plataforma vira caos caro. Treinamento e parceiros são parte do projeto.
Não testar rollback. Migração que assume sucesso garantido é frágil. Cada onda precisa de plano de retorno testado antes de cortar o on-premises original.
- Inventário completo de cargas com classificação pelas seis estratégias
- Provedor principal escolhido com justificativa multicritério
- Landing zone, identidade, rede e segurança base configurados
- Governança de FinOps com responsável e processo de revisão de custo
- Benchmark de custo com cargas reais (não estimativa de calculadora)
- Capacitação da equipe planejada com tempo e metas explícitas
- Rollback testado para a onda piloto
- Critérios de aceitação claros por carga migrada