Como Migrar seu Site para uma Nova Hospedagem sem Downtime

Trocar de hospedagem carrega uma fama injusta de operação arriscada, daquelas que deixam o site fora do ar por horas, quebram os e-mails da empresa e derrubam posições no Google conquistadas a duras penas. Na prática, quase todo o pânico associado à migração de hospedagem nasce de um erro de sequência: mexer no DNS antes de o novo servidor estar pronto e testado. Quando a ordem das etapas é respeitada, a troca acontece de forma quase invisível para o visitante, e o famoso downtime deixa de ser uma ameaça para virar, no máximo, alguns minutos de sobreposição controlada.

Este guia trata a migração como o que ela realmente é: um projeto de logística. Não existe mágica nem um botão único que resolve tudo. Existe um método, e ele se resume a uma ideia central que vale a pena fixar desde já: você copia e valida tudo no destino antes de apontar qualquer coisa para lá. O tráfego só é redirecionado quando o novo ambiente já responde de forma idêntica ao antigo. A partir dessa lógica, cada passo a seguir se encaixa naturalmente.

Por que e quando migrar#

Antes de planejar o "como", vale entender o "por quê", porque isso define a urgência e a janela de execução. Os motivos mais comuns para trocar de hospedagem são lentidão persistente que a otimização no próprio site já não resolve, instabilidade com quedas frequentes, suporte técnico ruim que não responde em incidentes, limites de recurso estourados pelo crescimento do projeto, preço que deixou de fazer sentido, ou a necessidade de recursos que o plano atual não oferece, como versões mais novas de PHP, HTTP/2 e HTTP/3, ou infraestrutura em nuvem escalável.

Sobre o quando, há uma regra prática que evita dor de cabeça: migre em períodos de menor tráfego do seu site. Para a maioria dos negócios isso significa madrugada ou fim de semana, mas o ideal é olhar seus próprios dados de acesso. Evite migrar às vésperas de campanhas, lançamentos, datas comerciais fortes ou qualquer momento em que uma eventual instabilidade custe caro. E nunca migre com pressa de última hora porque o plano antigo vence amanhã; mantenha a hospedagem de origem ativa por pelo menos alguns dias após o corte, como rede de segurança.

Planejamento e checklist pré-migração#

A migração começa muito antes de copiar qualquer arquivo. Ela começa com um inventário honesto de tudo que compõe o seu ambiente atual. A maioria dos sites fora do ar depois da troca simplesmente esqueceu de levar alguma peça. Levante, com calma, cada um destes itens:

• Arquivos do site: todo o conteúdo público (a raiz web), temas, plugins, uploads, bibliotecas e quaisquer scripts fora do diretório principal. Verifique também arquivos ocultos como .htaccess, que costumam guardar regras críticas de redirecionamento e segurança.
• Banco de dados: normalmente MySQL ou MariaDB no caso de sites em WordPress e na maioria dos CMS. Anote nome do banco, usuário, senha e host, além de eventuais bancos secundários.
• Contas de e-mail: liste todas as caixas associadas ao domínio, o volume de mensagens armazenadas e o protocolo usado (IMAP guarda tudo no servidor; POP3 pode ter baixado mensagens para os dispositivos). E-mail é a parte mais delicada da migração e a mais esquecida.
• Registros DNS: exporte a zona DNS completa. Não são só os registros A do site: há MX (e-mail), TXT de SPF, DKIM e DMARC, CNAME de subdomínios e serviços de terceiros, além de eventuais registros de verificação. Perder um TXT de SPF significa e-mails caindo em spam no dia seguinte.
• Certificados SSL: identifique se o certificado atual é um Let's Encrypt gratuito (que será simplesmente reemitido no destino) ou um certificado pago com validação estendida, que talvez precise ser reinstalado ou reemitido.
• Configurações específicas: versão de PHP, extensões habilitadas, tarefas agendadas (cron jobs), variáveis de ambiente, regras de firewall e qualquer serviço externo que aponte para o seu servidor por IP.

Com esse inventário em mãos, contrate e prepare o plano de destino garantindo que ele suporta a mesma versão de linguagem e as mesmas extensões. Um site que roda numa versão de PHP e cai numa incompatível no destino é uma das causas clássicas de tela branca depois da migração.

Baixe o TTL com antecedência#

