Migrar de provedor sem downtime: o roteiro honesto

Migrar de provedor tem fama de projeto arriscado, e a fama vem de migrações mal planejadas. Feita com método, a troca é surpreendentemente sem graça: o tráfego muda de endereço e ninguém percebe.

A parte que dá trabalho quase nunca é a que se imagina. Copiar arquivo é rápido. Subir a aplicação em outro lugar é rotina. O que consome tempo é o banco de dados em movimento, a propagação de DNS e — principalmente — a lista de coisas que existem no servidor atual e não estão documentadas em lugar nenhum.

O inventário é metade do trabalho

Antes de qualquer coisa, descubra tudo o que a máquina atual faz. Servidor com alguns anos acumula função que ninguém lembra, e é isso que quebra depois do corte.

# O que sobe junto com a máquina
systemctl list-unit-files --state=enabled --type=service

# O que escuta em rede
sudo ss -tulpn

# Tarefas agendadas, de todos os usuários
sudo ls -la /etc/cron.d/ /etc/cron.*/ 2>/dev/null
for u in $(cut -d: -f1 /etc/passwd); do
  sudo crontab -l -u "$u" 2>/dev/null | grep -v '^#' | sed "s/^/$u: /"
done
systemctl list-timers --all

Faça também o levantamento do que não está no servidor:

• Registros DNS, incluindo os de e-mail — MX, SPF, DKIM, DMARC. Migrar o site e esquecer o e-mail é um clássico.
• Certificados e como cada um é renovado.
• Integrações que dependem do IP atual. Gateway de pagamento, API de banco e webhook de terceiro frequentemente têm lista de origem permitida. Este é o item que mais causa surpresa no dia seguinte.
• Variáveis de ambiente e segredos, que por definição não estão no versionamento.
• Serviços externos apontando para lá: monitoramento, backup, CDN.

O tempo gasto aqui é o que separa uma migração tranquila de um fim de semana ruim.

Deixe os dois no ar

O princípio que torna tudo mais seguro: não desligue o antigo. Suba o ambiente novo completo, em paralelo, e mantenha os dois funcionando durante a transição.

Custa alguns dias de máquina duplicada. Compra a capacidade de voltar atrás em segundos, que é a única coisa que realmente reduz o risco.

Valide o ambiente novo antes de qualquer tráfego real, forçando o destino sem mexer no DNS:

curl -H 'Host: meusite.com.br' https://203.0.113.99/ -k

Ou apontando localmente, para navegar no ambiente novo com o domínio real:

# /etc/hosts da sua máquina
203.0.113.99  meusite.com.br www.meusite.com.br

Com isso você percorre o site inteiro, faz login, envia formulário e testa checkout — tudo no servidor novo, com zero usuário afetado.

O banco é o que define a estratégia

Arquivo estático se copia quantas vezes for preciso. Banco de dados muda enquanto você copia, e é por isso que ele define a abordagem.

Se algum downtime é aceitável — e para muita aplicação, dez minutos de madrugada são —, a rota simples é a melhor:

# Coloque a aplicação em manutenção primeiro
pg_dump -Fc -d app | ssh novo 'pg_restore -d app --clean --if-exists'

Simples, verificável e sem peças móveis. Não subestime o valor disso.

Se downtime não é aceitável, o caminho é replicação: o banco novo acompanha o antigo em tempo real, e o corte é a promoção da réplica. Custa configuração e exige teste, mas reduz a indisponibilidade a segundos.

Em ambos os casos, meça o tempo antes. Um dump que leva quarenta minutos em homologação não vai levar dez em produção:

time pg_dump -Fc -d app -f /tmp/teste.dump
ls -lh /tmp/teste.dump

E confira a versão dos dois lados. Restaurar dump de uma versão em outra mais nova costuma funcionar; o contrário, não.

Arquivos: duas passadas, não uma

Copiar arquivo enviado por usuário — imagem, anexo, documento — tem o mesmo problema do banco: o conteúdo muda enquanto a cópia acontece. A solução é mais simples, e consiste em fazer duas passadas.

A primeira leva o volume todo, com o serviço no ar, e pode demorar horas sem incomodar ninguém:

rsync -az --info=progress2 /var/www/uploads/ novo:/var/www/uploads/

A segunda acontece na janela de corte e leva só o que mudou desde a primeira — questão de segundos:

