Migração de hospedagem sem downtime: o passo a passo real

Uma migração de hospedagem sem downtime é possível para quase todo site, loja ou AVA, desde que você trate a troca de servidor como um projeto com fases, e não como uma tarde de cópia de arquivos. Neste guia eu mostro o passo a passo que usamos na Agathas Web: o que preparar uma semana antes, como virar a chave, quando não migrar e quanto isso custa de verdade.

TL;DR

• O Google recomenda baixar o TTL do DNS para algumas horas pelo menos uma semana antes da mudança. Quem pula esse passo fica refém do cache dos provedores.
• Arquivos e e-mails vão em cópias incrementais; o banco de dados é o único ponto que exige congelamento curto ou replicação.
• Com o domínio na Cloudflare em modo proxy, a troca de IP de origem vale na borda praticamente na hora; o TTL fixo de registros com proxy é de 300 segundos.
• O servidor antigo só é desligado quando o log dele mostra tráfego zero. Nós mantemos o ambiente velho intacto por 30 dias como rollback.
• Não migre na semana de matrícula, de Black Friday ou de fechamento: o risco é o mesmo, o prejuízo de um erro é muito maior.

O que é, na prática, uma migração de hospedagem sem downtime

Sem downtime não significa que nada muda por baixo. Significa que o visitante não percebe: o site responde o tempo todo, nenhuma compra é perdida e nenhum aluno vê página de erro no meio de uma prova.

Para chegar nisso, o trabalho se divide em duas partes muito diferentes:

• Conteúdo estático (código, imagens, uploads, a pasta moodledata de um Moodle): pode ser copiado com o site no ar, quantas vezes for preciso, porque cada nova cópia só transfere o que mudou.
• Estado vivo (banco de dados, sessões, filas, e-mails chegando): muda a cada segundo. Aqui está o risco real. Se o banco novo começa a receber pedidos enquanto o antigo ainda recebe outros, você tem dois bancos divergentes e nenhum deles está certo.

Por isso a honestidade técnica importa. Num site institucional, a virada é realmente invisível. Num e-commerce ou num AVA com milhares de acessos, fazer migração de hospedagem sem downtime quer dizer uma de duas coisas: replicar o banco em tempo real até o momento da troca, ou aceitar alguns minutos de escrita congelada (o site continua aberto para leitura) numa janela de baixo tráfego. As duas são legítimas. Mentir sobre qual das duas você vai usar é que não é.

Quando migrar e quando NÃO migrar agora

Os motivos que mais trazem clientes até nós: servidor que cai sem explicação, suporte que responde em dias, PHP preso no passado ou conta de nuvem que cresceu sem controle. Qualquer um justifica a troca.

Bons momentos para migrar

Escolher a data é metade de uma migração de hospedagem sem downtime bem-sucedida. Os melhores cenários:

• Fora de picos de negócio: férias escolares para AVA, meio de mês para varejo.
• Antes de vencer contrato ou renovação anual do fornecedor atual, com folga de pelo menos 30 dias.

Quando segurar a migração

• Na semana de matrícula, de provas ou de Black Friday. O procedimento é o mesmo, mas o custo de um erro multiplica.
• Quando ninguém tem acesso ao DNS. Se a senha do registro do domínio está com um ex-funcionário ou com a agência antiga, resolva isso primeiro. Sem acesso ao DNS não existe virada controlada.
• Quando o plano é migrar e atualizar tudo ao mesmo tempo. Trocar servidor, versão do Moodle e tema no mesmo dia transforma qualquer erro num quebra-cabeça. Migre primeiro, atualize depois.
• Quando não há backup testado do ambiente atual. Antes de mexer, restaure o backup em algum lugar e confirme que ele sobe.

Se a sua dúvida ainda é entre contratar um servidor e cuidar dele sozinho ou ter alguém operando, vale ler antes o comparativo hospedagem gerenciada vs VPS: ele mostra quem responde quando o site cai em cada modelo.

O passo a passo da migração de hospedagem sem downtime em 5 fases

O método abaixo é o mesmo que aplicamos em sites, lojas e AVAs. Muda a escala, não a ordem. Pular uma fase é a forma mais comum de transformar uma migração de hospedagem sem downtime numa madrugada de incidente.

Fase 1: inventário e preparação do servidor novo