Este é o passo mais negligenciado e, ao mesmo tempo, o que mais reduz o downtime. O TTL (Time To Live) é o tempo, em segundos, que os servidores DNS espalhados pela internet guardam em cache a resposta de um registro seu antes de perguntar de novo. Se o seu registro A tem TTL de 86400 segundos (24 horas), parte dos visitantes pode continuar sendo enviada ao servidor antigo por até um dia inteiro depois que você mudar o apontamento.

A solução é simples e precisa ser feita com antecedência. Reduza o TTL dos registros que você vai alterar (tipicamente o A e o MX) para um valor baixo, como 300 segundos (5 minutos), pelo menos 24 a 48 horas antes do corte. Assim, quando chegar a hora de virar a chave, a propagação da mudança acontece em minutos, não em horas. Depois que a migração estiver estável, você volta o TTL para um valor mais alto, o que melhora desempenho e reduz consultas desnecessárias.

A ordem correta: copie tudo antes de tocar no DNS#

Aqui está o coração do método e a razão pela qual downtime deixa de existir. A regra é inflexível: o novo servidor precisa estar 100% pronto, populado e testado antes de qualquer alteração de DNS. Durante toda a fase de cópia e validação, o site antigo continua no ar, atendendo os visitantes normalmente, sem que ninguém perceba que uma migração está em andamento nos bastidores.

Migração dos arquivos#

Transfira todo o conteúdo inventariado para o novo servidor. Para volumes pequenos, um cliente FTP/SFTP resolve; para sites grandes ou com muitos arquivos pequenos, compactar tudo em um único arquivo e transferi-lo é muito mais rápido e confiável do que enviar milhares de arquivos individualmente. Muitos painéis de hospedagem oferecem ferramentas de importação, e vários plugins de migração populares para WordPress automatizam a cópia de arquivos e banco de uma vez. Use-os quando fizerem sentido, mas entenda o que fazem por baixo: no fim, é sempre a mesma tríade de arquivos, banco e configuração.

Migração do banco de dados#

Exporte o banco da origem em um arquivo de dump e importe-o no servidor de destino, criando lá um banco novo com seu próprio usuário e senha. O ponto de atenção é o arquivo de configuração do site (no WordPress, o wp-config.php; em outros sistemas, o equivalente), que precisa ser atualizado com as novas credenciais e o novo host do banco. Se o endereço do site estiver gravado dentro do banco, como acontece no WordPress, e você estiver testando por um domínio provisório, pode ser necessário ajustar essas referências temporariamente, sempre com uma busca-e-substituição que respeite os dados serializados.

Teste antes de virar a chave#

Com arquivos e banco no destino, você precisa ver o site rodando no novo servidor antes de o mundo ver. Há duas formas seguras de fazer isso sem tocar no DNS público:

• Arquivo hosts: no seu próprio computador, edite o arquivo hosts do sistema operacional para apontar o seu domínio ao IP do novo servidor. Só a sua máquina passa a "enxergar" o site no destino; o resto do mundo continua no servidor antigo. É o método mais fiel, porque testa o domínio real.
• Domínio ou URL temporário: muitas hospedagens fornecem um endereço provisório de pré-visualização, ou você aponta um subdomínio de teste ao novo IP. É prático, mas com sistemas que gravam a URL no banco, exige os ajustes mencionados acima.

Nesse teste, valide tudo com rigor: páginas internas, formulários, área administrativa, envio de e-mail transacional, imagens carregando, funcionalidade de busca e, se houver, o fluxo de compra completo. É aqui, com o site antigo ainda protegendo seus visitantes, que você descobre e corrige qualquer incompatibilidade. Nada de pressa: essa etapa é a que compra a sua tranquilidade.

Valide o SSL no destino#

Antes do corte, garanta que o certificado SSL já esteja provisionado e válido no novo servidor. Certificados Let's Encrypt gratuitos costumam ser emitidos automaticamente pelo painel assim que o domínio aponta para o servidor, mas alguns provedores permitem pré-emitir ou preparar o certificado antecipadamente. Se o seu certificado for pago, reinstale-o ou reemita-o no destino com antecedência. O objetivo é que, no exato instante em que o tráfego começar a chegar ao novo servidor, o cadeado já esteja no lugar, sem aquele intervalo desconfortável em que o navegador acusa conexão não segura.

Cuidados com o e-mail durante a troca de MX#

