Migrar hospedagem sem perder dados nem deixar o site fora do ar

Para migrar um site para outra hospedagem sem quedas nem perda de dados, copie os arquivos, o banco de dados e os e-mails enquanto a hospedagem antiga continua no ar, teste a cópia pelo arquivo hosts ou com curl --resolve e só depois altere o DNS. Mantenha a hospedagem antiga ativa até expirarem todos os caches DNS: alguns minutos se você mudar um registro A com TTL 300, até 48 horas se mudar os nameservers de um domínio .com, e esse prazo não pode ser encurtado.

Inventário: o que saber antes da migração

A maioria dos problemas depois de uma migração acontece porque algo ficou fora da lista. Antes da primeira exportação, anote:

• Arquivos: tamanho total e quantidade de arquivos (du -sh, find . -type f | wc -l). Muitos planos limitam não só o espaço, mas também o número de arquivos (inodes).
• Banco de dados: nome, tamanho, servidor e versão (SELECT VERSION(); no phpMyAdmin). MySQL e MariaDB não são compatíveis em todas as versões.
• PHP: versão atual e extensões necessárias.
• E-mail: todas as caixas, encaminhamentos e aliases do domínio.
• Zona DNS: todos os registros, não só A e MX: SPF, DKIM, DMARC, o CNAME do www e os TXT de verificação de serviços.
• SSL: quem emite o certificado. O Let’s Encrypt é emitido de novo no servidor novo; um certificado pago vai junto com a chave privada. Mais detalhes no artigo sobre quanto custa um certificado SSL.
• Tarefas cron, .htaccess e redirecionamentos, além de licenças de plugins ou temas vinculadas ao domínio ou ao IP.

Escolher a nova hospedagem: o que conferir antes de pagar

Promessas de marketing ajudam pouco; o que vale são as condições do plano e os termos de uso. Compare estes pontos com o seu inventário:

Para comparação, as características da RichHost: armazenamento NVMe, tráfego ilimitado, sites e caixas de e-mail ilimitados, painel de controle próprio com assistente de IA, SSL gratuito Let’s Encrypt e servidores na Europa e nos EUA. Os planos de hospedagem começam em 8 USD por mês. A migração para a RichHost é gratuita.

Registro A ou nameservers: o que mudar e em quanto tempo vale

O TTL de um registro DNS define por quanto tempo os resolvers podem guardar a resposta antiga em cache. O que importa é qual registro você altera:

O TTL da delegação é definido pelo registro do domínio de topo. Nas nossas medições com dig +trace em outubro de 2026, ele era de 172.800 segundos (até 48 horas) para .com e .net, 3.600 segundos para .org e 86.400 segundos para .pl e .eu. Baixar o TTL na zona antiga não muda isso. Por isso, durante uma troca de nameservers, os dois servidores precisam servir o mesmo site e as mesmas caixas de e-mail. Os passos no registrador estão no nosso guia para alterar os DNS do domínio.

A ordem certa dos passos

1. Baixe o TTL. Se for mudar o registro A, coloque o TTL em 300 segundos com pelo menos um período do TTL antigo de antecedência: se era 86.400 segundos, 24 horas antes.
2. Copie tudo. Arquivos, banco de dados, caixas de e-mail e tarefas cron. Confira o arquivo compactado no servidor novo com uma soma de verificação (comandos abaixo).
3. Teste a cópia sem mexer no DNS: pelo arquivo hosts ou com curl --resolve.
4. Congele as alterações e faça a troca. Pause pedidos, comentários e publicações nos últimos minutos, transfira o banco de dados uma última vez e então mude o registro A ou os nameservers.
5. Mantenha a hospedagem antiga no ar. No mínimo até o TTL expirar, ou seja, 48 horas para nameservers de um .com. Recomendamos cancelar só depois de cerca de duas semanas: até lá dá para voltar atrás em minutos.

Para WordPress há um guia passo a passo próprio: migrar o WordPress para outra hospedagem, com plugin ou manualmente.

Testar antes da troca: arquivo hosts e curl --resolve

Com uma linha no arquivo hosts, só o seu computador já vê o site no servidor novo; todos os outros visitantes continuam chegando ao antigo. No Linux e no macOS o arquivo fica em /etc/hosts, no Windows em C:\Windows\System32\drivers\etc\hosts (edite como administrador). Troque o IP de exemplo pelo IP do servidor novo:

203.0.113.10  example.com www.example.com

Sem alterar o arquivo hosts, dá para usar o curl: a opção --resolve conecta ao IP indicado, mas envia o nome de domínio correto (cabeçalho Host e SNI).