A maior parte dos problemas nasce de algo que ninguém sabia que existia: um cron à meia-noite, um subdomínio esquecido, um redirecionamento no .htaccess que só a agência antiga conhecia.

O inventário que fazemos antes de tocar em qualquer coisa

1. DNS completo: exportamos a zona inteira (A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, registros de verificação do Google e da Meta).
2. Versões: PHP, Node, MariaDB ou MySQL, extensões instaladas, limites de memória e de upload.
3. Tarefas agendadas: crontab do sistema, cron do Moodle, wp-cron, filas de e-mail.
4. Integrações: webhooks de pagamento, a API oficial do WhatsApp, SSO, gateways que liberam acesso por IP. Se o IP do servidor muda, tudo que tem lista de IPs autorizados precisa ser atualizado antes da virada.
5. Certificados e e-mail: quem emite o SSL, onde estão as caixas postais e quanto espaço ocupam.

Baixe o TTL uma semana antes

TTL é o tempo que os servidores de DNS do mundo guardam a resposta em cache. Se o seu registro A tem TTL de 24 horas, parte dos visitantes vai continuar indo para o servidor antigo por até um dia depois da troca. A documentação do Google para mudança de hospedagem sem troca de URL recomenda baixar o TTL para algumas horas pelo menos uma semana antes. Nós vamos além: na véspera, deixamos em 300 segundos.

Se o domínio está na Cloudflare com proxy ligado, o cenário é melhor. Segundo a documentação de TTL da Cloudflare, registros com proxy têm TTL fixo de 300 segundos e o visitante só enxerga os IPs da própria Cloudflare. Trocar o IP de origem passa a ser uma mudança interna, que vale na borda quase imediatamente. É o principal motivo de colocarmos os domínios dos clientes atrás dela antes de qualquer migração.

Fase 2: cópia dos dados e sincronização

Com o servidor novo provisionado e com as mesmas versões do antigo, começa a cópia. Numa migração de hospedagem sem downtime a regra é copiar cedo e copiar de novo: a primeira cópia leva horas, as seguintes levam minutos.

Arquivos com rsync

Usamos rsync sobre SSH. A primeira passada transfere tudo; as próximas só o que mudou. No Moodle, isso vale para o código e, principalmente, para a moodledata, que costuma ser a maior parte do volume. No dia da virada, a última sincronização roda em poucos minutos porque quase tudo já está lá.

Banco de dados: dump consistente ou replicação

Para bases pequenas e médias em InnoDB, um mysqldump com a opção --single-transaction gera uma cópia consistente sem travar as tabelas, porque lê tudo de um mesmo instante. Lembre de incluir --routines, --triggers e --events, que não saem por padrão.

Quando o banco é grande ou a escrita não pode parar, configuramos o servidor novo como réplica do antigo. Ele recebe cada alteração em tempo real e, no momento da virada, é promovido a principal. É mais trabalho de preparo, mas transforma a janela de congelamento em segundos.

E-mails

Caixas postais vão com imapsync, em duas rodadas: uma completa antes da virada e uma incremental depois que o MX aponta para o servidor novo. Assim as mensagens que chegarem no servidor antigo durante a propagação também são trazidas.

Fase 3: validação em staging antes da virada

Antes de mexer no DNS, o ambiente novo precisa funcionar sozinho. Montamos um endereço interno de homologação (ou editamos o arquivo hosts só na máquina de quem testa) e rodamos um roteiro fixo:

• Login de aluno, professor e administrador; no e-commerce, um pedido completo até o pagamento em ambiente de teste.
• Envio de e-mail transacional e recebimento de webhook.
• Upload de arquivo, geração de PDF ou certificado, busca interna.
• Logs de erro do PHP e do servidor web vazios depois do roteiro.

No Moodle, conferimos ainda o config.php (wwwroot e dataroot), limpamos os caches com php admin/cli/purge_caches.php e garantimos que o cron rode em um só servidor. Cron duplicado é um clássico: os dois ambientes disparam as mesmas tarefas e os alunos recebem notificações em dobro.

O staging é onde uma migração de hospedagem sem downtime é ganha ou perdida. O cliente valida e aprova por escrito. Sem esse aceite, não há virada. Se o seu AVA tem exigências específicas de capacidade, o guia de requisitos e custos de hospedagem Moodle detalha o que dimensionar antes.

