Toda migração de nuvem parece simples no whiteboard. Você desenha a seta de "origem" para "destino", anota "DNS cutover" no meio e assume que vai ser fluido. Na prática, o que separa uma migração que termina em horário comercial de uma que vira incidente noturno é o plano executado nos detalhes que o whiteboard não mostra: o cache DNS que segura requisições no servidor antigo por horas depois do cutover, a conexão SSL que não renova porque o processo assumiu que o domínio seria validado no servidor antigo, os dados escritos na janela de transição que nunca chegam ao servidor novo.
Resumo rápido: Migração zero-downtime entre clouds exige preparação em quatro fases: redução de TTL DNS dias antes, configuração completa do ambiente destino com validação independente, período de dual-write ou proxy reverso para manter consistência de dados durante a transição, e plano de rollback testado e documentado antes de iniciar. O downtime em migrações mal planejadas raramente vem do cutover — vem do que foi assumido como "vai funcionar" sem verificação.
Por que migrar entre clouds em 2025?
A pergunta tem respostas concretas que se tornaram mais relevantes nos últimos anos. O custo de compute em provedores europeus como Hetzner, especialmente com servidores ARM (linha Cloud Ampere e CAX), criou uma diferença de custo significativa em relação a AWS e DigitalOcean para workloads de compute puro.
Um servidor com 8 vCPUs ARM e 16 GB RAM na Hetzner custa substancialmente menos do que um equivalente EC2 na AWS — e para aplicações que não dependem de serviços proprietários da AWS (RDS Multi-AZ, SQS, Lambda com triggers nativos), a migração faz sentido financeiro.
Oracle Cloud Free Tier tem instâncias ARM que muitos times usam para cargas que não precisam de garantias enterprise. Para n8n self-hosted, Ollama, instâncias menores de banco de dados e ferramentas de automação, o custo pode cair a zero nos limites do free tier.
Migração de WordPress para Cloudflare Pages + Next.js ou Astro elimina custo de servidor e latência para conteúdo estático. O trade-off é a complexidade de migração de conteúdo e a necessidade de repensar funcionalidades dinâmicas.
O ponto central em todos esses cenários: a migração se paga em três a seis meses de diferença de custo, mas só se for executada sem downtime e sem perda de dados.
Fase 0: O que validar antes de começar
Antes de qualquer mudança de infraestrutura, o inventário precisa estar claro:
Quais serviços dependem do servidor atual? Inclua integrações que não estão documentadas — webhooks de terceiros que apontam para o IP antigo, backups que sincronizam para o servidor via SSH, crons externos que fazem pull de dados.
Quais dados mudam durante a janela de migração? Banco de dados com escrita constante precisa de estratégia diferente de banco com escrita eventual. APIs que recebem webhooks de pagamento não podem perder transações durante o cutover.
Qual é o RTO aceitável? RTO (Recovery Time Objective) é o tempo máximo de indisponibilidade que o negócio tolera. Se a resposta é "zero", o plano é diferente de "até 15 minutos aceitáveis fora de horário de pico". Seja honesto sobre isso antes de planejar.
O ambiente destino foi testado de forma independente? O servidor novo precisa ter a aplicação rodando e validada antes de qualquer cutover. Testes no ambiente destino usando arquivo hosts local (ou DNS interno) antes de mexer no DNS público.
Fase 1: Preparação — TTL e ambiente destino
Redução de TTL DNS é a preparação mais crítica e mais ignorada. O TTL (Time To Live) de um registro DNS define por quanto tempo servidores ao redor do mundo cacheiam aquele registro. Se seu TTL é 86400 (24 horas), mesmo após o cutover os usuários cujos resolvedores cachearão o IP antigo continuarão apontando para o servidor antigo por até 24 horas.
A preparação correta: sete a dez dias antes da migração, reduza o TTL do domínio principal para 300 segundos (5 minutos). Aguarde até que o TTL antigo expire nos caches (respeite o TTL vigente antes da mudança). Após esse período, qualquer mudança de A/AAAA record vai se propagar em cinco minutos, não em 24 horas.
Configuração completa do ambiente destino precisa acontecer em paralelo, sem impactar o servidor atual. Isso inclui:
- Toda a aplicação instalada e funcionando
- Banco de dados com dados de uma snapshot recente (para testes funcionais)
- SSL configurado — mas com validação de domínio via DNS challenge (não HTTP challenge, que exige que o domínio aponte para o servidor)
- Variáveis de ambiente e secrets configurados
- Reverse proxy (Traefik, Caddy, Nginx) com as mesmas rotas do servidor atual
- Monitoramento configurado com alertas ativos
A validação nesse ambiente usa curl --resolve dominio.com:443:IP_NOVO https://dominio.com para testar as rotas sem alterar o DNS público. Essa checagem de ambiente destino é parte do protocolo que o time de DevOps da MaxVision executa antes de qualquer janela de cutover.
Fase 2: Sincronização de dados — o problema que ninguém planeja
Para serviços com banco de dados, o período entre o snapshot inicial (usado para configurar o ambiente destino) e o cutover acumula dados que precisam ser sincronizados. Dependendo do volume de escrita, essa diferença pode ser de minutos ou de horas.
Para PostgreSQL, o método mais seguro é logical replication: o banco destino se inscreve como réplica do banco origem e recebe as mudanças em tempo real. Quando o lag de replicação chega a zero (ou a poucos segundos), você executa o cutover e promove o banco destino para primary.
Para MySQL/MariaDB, o processo é análogo com binlog replication.
Para casos mais simples (banco pequeno, janela de manutenção aceitável), o dual-write via aplicação é uma alternativa: durante a janela de transição, a aplicação escreve em ambos os bancos. O risco é a complexidade de manter consistência e a dificuldade de rollback se divergências apareceram.
Para arquivos estáticos e uploads, rsync com --checksum garante que apenas arquivos novos ou modificados sejam transferidos. Executar rsync continuamente nos dias antes do cutover reduz o volume de dados a sincronizar no momento crítico.
Fase 3: Cutover — a janela que precisa ser curta
O cutover ideal dura menos de dez minutos. Qualquer coisa além disso indica que a preparação não foi completa o suficiente.
Sequência padrão para migração de aplicação web:
- Ativar modo de manutenção na aplicação origem (retorna 503 com mensagem clara)
- Executar dump final do banco e importar no destino (ou confirmar lag zero na replicação)
- Sincronizar arquivos finais com rsync
- Atualizar registro DNS: A/AAAA apontando para o IP novo
- Aguardar propagação (com TTL de 300s, a maioria dos resolvedores vai atualizar em menos de 5 minutos)
- Validar o ambiente destino via requests reais (monitoramento, smoke tests)
- Desativar modo de manutenção
O ponto de decisão crítico é entre os passos 5 e 6: se a validação falhar, o rollback é simples — reverter o registro DNS para o IP antigo. Com TTL de 300s, o rollback também propaga em minutos.
Fase 4: Estabilização e descomissionamento
Não desligue o servidor antigo imediatamente após o cutover. Mantenha-o por pelo menos 72 horas — de preferência uma semana — com a aplicação ainda rodando (mas sem receber tráfego novo).
Esse período serve para:
- Confirmar que nenhum webhook ou integração externa ainda aponta para o IP antigo
- Verificar que emails transacionais com domínio configurado (SPF, DKIM) estão funcionando no novo servidor
- Identificar qualquer serviço que hardcoded o IP antigo em vez de usar o domínio
Após confirmar que não há dependência do servidor antigo, documente o processo — o que funcionou, o que precisou de ajuste, qual foi o tempo real de indisponibilidade (mesmo que segundos). Essa documentação é o runbook para a próxima migração.
O que dá errado mesmo com bom planejamento
Cache DNS mais persistente do que o TTL. Alguns ISPs e resolvedores ignoram o TTL e cachiam por tempo próprio. Isso é especialmente comum em redes corporativas com resolvedores internos. A mitigação é monitorar de onde vêm as requisições para o servidor antigo após o cutover e comunicar proativamente usuários em redes corporativas se necessário.
SSL com HTTP challenge em vez de DNS challenge. Let's Encrypt valida a propriedade do domínio de duas formas: HTTP (acessando um arquivo num path específico no servidor que responde ao domínio) ou DNS (criando um registro TXT no DNS). Se você usou HTTP challenge no servidor destino, o certificado só será emitido depois que o DNS apontar para o novo servidor — mas sem SSL, muitos browsers bloqueiam o acesso. Use DNS challenge para emitir o certificado antes do cutover.
Dados em trânsito durante o cutover. Transações iniciadas no servidor antigo que estavam em processo (pagamento sendo processado, upload em andamento) podem ser interrompidas pelo modo de manutenção. Para sistemas de pagamento, o ideal é aguardar o esvaziamento da fila de processamento antes de ativar o modo de manutenção.
Configurações hardcoded por IP. Serviços de terceiros que integram via IP em vez de domínio precisam ter o IP atualizado separadamente. Isso inclui firewalls de banco de dados gerenciado, allowlists de API de terceiros, integrações de monitoramento externo.
Secrets que não foram migrados. Um ambiente destino funcional em staging pode falhar em produção se uma variável de ambiente foi esquecida. Crie um checklist de todos os secrets do servidor origem e valide que cada um existe no destino antes do cutover.
A tabela de riscos por fase
| Fase da Migração | Risco | Mitigacao |
|---|---|---|
| Preparacao (dias antes) | TTL alto que atrasa propagacao pos-cutover | Reduzir TTL para 300s com 7-10 dias de antecedencia |
| Configuracao do destino | SSL invalido no cutover (HTTP challenge) | Usar DNS challenge para emissao pre-cutover |
| Sincronizacao de dados | Dados escritos apos snapshot nao chegam ao destino | Replicacao logica continua ou janela de manutencao curta |
| Cutover DNS | Cache de resolvedores externos ignora TTL reduzido | Monitorar ambos os IPs pos-cutover; manter origem ativo |
| Pos-cutover imediato | Webhook ou integracao aponta para IP antigo | Inventario completo de dependencias antes do inicio |
| Estabilizacao | Descomissionar servidor antigo cedo demais | Manter origem por minimo 72h apos cutover validado |
| Qualquer fase | Rollback nao foi testado antes do incidente | Executar simulacao de rollback em staging antes do cutover real |
Quando zero-downtime é impossível (e o que fazer)
Algumas migrações têm componentes que exigem janela de manutenção inevitável. Banco de dados com schema migration que não é retrocompatível (como renomear uma coluna) não pode ser aplicada com dual-write sem lógica adicional de compatibilidade.
Nesses casos, a abordagem honesta é escolher a menor janela de manutenção possível (geralmente madrugada de menor uso), comunicar com antecedência, automatizar ao máximo o processo de cutover para reduzir o tempo de execução, e ter o rollback testado e documentado para execução imediata se necessário.
Downtime planejado e comunicado é diferente de downtime inesperado. Um é operação controlada; o outro é incidente.
Perguntas Frequentes
Quanto tempo a migração AWS → Hetzner tipicamente leva?
Depende do volume de dados e da complexidade dos serviços. A preparação (configurar o ambiente destino, testar, reduzir TTL) leva de uma a duas semanas. A janela de cutover em si, se bem preparada, dura menos de trinta minutos. O descomissionamento completo do ambiente origem, considerando o período de estabilização, leva mais uma semana.
Como migrar banco de dados grande sem janela de manutenção?
Replicação lógica é a resposta para PostgreSQL e MySQL. O processo configura o banco destino como réplica do banco origem, replicando mudanças em tempo real. Quando o lag chega a zero, você promove o destino para primary e atualiza as conexões da aplicação. O downtime se limita ao tempo de promoção do banco — geralmente segundos. Requer que o banco origem esteja configurado para WAL level logical (PostgreSQL) ou que o binlog esteja ativo (MySQL).
WordPress para Cloudflare Pages: o que muda na prática?
A stack muda completamente: o conteúdo migra para arquivos Markdown/MDX, a entrega passa a ser edge computing sem servidor, e as funcionalidades dinâmicas (formulários, comentários, autenticação) precisam de serviços externos (Supabase, Cloudflare Workers, Sendgrid). O ganho é eliminação de custo de hospedagem para conteúdo estático e melhora de performance. O custo é a migração de conteúdo e a reescrita das funcionalidades dinâmicas, que pode ser significativa dependendo do site.
O servidor antigo pode ficar ativo depois do cutover como fallback?
Sim, e é exatamente o que recomendamos durante o período de estabilização. O servidor antigo ativo mas sem receber tráfego novo é o rollback mais rápido possível: reverter o registro DNS é questão de segundos. Mantenha-o ativo por pelo menos uma semana antes de descomissionar.
Como lidar com emails transacionais na migração?
Email transacional depende de SPF, DKIM e DMARC configurados para o domínio — não para o IP do servidor. Se você usa serviço dedicado (Sendgrid, Postmark, Amazon SES), não há nada a migrar no email em si. Se o servidor antigo enviava emails diretamente (Postfix local), o servidor novo precisa ter SPF/DKIM configurados antes do cutover, e os registros DNS de email precisam ser atualizados na mesma janela do cutover de aplicação.
Conclusão
Migração zero-downtime não é um evento — é um processo que começa semanas antes do cutover e termina dias depois. A maioria dos problemas em migrações acontece não por falha técnica no momento do cutover, mas por suposições não verificadas na preparação: TTL que nunca foi reduzido, SSL que não foi validado antes, dados que assumiram sincronização automática sem teste.
O plano que funciona tem três características: o ambiente destino está completamente validado de forma independente antes de qualquer mudança de DNS, o rollback foi testado e cronometrado, e há alguém monitorando ativamente ambos os servidores durante e após o cutover.
Migrar entre clouds — AWS para Hetzner, DigitalOcean para Oracle, WordPress para Cloudflare Pages — exige um executor que já percorreu cada fase e sabe onde os problemas aparecem. O departamento de DevOps da MaxVision conduz o processo completo: inventário de dependências, configuração validada do destino, replicação de dados, cutover e estabilização, com runbook documentado e SLA por escrito. Descreva o seu cenário e receba uma avaliação inicial.
