Migrar para o Google Cloud é, antes de tudo, uma decisão de risco e de custo, e só depois uma decisão técnica. Empresas que começam pela tecnologia costumam gastar meses escolhendo serviço e descobrem tarde que não sabiam quantos servidores tinham, de quem eram os bancos de dados nem quanto custava manter tudo aquilo.
O assunto ganhou urgência no Brasil. Em setembro, durante o Google Cloud Summit Brasil 2026, o Google anunciou que vai dobrar até 2030 a capacidade de computação da sua nuvem no país, e que a versão web do Gemini Enterprise passa a processar dados localmente com o Gemini 3.5 Flash a partir de 15 de outubro, segundo o MobileTime. Para quem ainda roda em servidor próprio, data center alugado ou hospedagem tradicional, a pergunta prática é como chegar lá sem parar a operação. Este guia responde com as fases, as estratégias, as ferramentas e os cuidados de custo.
Quando migrar para o Google Cloud faz sentido
Nem toda empresa precisa estar na nuvem, e quem diz o contrário está vendendo algo. Na minha leitura, a migração se justifica quando pelo menos um destes sinais aparece:
- Hardware chegando ao fim da vida útil ou contrato de data center perto de vencer, o que força um investimento de qualquer jeito.
- Picos de demanda que obrigam a comprar capacidade para o pior dia do ano e deixá-la ociosa o resto do tempo.
- Dados espalhados em planilhas, sistemas legados e ferramentas que não conversam, o que impede análise séria e uso de IA.
- Exigências de disponibilidade, backup e segurança que a equipe interna não consegue cumprir sozinha.
- Necessidade de IA e analytics em escala, onde serviços como BigQuery e os modelos Gemini já estão prontos para usar.
Do outro lado, uma aplicação pequena e estável, com custo fixo baixo e sem previsão de crescimento, raramente paga o esforço de uma migração. Migrar por moda é o caminho mais curto para uma conta mensal maior sem nenhum ganho visível.
As quatro fases de uma migração para o Google Cloud
O próprio Google organiza a jornada em quatro fases no seu guia oficial de migração. A ordem importa, e pular a primeira é o erro mais caro do processo.
1. Assess: avaliar o ambiente atual
É a descoberta. Você faz o inventário de servidores, bancos de dados, aplicações e dependências entre eles, e mede o consumo real de cada um. O objetivo é responder três perguntas: o que existe, o que está em uso e o que depende de quê. O Migration Center automatiza boa parte disso, com varredura do ambiente, relatório de custo total de propriedade e mapa de dependências, tudo sem alterar as aplicações.
2. Plan: montar a base na nuvem
Antes de mover qualquer carga, é preciso construir o terreno: estrutura de contas e projetos, rede, identidade e acesso, políticas de segurança e controle de custos. É a fase menos vistosa e a que mais evita retrabalho. Uma rede mal desenhada no começo vira problema de segurança e de desempenho dois anos depois.
3. Deploy: executar a migração por ondas
A migração acontece em ondas, começando pelas cargas de menor risco, para que a equipe aprenda no processo. Cada onda segue o mesmo ciclo: replicar, testar em ambiente isolado, ensaiar a virada e só então virar o tráfego, com plano de retorno definido.
4. Optimize: ajustar para a nuvem
Com tudo no ar, começa a parte que gera valor de verdade: redimensionar máquinas, adotar serviços gerenciados, automatizar escala e fechar compromissos de desconto com base em consumo real. É também o momento de ligar monitoramento e alertas de disponibilidade e custo.
Seis caminhos de migração: qual escolher para cada sistema
A palavra migração esconde estratégias muito diferentes. A documentação do Google descreve seis, e a escolha é feita sistema a sistema, não para a empresa inteira.
| Estratégia | O que é | Quando usar | Esforço |
|---|---|---|---|
| Rehost (lift and shift) | Move o sistema com mudanças mínimas | Prazo curto, legado difícil de alterar | Baixo |
| Replatform | Move e troca peças pontuais por serviços gerenciados, como o banco de dados | Ganho rápido sem reescrever o código | Médio |
| Refactor | Altera o sistema para aproveitar recursos da nuvem | Aplicação que precisa escalar | Médio a alto |
| Re-architect | Divide um sistema monolítico em serviços menores | Sistema grande com times independentes | Alto |
| Rebuild (rip and replace) | Reconstrói a aplicação como nativa de nuvem | Sistema obsoleto com pouco reaproveitamento | Alto |
| Repurchase | Troca o sistema por um serviço pronto (SaaS) | Software de prateleira, como e-mail e colaboração | Baixo a médio |
O erro mais comum que vejo no mercado é aplicar rehost em tudo e esperar que a conta caia. Sem nenhum ajuste, a empresa passa a pagar nuvem pelo preço de servidor superdimensionado. O rehost funciona como primeira etapa para sair de um data center com pressa, desde que a fase de otimização venha logo depois.
Ferramentas do Google para cada tipo de carga
O Google oferece ferramentas específicas para cada tipo de ativo. Saber qual usar economiza semanas.
| Ferramenta | Para que serve |
|---|---|
| Migration Center | Descoberta de ativos, avaliação, estimativa de custo e planejamento |
| Migrate to Virtual Machines | Migra máquinas virtuais e discos de vSphere, AWS, Azure e Google Cloud VMware Engine |
| Database Migration Service | Migra bancos MySQL, PostgreSQL, SQL Server e Oracle para o Cloud SQL e o AlloyDB, com replicação contínua e pouco tempo fora do ar |
| Storage Transfer Service | Transferência de grandes volumes de dados de armazenamento |
| Transfer Appliance | Dispositivo físico para volumes de dados grandes demais para a rede |
| BigQuery Migration Service | Migração de data warehouses e consultas para o BigQuery |
Para quem centraliza dados de marketing, vendas e operação, o destino natural costuma ser o BigQuery, com Looker Studio ou Power BI na camada de visualização. Esse é o terreno de uma agência de data analytics e é onde a migração costuma render mais retorno de negócio.
Região de São Paulo, latência e LGPD
Hoje o Google tem uma única região de nuvem no Brasil, a southamerica-east1, em Osasco (SP), com três zonas, segundo o MobileTime. Os detalhes e as demais regiões do mundo estão na lista oficial de localizações.
Rodar a aplicação perto do usuário reduz a latência, o que pesa em e-commerce, aplicativos e atendimento. Também simplifica a conversa jurídica. A LGPD permite a transferência internacional de dados em hipóteses específicas (artigo 33), e manter os dados em região no país reduz a necessidade de discutir esse ponto. Isso não substitui análise jurídica nem contrato bem escrito, mas tira um obstáculo comum de projetos em banco, saúde e setor público.
A novidade do Gemini com processamento local, a partir de 15 de outubro, aponta na mesma direção. O desenho de arquiteturas com IA no Brasil tende a se apoiar cada vez mais em infraestrutura dentro do país.
Quanto custa e como evitar surpresas na conta
Não existe preço único, porque o custo depende de região, tipo de máquina, armazenamento, rede e tempo de uso. O que existe é método. Antes de migrar, use a estimativa do Migration Center para ter um número de referência. Depois, aplique estes controles:
- Orçamentos e alertas desde o primeiro dia. Configure limites por projeto, com aviso por e-mail antes de estourar.
- Etiquetas (labels) em todo recurso. Sem elas, ninguém sabe qual área, cliente ou sistema gerou o gasto.
- Dimensionamento correto. Ajuste máquinas ao consumo real medido, não ao que o servidor antigo tinha.
- Descontos só depois de um histórico. Os descontos por uso contínuo chegam a até 30% automaticamente para máquinas que rodam o mês inteiro, conforme a documentação do Compute Engine. Os descontos por compromisso de 1 ou 3 anos são maiores (levantamentos de terceiros citam 28% e 46% no modelo flexível, e vale conferir a tabela oficial antes de decidir). Compromisso de longo prazo só deve ser assinado depois de dois ou três meses de consumo estável.
- Desligar o que não é usado. Ambientes de teste e discos órfãos são a fonte mais comum de gasto invisível.
Os erros mais comuns
- Pular o inventário. Migrar sem saber o que existe garante surpresas na virada.
- Ignorar dependências. Um sistema migrado que conversa com um banco que ficou para trás passa a sofrer com latência.
- Rehost permanente. Funciona para sair do lugar, mas sem otimização a conta decepciona.
- Segurança tratada no fim. Identidade, rede e backup precisam estar desenhados antes da primeira carga.
- Sem plano de retorno. Toda virada de produção precisa de um caminho de volta testado.
- Ninguém dono da conta. Sem responsável por custos, o gasto cresce sem que ninguém questione.
Passo a passo para uma migração segura
Resumindo o processo em uma sequência de trabalho, do inventário ao ajuste fino:
- Faça o inventário completo do ambiente
Liste servidores, bancos, aplicações, dependências e consumo real. Ferramentas como o Migration Center automatizam essa varredura.
- Classifique cada sistema por estratégia
Defina para cada carga se será rehost, replatform, refactor, rebuild, repurchase ou se será aposentada.
- Monte a base na nuvem
Crie a estrutura de projetos, a rede, o controle de acesso, as políticas de segurança, os alertas de orçamento e as etiquetas.
- Escolha uma carga piloto de baixo risco
Migre primeiro um sistema pouco crítico, para treinar a equipe e validar o processo.
- Replique, teste e ensaie a virada
Use as ferramentas de migração para replicar, teste em ambiente isolado e ensaie o corte antes de mexer na produção.
- Vire o tráfego com plano de retorno
Escolha uma janela de baixo movimento, monitore de perto e mantenha o ambiente antigo disponível até a estabilização.
- Otimize e meça o custo
Redimensione recursos, adote serviços gerenciados e só então feche compromissos de desconto.
Como a Superplural atua em migrações para o Google Cloud
A Superplural é certificada como Google Cloud Partner e ajuda negócios a hospedar, escalar e integrar aplicações na infraestrutura do Google Cloud. O trabalho cobre desde o provisionamento de servidores, rede e armazenamento até a migração e a conexão de sistemas existentes, com segurança, firewalls, backups e ajuste de recursos para controlar custos. Quem quiser conversar sobre um projeto pode conhecer a nossa página de agência Google Cloud Partner e a de consultoria de TI.
Depois da migração, o acompanhamento da disponibilidade importa tanto quanto o projeto. O Superplural Status faz o monitoramento de uptime da infraestrutura, e o Superplural Analytics entrega métricas de acesso com privacidade em primeiro lugar, em infraestrutura própria. Para quem está começando por um projeto menor, já escrevemos um passo a passo de como instalar e configurar o WordPress no Google Cloud, e também uma análise sobre a disputa entre as grandes nuvens.
Perguntas frequentes sobre migração para o Google Cloud
Depende do tamanho do ambiente e da estratégia escolhida. Um site ou aplicação única pode migrar em dias ou semanas, enquanto ambientes com muitos sistemas e dependências são feitos em ondas ao longo de meses.
O rehost costuma ser o ponto de partida quando o prazo é curto, porque move o sistema com poucas mudanças. O ideal é planejar a otimização logo depois, para que a conta na nuvem não fique maior que a do servidor antigo.
Sim. A região southamerica-east1 fica em Osasco, em São Paulo, e tem três zonas. É a única região de nuvem do Google no país hoje, e o Google anunciou que vai dobrar a capacidade no Brasil até 2030.
Em muitos casos sim. Ferramentas como o Database Migration Service mantêm a replicação contínua dos dados até o momento da virada, o que reduz bastante o tempo de indisponibilidade.
Use orçamentos e alertas, etiquetas em todos os recursos, dimensionamento baseado no consumo real e, só depois de alguns meses de histórico, descontos por compromisso. Desligar ambientes e discos sem uso também gera economia imediata.
Se eu tivesse que resumir em uma frase, diria que migrar bem é um trabalho de organização antes de ser um trabalho de tecnologia. A nuvem entrega o que promete para quem sabe o que tem, onde quer chegar e quem vai cuidar da conta. Para quem ainda não sabe nenhuma das três coisas, o melhor primeiro passo é um inventário honesto, e essa conversa a gente faz com prazer.