O e-mail merece um capítulo próprio porque é onde as migrações mais silenciosamente falham. Um site fora do ar por dez minutos é constrangedor; um e-mail de cliente perdido é um problema de negócio real.

Se você usa e-mail no mesmo servidor de hospedagem e vai levá-lo junto, replique as contas no destino primeiro, com os mesmos nomes e senhas, e migre as mensagens armazenadas (via IMAP, sincronizando caixa a caixa) antes de mexer no registro MX. Durante a janela de propagação do MX, mensagens novas podem chegar tanto ao servidor antigo quanto ao novo, dependendo de qual resposta DNS cada remetente ainda tem em cache. Por isso, mantenha as duas caixas ativas e acessíveis por alguns dias e faça uma sincronização final para não perder nada que tenha caído no servidor antigo durante a transição.

Uma decisão estratégica que simplifica muito a vida: considere manter o e-mail em um serviço dedicado, separado da hospedagem do site. Assim, quando você trocar a hospedagem no futuro, os registros MX nem precisam ser tocados, e o e-mail fica imune à migração. Se optar por migrar tudo junto, não se esqueça dos registros SPF, DKIM e DMARC: eles precisam refletir o novo servidor de envio, sob pena de suas mensagens legítimas começarem a ser marcadas como spam logo após a troca.

O corte final: nameservers e registros A#

Chegado o momento em que o destino está copiado, testado, com SSL válido e e-mails replicados, o corte é a parte mais rápida e menos dramática de todo o processo, justamente porque tudo já foi feito. Você tem duas maneiras de apontar o domínio para o novo servidor:

• Trocar os nameservers: você aponta o domínio, no registrador, para os servidores DNS da nova hospedagem. É mais simples, porque a nova hospedagem passa a gerenciar toda a zona DNS, mas exige que você recrie manualmente todos os registros (MX, TXT, CNAME) do inventário na nova zona antes da troca. Esqueça um só e algo quebra.
• Alterar apenas os registros A: se você mantém o DNS em um provedor independente (como um serviço de DNS dedicado), basta editar o registro A (e o AAAA, se houver IPv6) para o novo IP. É mais cirúrgico e preserva todo o resto da zona intacto, sendo a opção preferida por quem quer controle fino sobre a propagação.

Graças ao TTL baixado com antecedência, a mudança se propaga em minutos. E aqui entra o conceito que sela a ausência de downtime: o período de dupla operação. Durante a propagação, parte dos visitantes ainda será atendida pelo servidor antigo e parte já pelo novo. Como ambos estão idênticos e funcionando, nenhum usuário percebe diferença. Por isso é essencial não desligar nada na origem imediatamente. Mantenha o servidor antigo intacto por vários dias, com os arquivos e o banco preservados, até ter certeza absoluta de que 100% do tráfego já migrou e de que nenhum e-mail novo está mais chegando à caixa antiga.

Pós-migração: o que validar depois do corte#

Assim que a propagação avançar, faça uma última rodada de verificação, agora em produção real: confirme que o SSL está ativo em todas as páginas, teste envio e recebimento de e-mails, verifique os formulários, revise os redirecionamentos do .htaccess, cheque as tarefas agendadas rodando no novo ambiente e acompanhe os logs de erro nas primeiras horas. Ferramentas de propagação DNS ajudam a confirmar que a mudança já é vista de várias regiões do mundo. Só depois de tudo confirmado e de esgotada a janela de segurança é que você restaura o TTL para um valor mais alto e, por fim, cancela o plano antigo.

A escolha do destino também pesa no resultado, e vale entender as diferenças entre os principais tipos de hospedagem web antes de decidir para onde levar o seu projeto, já que o ambiente certo evita que você precise migrar de novo em pouco tempo.

Conclusão#

Migrar sem downtime não é sorte nem privilégio de especialistas: é o resultado direto de respeitar a sequência. Inventarie tudo, baixe o TTL com antecedência, copie e teste o site inteiro no novo servidor enquanto o antigo segue no ar, valide o SSL, cuide do e-mail com atenção redobrada, faça o corte apoiado na dupla operação e só desligue a origem quando tiver certeza. Cada uma dessas etapas existe para eliminar uma forma específica de indisponibilidade. Feitas na ordem, elas transformam um evento temido em uma operação rotineira e previsível, o tipo de troca que o seu visitante nunca chega a notar.