Como fazer migração de site: roteiro em 5 etapas

Roteiro de execução para migrar um site: o que fazer na semana anterior, na véspera, no dia da troca e na primeira semana, com comandos e conferências.

Por Redação Eleven Host · @robson.direitodigital · Atualizado em 18 de outubro de 2026 · 9 min de leitura

Como fazer migração de site sem surpresa: siga um roteiro por data. Congele mudanças na semana anterior, copie arquivos e banco na véspera, teste o servidor novo antes de mexer no DNS e deixe o antigo ligado durante a primeira semana.

Este é o roteiro de execução, com comandos curtos e verificação em cada etapa. Para entender os tipos de migração e montar o inventário, veja o guia de conceitos sobre migração de site. Para a técnica de DNS e TTL, há o passo a passo para migrar sem tirar o site do ar. Se o site é WordPress, existe um passo a passo de migração de WordPress com os ajustes próprios dessa plataforma.

Etapa 1: semana anterior, congele e meça

A migração falha quando o site muda no meio da cópia. Combine com quem mexe nele uma data de congelamento: sem instalar plugin, sem trocar tema, sem publicar funcionalidade nova. Texto novo ainda pode entrar até a véspera, mas o dia da troca pede pausa.

Nessa semana, anote os números do site de origem. Eles serão a régua da conferência depois da cópia:

• quantidade de arquivos da pasta do site;
• tamanho total da pasta;
• lista de tabelas do banco e a contagem de linhas das tabelas que importam (pedidos, usuários, páginas);
• versões de PHP e do banco em uso no servidor atual.

No servidor de origem, os dois primeiros números saem assim (ajuste o caminho):

find /var/www/meusite -type f | wc -l

du -sh /var/www/meusite

Anote também as tarefas agendadas do servidor antigo com crontab -l e as configurações de envio de e-mail do site. Ficam fora da pasta do site e por isso são fáceis de esquecer.

Por fim, prepare o servidor novo: mesma versão de PHP e de banco (ou uma diferença que você já verificou), espaço livre maior que o site (confira com df -h) e o banco vazio criado com CREATE DATABASE nome_do_banco CHARACTER SET utf8mb4; dentro do cliente mysql.

Etapa 2: na véspera, copie arquivos e banco

Com o acesso por SSH ao servidor de origem, o rsync puxa os arquivos preservando datas e permissões. Rode no servidor novo:

rsync -avz --progress usuario@antigo.exemplo.com:/var/www/meusite/ /var/www/meusite/

A barra final no caminho de origem importa: com ela, o rsync copia o conteúdo da pasta; sem ela, cria uma pasta extra dentro do destino.

Na véspera o rsync copia tudo; no dia da troca, o mesmo comando envia só o que mudou, e a janela de congelamento fica curta.

Para o banco, gere o arquivo de exportação na pasta pessoal do usuário no servidor de origem. O -p sem valor faz o programa pedir a senha, então ela não fica no histórico do terminal:

mysqldump --single-transaction -u usuario -p nome_do_banco > meusite-2026-10-18.sql

A opção --single-transaction gera uma exportação consistente em tabelas InnoDB sem travar o site.

Leve o arquivo ao servidor novo e importe:

scp usuario@antigo.exemplo.com:meusite-2026-10-18.sql .

mysql -u usuario -p nome_do_banco < meusite-2026-10-18.sql

Depois, aponte o arquivo de configuração do site para o banco novo (nome, usuário, senha e host). O nome e o lugar desse arquivo mudam de sistema para sistema.

Etapa 3: confira se a cópia está inteira

Não confie na barra de progresso. Compare com os números anotados na etapa 1.

1. Arquivos: rode os mesmos find ... | wc -l e du -sh no servidor novo. A contagem de arquivos precisa ser igual. O tamanho pode variar um pouco entre sistemas de arquivos, então use-o como alerta, não como prova.
2. Conteúdo dos arquivos: repita o rsync em modo de simulação com comparação por checksum: rsync -avnc usuario@antigo.exemplo.com:/var/www/meusite/ /var/www/meusite/. O -n não copia nada e o -c compara o conteúdo. Se a lista vier vazia, os arquivos são idênticos.
3. Banco: compare a contagem de linhas das tabelas principais nos dois lados, com mysql -u usuario -p -e "SELECT COUNT(*) FROM pedidos;" nome_do_banco. Troque pedidos pelo nome real da tabela.
4. Arquivo de exportação: sha256sum meusite-2026-10-18.sql nos dois servidores precisa dar o mesmo resultado, o que prova que o arquivo não se corrompeu na viagem.

Se algum número não bater, descubra o motivo antes de seguir.

Etapa 4: teste o site novo sem mexer no DNS

Ainda na véspera, faça o seu computador acreditar que o domínio já mora no servidor novo. Isso é o arquivo hosts: uma lista local que vale antes do DNS e só afeta a sua máquina. Use o IP do servidor novo (aqui, o de exemplo 203.0.113.10).

