Como migrar de hospedagem sem downtime

Antes de começar: checklist de preparação

A maior causa de downtime numa migração não é a transferência de arquivos — é a falta de preparação do DNS e o esquecimento de algum serviço dependente (e-mail, subdomínios, integrações). Confirme cada item antes de tocar em qualquer configuração:

• Acesso confirmado ao provedor atual (FTP/SSH, painel, banco de dados) e ao novo provedor.
• Lista completa de subdomínios e registros DNS ativos (A, CNAME, MX, TXT/SPF, DKIM) — exporte a zona DNS atual antes de mudar qualquer coisa.
• Backup completo verificado: arquivos, banco de dados e, se houver, contas de e-mail.
• Certificado SSL identificado — se for Let's Encrypt, será emitido de novo no destino; se for pago, confirme se pode ser reemitido ou precisa ser reinstalado.
• Janela de baixo tráfego definida para a virada final do DNS.
• Todas as contas de e-mail do domínio listadas, se a migração incluir e-mail.

Reduza o TTL do DNS com antecedência

TTL (Time To Live) é o tempo que os resolvedores de DNS guardam em cache o endereço antigo. Se o TTL do seu domínio estiver em 24h (86400 segundos, o padrão em muitos provedores) e você mudar o DNS sem preparar isso, parte dos visitantes vai continuar caindo no servidor antigo por até um dia inteiro.

1. Pelo menos 24–48h antes da migração, reduza o TTL dos registros A e CNAME do domínio para 300 segundos (5 minutos).
2. Aguarde o TTL antigo expirar naturalmente — só depois desse período a mudança de TTL realmente já está propagada.
3. Só então faça a virada final do DNS para o novo servidor.
4. Depois que a migração estiver validada e estável (alguns dias), volte o TTL para um valor mais alto (1h a 24h) — TTL muito baixo permanente aumenta a carga nos servidores de DNS sem necessidade.

Ordem das operações no dia da virada

Com o TTL já baixo e o novo ambiente pronto, a virada em si segue esta ordem:

1. Suba os arquivos e o banco de dados para o novo servidor, sem apagar nada no antigo ainda.
2. Coloque o site no ar no novo servidor usando um domínio temporário, IP direto ou o arquivo hosts local — teste tudo (páginas, formulários, painel admin, checkout se for loja) antes de apontar o DNS de verdade.
3. Só depois do teste no ambiente novo passar, aponte o DNS (registros A/CNAME) para o novo servidor.
4. Se a migração incluir e-mail, migre as contas e só troque o registro MX depois que as caixas já estiverem replicadas no destino — isso evita perda de mensagens durante a janela de propagação.
5. Mantenha o site antigo no ar (sem apagar) por pelo menos 48–72h após a virada, como rede de segurança caso precise reverter.

Validação pós-migração

Depois que o DNS propagar, confira sistematicamente — não confie só em "abriu no meu navegador", porque cache local e DNS já propagado pra você escondem problemas que outros visitantes ainda têm:

• Propagação de DNS em múltiplas localizações (ferramentas públicas de checagem de DNS mostram isso por região).
• Certificado SSL válido no novo endereço, sem aviso de "conexão não seguros".
• Formulários de contato e checkout completando de ponta a ponta, incluindo o e-mail de confirmação chegando.
• E-mail enviando e recebendo normalmente (teste os dois sentidos, não só o envio).
• Todos os subdomínios (loja, blog, painel, API) respondendo no novo servidor.
• Redirects 301 de URLs antigas, se a estrutura de URL mudou.
• Performance comparável ou melhor que antes (tempo de resposta do servidor).

Tempos reais por tipo de site

Os tempos variam com o volume de dados e a complexidade, mas como referência:

Em todos os casos, a propagação de DNS é o mesmo intervalo curto — porque depende do TTL, não do tamanho do site. O que muda é o tempo de transferência dos dados, que acontece antes da virada e não derruba o site atual.

O que pode dar errado — e como reverter

Por isso o site antigo deve continuar no ar por alguns dias após a virada: reverter o DNS é rápido (minutos, com TTL baixo) desde que o ambiente antigo ainda exista.