Fase 4: a virada e a janela de congelamento

A virada (cut-over) é a parte curta. Quando as fases anteriores foram bem feitas, ela dura de 10 a 30 minutos e acontece de madrugada ou no horário de menor uso daquele cliente específico, que descobrimos olhando o log, não chutando.

Este é o cronograma padrão da nossa migração de hospedagem sem downtime em projetos de porte médio:

Momento	O que acontece	Quem confere
T-7 dias	TTL reduzido, inventário fechado, servidor novo provisionado	Infra
T-3 dias	Primeira cópia completa de arquivos, banco e e-mails	Infra
T-1 dia	Staging aprovado por escrito, TTL em 300 s, comunicado ao time	Cliente e infra
T0	Modo manutenção ou só leitura, sincronização final, troca do DNS	Infra
T+1 hora	Testes de fumaça em produção, logs dos dois servidores	Infra
T+1 dia	imapsync incremental, revisão de tarefas agendadas	Infra
T+30 dias	Desligamento do servidor antigo, se o tráfego nele for zero	Infra e cliente

No Moodle, o congelamento é feito com php admin/cli/maintenance.php --enable. A documentação oficial de migração do Moodle lembra um detalhe que pega muita gente: administradores não são bloqueados pelo modo manutenção, então ninguém da equipe deve entrar no painel durante a cópia final.

Certificado SSL antes do DNS apontar

O certificado do servidor novo precisa existir antes da virada. O desafio HTTP-01 do Let's Encrypt não funciona enquanto o domínio aponta para o servidor antigo, então usamos validação por DNS ou o certificado de origem da Cloudflare. E automatize a renovação: desde 15 de março de 2026 a validade máxima de certificados públicos caiu para 200 dias, e o Let's Encrypt anunciou que o perfil padrão passa de 90 para 64 dias em 10 de fevereiro de 2027 e para 45 dias em 16 de fevereiro de 2028. Renovação manual não tem mais lugar numa operação séria.

Fase 5: monitoramento e desligamento do servidor antigo

Uma migração de hospedagem sem downtime só termina quando o servidor antigo pode ser desligado sem que ninguém perceba. Depois da virada, os dois servidores ficam de pé. O antigo continua recebendo alguns acessos de quem ainda tem o DNS velho em cache, e isso é esperado. O Google orienta acompanhar o log do provedor antigo e só desligar quando o tráfego nele chegar a zero. A mesma página avisa que a taxa de rastreamento do Googlebot pode cair logo após a mudança e voltar a subir nos dias seguintes.

Nas primeiras 72 horas, acompanhamos:

• Erros 5xx e tempo de resposta no servidor novo.
• Acessos residuais no servidor antigo, em especial requisições POST, que indicam alguém gravando dados no lugar errado.
• Fila de e-mails, rejeições por SPF e DKIM e entrega das mensagens transacionais.

Um cuidado que muita gente esquece: se o Search Console foi verificado por um arquivo HTML na raiz do site, esse arquivo precisa estar no servidor novo. Senão a propriedade perde a verificação justamente na semana em que você mais precisa dos dados.

Armadilhas que já vimos em migração de hospedagem sem downtime

O relatório anual de interrupções do Uptime Institute de 2025 aponta que quase 40% das organizações tiveram uma interrupção grave causada por erro humano nos últimos três anos, e que 85% desses casos vieram de equipe que não seguiu o procedimento ou de procedimento falho. Migração é exatamente o tipo de operação em que isso acontece. Algumas armadilhas que já encontramos na prática:

Painel que não regenera o que deveria

Em servidores com HestiaCP, já vimos o webmail parar depois de um rebuild do painel porque o vhost SSL da porta 443 não foi recriado. Só aparece se o roteiro de testes incluir o webmail.

IP do visitante virando o IP da Cloudflare

Ao colocar o site atrás de proxy, os logs, o rate limit de login e o antifraude passam a enxergar o IP da borda, e não o do cliente. O único cabeçalho confiável para recuperar o IP real é o CF-Connecting-IP. Sem esse ajuste, uma proteção contra força bruta pode bloquear todo mundo de uma vez.

Outras que aparecem com frequência

