Trocar de hospedagem tem uma fama pior do que merece. A operação é razoavelmente previsível, e a maior parte dos problemas vem de três erros específicos — sempre os mesmos, sempre evitáveis.

O primeiro é apontar o domínio para o novo servidor antes de o conteúdo estar lá. O segundo é esquecer o e-mail, que exige um cuidado próprio e falha de forma silenciosa. O terceiro é encerrar o plano antigo cedo demais, eliminando o caminho de volta.

Este guia organiza a migração em quatro fases, com atenção especial ao ponto que mais confunde: o que realmente acontece durante a propagação de DNS.

O princípio que evita quase todo problema

Antes do procedimento, uma ideia que orienta tudo: os dois ambientes coexistem durante a migração.

Você não desliga um e liga o outro. Você monta o novo ambiente completo, testa com o site antigo ainda no ar, e só então redireciona o tráfego. Se algo der errado, o ambiente anterior continua funcionando.

Migrações que dão errado quase sempre violam esse princípio em algum ponto — geralmente por pressa em cancelar o plano antigo ou por apontar o domínio antes da hora.

Fase 1 — Preparação

A fase mais longa e a que determina o resultado. Nada aqui afeta o site atual.

1. Faça o inventário. Liste tudo o que precisa ir junto: arquivos do site, banco de dados, contas de e-mail com seus históricos, tarefas agendadas, certificados, redirecionamentos configurados e integrações que apontam para o servidor atual.
2. Confirme os requisitos no ambiente novo: versão de linguagem, extensões, versão de banco de dados. Descobrir uma incompatibilidade agora é barato; descobrir depois da virada, não.
3. Reduza o TTL do DNS. Este é o passo técnico mais importante e o mais esquecido. O TTL define por quanto tempo servidores pela internet guardam a informação de para onde o seu domínio aponta. Reduzi-lo com pelo menos 48 horas de antecedência faz a virada acontecer em minutos em vez de horas.
4. Faça um backup completo do ambiente atual e guarde-o fora dos dois servidores.
5. Escolha a janela, no horário de menor movimento segundo os seus próprios dados, evitando vésperas de campanha e períodos sazonais.

Sobre o TTL, vale insistir porque quase ninguém faz: reduzir de algumas horas para poucos minutos, dois dias antes, é o que transforma uma propagação demorada em uma transição quase imperceptível.

Fase 2 — Montagem e teste do novo ambiente

Aqui o novo ambiente é construído em paralelo, com o site antigo ainda atendendo normalmente.

1. Transfira arquivos e banco de dados para o novo servidor.
2. Configure o ambiente: versão de linguagem, extensões, limites de execução, regras de reescrita.
3. Teste com um endereço provisório, usando um domínio temporário do provedor ou uma configuração local que aponte apenas a sua máquina para o novo servidor. Assim você navega no ambiente novo enquanto o mundo continua vendo o antigo.
4. Percorra o site inteiro: páginas principais, formulários, área administrativa, upload de arquivos, integrações e — se houver — o fluxo completo de compra.
5. Prepare o certificado para o domínio no novo ambiente, para que o HTTPS funcione desde o primeiro instante após a virada.
6. Configure as tarefas agendadas, mas mantenha desativadas até a virada, para que não executem em duplicidade.

O item 6 merece atenção: tarefas rodando nos dois servidores ao mesmo tempo produzem e-mails duplicados, cobranças repetidas e sincronizações conflitantes.

Fase 3 — E-mail, que exige tratamento próprio

Esta é a parte que mais dá errado, e por um motivo específico: a falha é silenciosa. Um site fora do ar todo mundo percebe; um e-mail que não chegou, não.

A ordem correta:

1. Crie as contas no novo servidor com os mesmos endereços, antes de qualquer alteração.
2. Transfira o histórico de mensagens e pastas. Ferramentas de migração de caixas fazem isso enquanto o serviço antigo continua ativo.
3. Altere os registros MX apenas depois da transferência concluída.
4. Mantenha o serviço antigo ativo por alguns dias, porque servidores que ainda não perceberam a mudança continuarão entregando lá.
5. Faça uma sincronização final das mensagens recebidas nesse intervalo, antes de encerrar o serviço anterior.
6. Reconfigure os dispositivos dos usuários, avisando com antecedência que isso será necessário.

E um item que não é migração, mas é o momento certo de tratar: os registros de autenticação do domínio. Trocar de servidor de envio sem atualizar SPF, DKIM e DMARC faz mensagens legítimas irem para o spam — assunto do artigo sobre e-mails caindo no spam.

Fase 4 — A virada e o que acontece na propagação

Chegou o momento de apontar o domínio. Vale entender exatamente o que ocorre, porque a propagação é mal compreendida.

Quando você altera o DNS, a mudança não chega a todo mundo ao mesmo tempo. Servidores espalhados pela internet mantêm a informação anterior em cache pelo tempo definido no TTL. Durante esse intervalo, parte dos visitantes é atendida pelo servidor antigo e parte pelo novo.

A consequência prática é importante: os dois ambientes recebem tráfego simultaneamente por algum tempo. Se ambos aceitam alterações — pedidos, cadastros, comentários, formulários —, você terá dois conjuntos de dados para reconciliar.

O procedimento que resolve:

1. Congele alterações no ambiente antigo pouco antes da virada — sem publicar conteúdo, sem receber dados novos, se possível.
2. Faça uma sincronização final do banco de dados e dos arquivos enviados desde a transferência inicial.
3. Ative as tarefas agendadas no novo ambiente e desative no antigo.
4. Altere o DNS, apontando o domínio para o novo servidor.
5. Acompanhe as primeiras horas, verificando se as requisições chegam ao ambiente novo e se não há erros.
6. Restaure o TTL para um valor normal depois que a propagação se completar.