Windows: abra o Bloco de Notas como administrador, abra o arquivo C:\Windows\System32\drivers\etc\hosts e acrescente no fim a linha de exemplo mostrada depois destes dois parágrafos. Salve e, no Prompt de Comando, rode ipconfig /flushdns.

Linux e macOS: rode sudo nano /etc/hosts, acrescente a mesma linha e salve. No macOS, limpe o cache com sudo dscacheutil -flushcache e sudo killall -HUP mDNSResponder.

203.0.113.10 exemplo.com www.exemplo.com

Feche e reabra o navegador e abra o site. Navegue como cliente: página interna, busca, login e formulário. Se preferir não editar arquivo nenhum, o curl faz o teste de cabeçalho em uma linha: curl -I --resolve exemplo.com:443:203.0.113.10 https://exemplo.com. Se o certificado ainda não foi emitido no servidor novo, a conexão em https falha com erro de certificado; nesse caso teste em http: curl -I --resolve exemplo.com:80:203.0.113.10 http://exemplo.com.

Atenção ao fim do teste: apague a linha do hosts e limpe o cache de novo. Quem esquece segue vendo o servidor novo na própria máquina e não sabe se está olhando o hosts ou o DNS de verdade.

Sobre o HTTPS, a validação do certificado por HTTP exige que o domínio já aponte para o servidor novo: planeje a emissão para o dia da troca. E guarde uma cópia do que você leva, como ensina o guia de backup de site.

Precisa de um servidor novo para receber o site? Ver planos de VPS

Etapa 5: dia da troca e primeira semana

Em um horário de pouco movimento, faça nesta ordem:

1. Ative a pausa do site de origem (modo de manutenção ou bloqueio de pedidos).
2. Gere a exportação final do banco e importe no servidor novo.
3. Repita o rsync para trazer só os arquivos que mudaram.
4. Confira de novo a contagem de linhas das tabelas principais.
5. Altere o apontamento do domínio para o IP do servidor novo (registro A) no lugar onde o DNS é administrado.
6. Emita ou instale o certificado HTTPS, se ainda não o fez.
7. Retire o bloqueio e reative as tarefas agendadas.

A mudança chega aos visitantes aos poucos: pode levar de minutos a horas, conforme o TTL e os provedores. Nesse intervalo, parte das pessoas vê o servidor antigo e parte o novo, e é por isso que o antigo fica ligado.

Plano de volta

Mantenha o servidor antigo ligado e intacto, com a última exportação do banco guardada. Se algo grave aparecer, devolva o registro A ao IP anterior. Há um cuidado: se o site novo recebeu pedidos ou cadastros depois da troca, eles não existem no antigo. Por isso, em loja ou sistema com escrita constante, defina antes quem decide voltar e até que horário a volta ainda é segura.

Checklist da primeira semana

• formulários de contato enviam e a mensagem chega à caixa certa;
• e-mails de notificação do site (pedido, senha nova) saem e não caem no spam;
• tarefas agendadas rodam no horário (confira crontab -l no servidor novo);
• HTTPS ativo sem aviso de conteúdo misto;
• redirecionamentos antigos funcionam (teste duas ou três URLs que já tinham redirecionamento);
• o mapa do site e a ferramenta gratuita do Google para donos de site sem erros novos;
• integrações que liberam o IP do servidor (pagamento, API de terceiros) foram atualizadas para o IP novo.

Só desligue o servidor antigo depois dessa semana e de uma última cópia guardada fora dele.

Exemplos práticos

Site em PHP com MySQL. Um site de clínica com agendamento: rsync na véspera, exportação do banco, teste pelo hosts agendando uma consulta de teste e apagando-a depois. No dia da troca, formulário de agendamento pausado durante a janela, exportação final e troca do registro A.

Site estático. Sem banco, o roteiro encurta: rsync, conferência por checksum, teste pelo hosts e troca de DNS.

Sistema interno. Um painel que só a equipe usa e que envia relatório por e-mail toda manhã. O risco é o agendamento: se o cron ficar ligado nos dois servidores, o relatório sai duas vezes; se não for recriado, não sai. Liste também as integrações que liberam o IP antigo.

Dúvida sobre os serviços da Eleven antes da troca? Falar com a equipe

Perguntas frequentes

Quanto tempo antes devo começar o roteiro?

Comece na semana anterior, para congelar mudanças e anotar os números de conferência. A cópia em si pode ser feita na véspera.

Preciso saber usar o terminal?

Os comandos facilitam a conferência. Quem usa só SFTP e um gerenciador de banco também migra, mas precisa conferir a contagem de arquivos e de linhas pelos meios que tiver.

O arquivo hosts muda o DNS de verdade?

Não. Ele só afeta o computador em que foi editado e vale até você apagar a linha. Visitantes continuam vendo o servidor antigo.

Quando posso desligar o servidor antigo?

Depois da primeira semana com o checklist conferido e com uma cópia final guardada fora dele.

A Eleven faz a migração para mim?

O texto do site não detalha isso. Pergunte à equipe pelo contato comercial.