curl -sI --resolve example.com:443:203.0.113.10 https://example.com/
curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/

Foi assim o teste no nosso servidor de teste local, que devolve o cabeçalho Host recebido:

$ curl -sS --resolve example.com:8080:127.0.0.1 http://example.com:8080/
new server, Host=example.com:8080

Conte com um aviso de certificado durante o teste: o Let’s Encrypt normalmente valida o domínio por HTTP, e isso só funciona quando o DNS já aponta para o servidor novo. Depois confira a página inicial, o login, os formulários, o upload de arquivos, a busca, o carrinho e o envio de e-mails pelo site, de preferência também no celular.

O que mais quebra depois da migração

É assim que o PHP 8.3 avisa sobre a chamada de uma função removida (nosso teste, saída resumida):

$ php -r '$a=[1]; each($a);'
PHP Fatal error:  Uncaught Error: Call to undefined function each() in Command line code:1

Segundo o php.net, em 30/10/2026 só o PHP 8.2 a 8.5 ainda recebe atualizações de segurança, e o suporte do 8.2 termina em 31/12/2026. Uma versão antiga do PHP é, portanto, só uma solução provisória. Para as permissões, a documentação do WordPress recomenda 755 para pastas, 644 para arquivos e 440 ou 400 para o wp-config.php:

find public_html -type d -exec chmod 755 {} +
find public_html -type f -exec chmod 644 {} +

O MariaDB anuncia na documentação o suporte às collations utf8mb4_0900_* do MySQL 8.0 a partir da versão 11.4.5; versões anteriores recusam esses dumps. Em caso de falha no banco, veja o nosso guia sobre o erro de conexão com o banco de dados, e para e-mail, o resumo das configurações IMAP e SMTP.

Backups e plano para voltar atrás

Um backup só vale se você conseguir restaurá-lo. Antes da migração, salve os arquivos, o banco de dados, as tarefas cron e a exportação da zona DNS, e guarde pelo menos uma cópia fora dos dois servidores, por exemplo no seu computador ou num armazenamento em nuvem.

tar -czf site.tar.gz public_html
sha256sum site.tar.gz > site.tar.gz.sha256
sha256sum -c site.tar.gz.sha256
mysqldump --single-transaction -u DB_USER -p DB_NAME > db.sql
crontab -l > crontab.txt

Com sha256sum -c no servidor novo você confere se o arquivo chegou inteiro; no nosso teste a saída foi site.tar.gz: OK. O plano de volta é simples: enquanto a hospedagem antiga estiver no ar, se algo der errado, você volta o DNS anterior. Se endereços mudarem na migração, você também vai precisar de um redirecionamento 301.

Como verificamos: em 30/10/2026 executamos o método do curl --resolve num servidor de teste local (curl 8.5.0), testamos as chamadas a each() e mysql_connect() no PHP 8.3.6 (CLI) e conferimos com tar e sha256sum um arquivo de teste de cerca de 5 MB. Os TTL de delegação vêm das nossas medições com dig +trace de outubro de 2026. O suporte do PHP foi consultado em php.net/supported-versions.php, as permissões na documentação do WordPress (Advanced Administration) e as collations na documentação do MariaDB, em 30/10/2026. O comando mysqldump não foi executado neste teste.

Perguntas frequentes

Quanto tempo leva uma migração de hospedagem?

A cópia depende do tamanho do site. A troca em si leva alguns minutos com um registro A e TTL 300, e até 48 horas com uma troca de nameservers num .com.

Vou perder posições no Google?

Não, desde que as URLs, o conteúdo e o HTTPS continuem iguais e o site não fique fora do ar por muito tempo. Se os endereços mudarem, redirecionamentos 301 são obrigatórios.

Quando posso cancelar a hospedagem antiga?

No mínimo depois que os caches DNS expirarem e o site, os formulários, o e-mail e os backups estiverem funcionando no servidor novo. Recomendamos uma folga de cerca de duas semanas.

Preciso transferir o domínio também?

Não. O registro do domínio e a hospedagem são independentes: para migrar, basta mudar o registro A ou os nameservers. Trocar de registrador é um processo separado.

Conclusão

Migrar sem quedas é principalmente uma questão de ordem: primeiro copiar e testar, depois fazer a troca, e desligar a hospedagem antiga só quando nenhum resolver lembrar mais o endereço antigo. Sabendo de antemão se você vai mudar um registro A ou os nameservers, também dá para planejar um prazo realista.