Com o TTL reduzido previamente, essa janela costuma ser de minutos. Sem essa preparação, pode durar muitas horas — e é daí que vem a fama ruim das migrações.

Depois da virada

A migração não termina quando o site carrega. Uma checagem nos dias seguintes:

• HTTPS funcionando em todas as páginas, sem avisos de conteúdo misto.
• Formulários enviando e as mensagens chegando ao destino correto.
• E-mails entrando e saindo, com envio testado para provedores diferentes.
• Redirecionamentos preservados, especialmente os que sustentam posições em buscadores.
• Tarefas agendadas executando no novo ambiente e não no antigo.
• Desempenho comparável ou melhor, medido com a mesma ferramenta usada antes.
• Erros no log, que costumam revelar dependências esquecidas.
• Integrações respondendo, sobretudo as que usam endereço de IP em listas de permissão — este é um esquecimento clássico, já que o IP muda com o servidor.

Mantenha o ambiente antigo ativo por pelo menos uma semana, sem receber tráfego. É o caminho de volta, e ele custa pouco perto do que evita.

Os erros que mais aparecem

Erro	Consequência
Apontar o DNS antes de transferir	Site fora do ar ou incompleto
Não reduzir o TTL antes	Propagação longa e imprevisível
Migrar e-mail depois do site	Mensagens perdidas sem aviso
Esquecer as tarefas agendadas	Execuções duplicadas ou nenhuma
Não sincronizar o banco antes da virada	Perda dos dados do intervalo
Cancelar o plano antigo no mesmo dia	Sem caminho de volta
Ignorar listas de permissão por IP	Integrações silenciosamente quebradas
Migrar em véspera de campanha	Risco concentrado no pior momento

Quando pedir ajuda

Alguns cenários aumentam bastante a complexidade e justificam apoio especializado — do próprio provedor, quando ele oferece, ou de um profissional:

• Muitas contas de e-mail com histórico extenso.
• Aplicações com configuração própria no servidor.
• Lojas virtuais com pedidos entrando continuamente.
• Vários sites no mesmo ambiente.
• Ambiente atual com acesso limitado ou documentação inexistente.

Vale confirmar antecipadamente se o novo fornecedor apoia a migração e o que exatamente esse apoio cobre — é um dos critérios que tratamos no artigo sobre como escolher uma hospedagem.

Conclusão

Migrar de hospedagem sem sair do ar depende menos de habilidade técnica e mais de ordem: preparar tudo com o site antigo ainda funcionando, testar o novo ambiente antes de qualquer alteração de domínio, tratar o e-mail com cuidado próprio e só então virar o DNS.

Dois cuidados respondem pela maior parte do resultado: reduzir o TTL com pelo menos 48 horas de antecedência e manter o ambiente anterior ativo por alguns dias depois da virada. Ambos são baratos e é justamente por isso que costumam ser dispensados.

Se você está avaliando para onde migrar, conheça os planos de hospedagem de sites da TBF Host e verifique o apoio disponível para a transferência do seu ambiente atual.

Perguntas frequentes

Como migrar de hospedagem sem o site sair do ar?

Montando o novo ambiente em paralelo, com o site antigo ainda funcionando. Transfira arquivos, banco e e-mails, teste o ambiente novo com um endereço provisório, reduza o TTL do DNS com antecedência e só então aponte o domínio. Os dois ambientes coexistem durante a transição, o que preserva o caminho de volta.

O que é propagação de DNS e quanto tempo demora?

É o intervalo em que servidores pela internet ainda mantêm em cache a informação anterior sobre para onde o domínio aponta. A duração depende do TTL configurado: se ele for reduzido para poucos minutos com pelo menos 48 horas de antecedência, a virada costuma levar minutos. Sem essa preparação, pode durar muitas horas.

Devo migrar o site ou o e-mail primeiro?

O e-mail exige tratamento próprio e não deve ficar para depois. Crie as contas no novo servidor, transfira o histórico enquanto o serviço antigo continua ativo e só então altere os registros MX. Mantenha o serviço anterior ligado por alguns dias e faça uma sincronização final antes de encerrá-lo.

Vou perder e-mails durante a migração?

Não, se a ordem for respeitada. Perdas acontecem quando os registros MX são alterados antes da transferência do histórico ou quando o serviço antigo é encerrado cedo demais — servidores que ainda não perceberam a mudança continuam entregando lá por algum tempo.

Por que devo reduzir o TTL antes de migrar?

Porque o TTL define por quanto tempo a informação antiga de DNS permanece em cache. Reduzi-lo para poucos minutos, com pelo menos 48 horas de antecedência, faz com que a mudança se propague rapidamente na virada. É o passo técnico mais importante e o mais esquecido em migrações.

Posso cancelar o plano antigo logo após a migração?

Não é recomendável. Mantenha o ambiente anterior ativo por pelo menos uma semana, sem receber tráfego, como caminho de volta. Também é nesse período que se faz a sincronização final das mensagens de e-mail que ainda chegaram ao servidor antigo durante a propagação.

O que pode quebrar depois de migrar de hospedagem?

Os pontos mais comuns são certificado HTTPS não configurado no novo ambiente, formulários enviando para o destino errado, redirecionamentos perdidos, tarefas agendadas executando no servidor errado e integrações que usam listas de permissão por endereço de IP — que mudam com o servidor e falham silenciosamente.

Quando vale a pena pedir ajuda para migrar?

Quando há muitas contas de e-mail com histórico extenso, aplicações com configuração própria no servidor, lojas com pedidos entrando continuamente, vários sites no mesmo ambiente ou quando o ambiente atual tem acesso limitado e nenhuma documentação.