• Container Docker que volta fora da rede do proxy reverso depois de um restart e deixa o site em 502.
• Lista de IPs liberados num gateway de pagamento ou numa API ainda com o IP antigo.
• Fuso horário do servidor diferente, quebrando agendamentos e relatórios.
• Limite de upload menor no servidor novo, descoberto pelo professor que tenta enviar um vídeo.

Nenhuma delas é difícil de resolver. Todas são difíceis de descobrir às três da manhã. É para isso que serve uma checklist de migração de hospedagem sem downtime escrita antes, e não lembrada na hora.

Quanto custa e quanto tempo leva

O custo de uma migração depende menos do tamanho do site e mais da quantidade de estado vivo e de integrações. Em vez de inventar uma tabela de preços genérica, este é o retrato do que vemos no dia a dia:

Tipo de projeto	Desafio principal	Janela de congelamento típica	Prazo total
Site institucional ou WordPress simples	DNS e e-mails	Nenhuma perceptível	2 a 3 dias úteis
E-commerce ou sistema com pagamentos	Banco, webhooks, IPs liberados	Minutos, ou zero com replicação	4 a 7 dias úteis
Moodle com moodledata grande	Volume de arquivos, cron, plugins	10 a 30 minutos de manutenção	5 a 7 dias úteis
Aplicação em containers com várias integrações	Redes, variáveis de ambiente, filas	Depende da arquitetura	Sob avaliação

O custo escondido está no servidor antigo pago em dobro por um mês, nas horas de teste e no risco de uma virada no dia errado. Se você está comparando nuvem pública com um ambiente gerenciado, o comparativo Moodle na AWS vs hospedagem gerenciada mostra onde a conta costuma sair do controle.

Fazer sozinho uma migração de hospedagem sem downtime é viável quando o site é simples e alguém do time tem acesso a DNS, SSH e banco. Fica arriscado quando há loja, AVA em semestre letivo ou integrações que ninguém documentou. Nesses casos, terceirizar a migração de hospedagem sem downtime custa menos do que um dia de matrícula fora do ar.

Como a Agathas Web resolve isso

Na hospedagem gerenciada da Agathas Web, a migração vem incluída no setup e segue exatamente as fases deste guia. Você não executa nenhuma etapa técnica da migração de hospedagem sem downtime: o time cuida de tudo e você só valida. Na prática, é assim:

1. Diagnóstico: levantamos o ambiente atual (DNS, versões, crons, integrações, e-mails) e devolvemos um plano com data de virada proposta para o horário de menor uso do seu negócio.
2. Ambiente novo sob medida: configuramos PHP, Node, Python ou containers conforme a sua stack, com WAF Cloudflare, SSL automático, backups diários e monitoramento 24/7.
3. Staging com aceite: você testa o ambiente novo num endereço interno e aprova por escrito antes de qualquer mudança no DNS.
4. Virada e rollback: o cut-over acontece fora do horário comercial, com TTL baixo e o ambiente antigo intacto por 30 dias. Se algo der errado, revertemos em horas.
5. Operação contínua: depois da migração, o mesmo time segue cuidando do servidor, com SLA contratual de 99,9% de uptime e resposta a incidente crítico em até 15 minutos.

O prazo de referência é de até 7 dias úteis para site, banco, e-mails e DNS. Atendemos sites, sistemas Laravel e Next.js, e-commerce, Moodle e aplicações que usam a API oficial do WhatsApp, onde a troca de servidor também envolve webhooks e certificados.

Para contratar, basta pedir um diagnóstico pela página da hospedagem gerenciada ou pelo WhatsApp. Respondemos com o plano de migração e o orçamento antes de você assinar qualquer coisa.

Conclusão: migração é método, não sorte

Uma migração de hospedagem sem downtime depende de quatro decisões tomadas antes do dia da virada: baixar o TTL com uma semana de antecedência, copiar os dados em rodadas incrementais, validar tudo num staging aprovado e manter o servidor antigo como rede de segurança até o tráfego nele zerar.

Se a sua empresa ou instituição está presa a um servidor que cai, a um suporte que não responde ou a uma conta de nuvem sem controle, o primeiro passo é um inventário honesto do que existe hoje. Fale com a gente pela página de hospedagem gerenciada com migração incluída e receba o plano da sua migração de hospedagem sem downtime antes de decidir.