rsync -az --delete /var/www/uploads/ novo:/var/www/uploads/

O --delete só entra na segunda passada, e por um motivo importante: ele remove no destino o que não existe mais na origem. Usado antes da hora, apaga arquivo que a aplicação nova já tinha criado legitimamente.

Confira a contagem dos dois lados antes de seguir:

find /var/www/uploads -type f | wc -l
ssh novo 'find /var/www/uploads -type f | wc -l'

Se os arquivos de usuário já estiverem em um bucket S3, essa etapa desaparece por completo — o armazenamento não migra junto com a máquina, basta a aplicação nova apontar para o mesmo lugar. É um bom argumento para tirar mídia do disco da VM antes mesmo de pensar em trocar de provedor.

DNS: prepare com antecedência

O DNS é onde o corte acontece, e ele tem uma inércia que precisa ser administrada com dias de antecedência.

O TTL diz por quanto tempo os resolvedores guardam a resposta. Se está em 24 horas, a mudança leva até 24 horas para alcançar todo mundo.

O procedimento:

• Uma semana antes, reduza o TTL para 300 segundos. Essa mudança também demora o TTL antigo para valer — por isso é a primeira coisa a fazer.
• No dia, confirme que o TTL curto já está valendo:

dig meusite.com.br +noall +answer

• Faça o corte alterando o registro.
• Acompanhe a propagação consultando resolvedores diferentes:

for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  printf '%-8s ' "$r"; dig @$r meusite.com.br +short
done

• Uma semana depois, com tudo estável, devolva o TTL ao valor normal.

Durante a janela de propagação, parte dos usuários vai para o servidor novo e parte para o antigo. É por isso que os dois precisam estar funcionais — e é por isso que o banco não pode aceitar escrita nos dois lugares ao mesmo tempo. A saída usual é deixar o antigo em modo somente leitura, ou fazer ele redirecionar para o novo.

O guia de apontamento de domínio cobre o registro em si; o que este roteiro acrescenta é a ordem e a antecedência.

O dia do corte

Uma sequência curta e ensaiada:

• Congele mudanças no ambiente antigo. Nada de deploy no dia.
• Tire um snapshot dos dois lados. No antigo, é a sua rede de segurança; no novo, o ponto de partida limpo.
• Sincronize a última vez. Arquivos com rsync, banco com o dump final ou a promoção da réplica.
• Emita o certificado no ambiente novo antes de mover o DNS, usando desafio por DNS se o domínio ainda aponta para o servidor antigo.
• Vire o DNS.
• Observe. Log de erro dos dois servidores, taxa de erro da aplicação, fila de e-mail.

Reserve pelo menos duas horas de atenção depois do corte. A maior parte dos problemas aparece nos primeiros trinta minutos, e todos são mais fáceis de resolver com alguém olhando.

O plano de volta, que quase nunca é usado

Escreva antes o que fazer se der errado, e defina o critério objetivo que dispara a decisão — taxa de erro acima de tanto, ou função crítica indisponível por mais de tantos minutos. Decidir isso no calor do momento é como se erra.

O plano de retorno é normalmente trivial: reverter o registro de DNS. Com TTL de 300 segundos, a volta acontece em cinco minutos. Foi para isso que o servidor antigo ficou de pé.

A única complicação é o banco. Se o novo já recebeu escrita, voltar significa perder essas transações ou reconciliá-las na mão. Por isso vale ter claro, antes, qual é a janela em que o retorno é gratuito e a partir de quando ele passa a custar — na maioria dos casos, esse ponto de não retorno é a primeira hora.

Só desligue o ambiente antigo depois de uma semana estável, com um backup completo guardado. É barato manter e caro não ter.

Se a origem for outro provedor e o volume de dados for grande, confira antes o custo de saída: tráfego de saída é cobrado por quem você está deixando, e um acervo histórico pode transformar a cópia em despesa relevante. Para os casos mais complexos, vale acionar o time de onboarding — migrações são avaliadas caso a caso quanto à viabilidade técnica.

Uma observação final sobre expectativa: migração bem feita é entediante. Se o dia do corte teve adrenalina, alguma etapa do preparo foi pulada — quase sempre o inventário ou o ensaio do dump. O objetivo não é resolver problema com agilidade no dia, é não ter problema para resolver.