Como migrar seu site de outra hospedagem pra uma VPS Hostini
Guia técnico pra migrar site WordPress, PHP ou estático de hospedagem compartilhada (Hostgator, Locaweb, Kinghost) pra VPS Hostini sem downtime.
Migrar um site de hospedagem compartilhada pra uma VPS é um upgrade comum: você sai de um ambiente com recursos compartilhados, regras opacas de CPU/memória e painéis genéricos pra uma máquina dedicada onde controla o stack inteiro. O ganho de performance é real, mas o processo de migração tem armadilhas — DNS mal configurado derruba o site, banco exportado errado corrompe dados, e arquivos faltando quebram o tema do WordPress.
Este tutorial cobre o caminho completo pra migrar de provedores como Hostgator, Locaweb, Kinghost, HostMídia ou similares pra uma VPS Hostini com Ubuntu 24.04. O foco é em sites PHP/MySQL (WordPress, Magento, Laravel, sites estáticos com formulários), mas o processo se aplica a qualquer stack web. Reserve entre 2 e 4 horas pra execução completa numa primeira tentativa, e leia o tutorial inteiro antes de começar — alguns passos precisam ser preparados em paralelo.
A estratégia geral é: subir o site na VPS em paralelo ao antigo, validar tudo via arquivo hosts local, e só então alterar o DNS. Assim você nunca fica com o site fora do ar e tem rollback imediato caso algo dê errado.
Pré-requisitos
VPS Hostini provisionada com Ubuntu 24.04 LTS e acesso SSH como root. Acesso ao painel da hospedagem antiga (cPanel, Plesk ou painel proprietário) com permissão pra criar backups e exportar o banco. Acesso ao painel do seu registrador de domínio (Registro.br, GoDaddy, etc) pra alterar os nameservers ou registros A. Cliente SSH local (Terminal no Linux/macOS, ou Windows Terminal com OpenSSH).
Anote os dados da VPS antes de começar — você vai usar várias vezes:
45.xxx.xxx.xxx root 22 Ubuntu 24.04 LTS Inventário do site atual
Antes de tocar em qualquer coisa, mapeie o que existe na hospedagem antiga. Faltar um arquivo de configuração ou uma tabela do banco no meio da migração custa horas de retrabalho.
Liste todos os domínios, subdomínios e aplicações hospedadas. No cPanel, isso aparece em “Domínios” e “Subdomínios”. Anote também a versão do PHP que cada aplicação roda — sites legados podem precisar de PHP 7.4 ou 8.0, enquanto WordPress recente roda em PHP 8.2+.
Identifique os bancos de dados ativos. No phpMyAdmin, anote o nome de cada banco e o tamanho aproximado. Bancos acima de 1 GB precisam de exportação por linha de comando — phpMyAdmin trava em arquivos grandes.
Anote credenciais externas que o site usa: APIs de pagamento, SMTP, integrações com CRM. Essas credenciais vão precisar ser revalidadas no destino — algumas APIs travam o acesso quando o IP de origem muda.
Backup completo da origem
O backup é o ponto de não-retorno. Verifique cada arquivo gerado antes de prosseguir.
Conecte via SSH à hospedagem antiga (se tiver acesso) e gere um arquivo compactado do diretório público:
cd ~
tar czf site-backup.tar.gz public_html/Isso cria um arquivo único contendo toda a estrutura do site. Em hospedagens com cPanel, o diretório padrão é public_html — em outros painéis pode ser httpdocs, www ou similar.
Exporte o banco de dados via mysqldump:
mysqldump -u usuario_db -p nome_do_banco > banco.sqlSe a hospedagem não permite mysqldump direto, use o phpMyAdmin: selecione o banco, vá em “Exportar”, escolha formato SQL e marque “Adicionar DROP TABLE” — isso garante que a reimportação funcione mesmo se o banco de destino já tiver tabelas vazias.
Confira que site-backup.tar.gz e banco.sql não estão truncados. Um ls -lh revela o tamanho — se banco.sql está com 0 bytes ou muito menor que o esperado, a exportação falhou silenciosamente (comum quando o tempo de execução do PHP estoura em bancos grandes).
Baixe os arquivos pro seu computador local com scp (ou via o gerenciador de arquivos do painel se não tiver SSH):
scp [email protected]:~/site-backup.tar.gz ./
scp [email protected]:~/banco.sql ./Preparação da VPS Hostini
Com o backup em mãos, instale o stack mínimo na VPS antes de subir os arquivos. Pra WordPress e a maioria dos sites PHP, isso significa nginx, PHP-FPM e MySQL.
Conecte na VPS e atualize o sistema:
ssh [email protected]
apt update && apt upgrade -yInstale o stack web completo:
apt install -y nginx mysql-server php8.3-fpm php8.3-mysql \
php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip \
certbot python3-certbot-nginx unzipEsse conjunto cobre 95% dos sites PHP em produção. Se o seu CMS exige extensões específicas (imagick, redis, memcached), instale junto.
Configure o MySQL com senha forte:
mysql_secure_installationResponda “Y” em todas as opções de segurança. Anote a senha do root do MySQL — você vai precisar.
Transferência dos arquivos
Envie os arquivos do seu computador local pra VPS:
scp site-backup.tar.gz [email protected]:/var/www/
scp banco.sql [email protected]:/root/Em conexões lentas, considere comprimir o .sql antes de enviar: gzip banco.sql reduz o arquivo em 70-80% pra bancos com dados de texto.
Na VPS, extraia o site no diretório web:
cd /var/www/
tar xzf site-backup.tar.gz
mv public_html seusite.com.br
chown -R www-data:www-data seusite.com.br
chmod -R 755 seusite.com.brCrie o banco de dados e importe o dump:
mysql -u root -pDentro do prompt do MySQL:
CREATE DATABASE seusite CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'seusite_app'@'localhost' IDENTIFIED BY 'senha_forte_aqui';
GRANT ALL PRIVILEGES ON seusite.* TO 'seusite_app'@'localhost';
FLUSH PRIVILEGES;
EXIT;Importe o dump:
mysql -u root -p seusite < /root/banco.sqlAtualize as credenciais do banco no arquivo de configuração do site. Pra WordPress, edite wp-config.php:
nano /var/www/seusite.com.br/wp-config.phpAjuste DB_NAME, DB_USER e DB_PASSWORD pros valores criados no passo anterior. Pra Laravel ou outros frameworks, edite o .env correspondente.
Configuração do nginx
Crie o arquivo de configuração do site:
nano /etc/nginx/sites-available/seusite.com.brCole a configuração base:
server {
listen 80;
server_name seusite.com.br www.seusite.com.br;
root /var/www/seusite.com.br;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
location ~ /\.ht {
deny all;
}
}Ative o site e teste a configuração:
ln -s /etc/nginx/sites-available/seusite.com.br /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginxO nginx -t valida a sintaxe antes do reload — sempre rode isso. Erro de sintaxe num arquivo de config derruba todos os sites servidos pelo nginx.
Validação antes do DNS
Edite /etc/hosts no seu computador (ou C:\Windows\System32\drivers\etc\hosts no Windows) e adicione uma linha mapeando o domínio pro IP da VPS. Assim só o seu navegador resolve o domínio pra VPS nova — visitantes continuam vendo a versão antiga. Isso permite testar tudo sem expor a migração.
Adicione no arquivo hosts:
45.xxx.xxx.xxx seusite.com.br www.seusite.com.br
Abra http://seusite.com.br no navegador. Se o site carregar corretamente, navegue por todas as páginas principais, faça login no painel admin (se for CMS) e teste formulários. Erros visuais nessa etapa indicam arquivos faltando — verifique permissões em /var/www/seusite.com.br/wp-content/uploads/ ou equivalente.
HTTPS antes do DNS apontar
Gere o certificado SSL via Let’s Encrypt. Como o DNS ainda aponta pra hospedagem antiga, use o modo manual de validação por DNS:
certbot certonly --manual --preferred-challenges dns \
-d seusite.com.br -d www.seusite.com.brO certbot vai pedir pra você criar registros TXT no seu DNS. Crie no painel do registrador, espere a propagação (geralmente 1-5 minutos), e confirme no certbot.
Atualize o nginx pra usar SSL. Edite o arquivo de configuração e troque o bloco server por:
server {
listen 443 ssl http2;
server_name seusite.com.br www.seusite.com.br;
ssl_certificate /etc/letsencrypt/live/seusite.com.br/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/seusite.com.br/privkey.pem;
root /var/www/seusite.com.br;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
}
server {
listen 80;
server_name seusite.com.br www.seusite.com.br;
return 301 https://$host$request_uri;
}Recarregue o nginx: systemctl reload nginx.
Mudança do DNS
Com tudo validado, é hora de apontar o domínio pra VPS. Acesse o painel do registrador (Registro.br pra .com.br, ou outro) e altere o registro A do domínio pro IP da VPS.
Se possível, baixe o TTL do registro A pra 300 segundos algumas horas antes da mudança. Isso reduz o tempo de propagação — em vez de horas, a mudança aparece em minutos pra maioria dos visitantes.
Remova a entrada do /etc/hosts local pra testar a resolução real. Use ferramentas como dig seusite.com.br +short (Linux/macOS) pra verificar que o IP correto está propagando.
Verificação
Após a propagação do DNS, valide o ambiente em produção:
curl -I https://seusite.com.br
A resposta deve mostrar HTTP/2 200 e headers de SSL válidos. Verifique também no SSL Labs (ssllabs.com/ssltest/) que o grau do certificado é A ou A+.
Monitore o site nas primeiras 48 horas: logs do nginx em /var/log/nginx/access.log revelam erros 500, e o Google Search Console mostra se há queda anormal de tráfego (geralmente não há, se a migração foi feita corretamente).
Resolução de problemas
Site mostra “Error establishing a database connection”
Confirme que o MySQL está rodando: systemctl status mysql. Se estiver ativo, verifique se as credenciais em wp-config.php (ou equivalente) batem com as do banco criado. Senhas com caracteres especiais às vezes precisam ser escapadas.
Imagens não aparecem ou erro 403
Permissões erradas no diretório de uploads. Rode:
chown -R www-data:www-data /var/www/seusite.com.br
find /var/www/seusite.com.br -type d -exec chmod 755 {} \;
find /var/www/seusite.com.br -type f -exec chmod 644 {} \;
Erro 502 Bad Gateway
PHP-FPM não está respondendo. Verifique com systemctl status php8.3-fpm. Confira também que o fastcgi_pass na config do nginx aponta pro socket correto da versão instalada.
Próximos passos
Com o site migrado e estável, considere adicionar camadas de robustez à sua VPS:
- Configure backups automáticos diários pra evitar perda em caso de falha de hardware.
- Adicione monitoramento de uptime (UptimeRobot, BetterUptime) pra ser alertado se o site cair.
- Habilite firewall com
ufwpermitindo apenas portas 22, 80 e 443. - Configure renovação automática do certificado SSL via cron:
certbot renew --quietsemanal. - Considere usar uma CDN (Cloudflare gratuito) na frente da VPS pra acelerar entrega e reduzir carga.
Se você está migrando vários sites de uma vez ou tem requisitos de alta disponibilidade, uma VPS Hostini oferece snapshots automáticos, IPs adicionais e proteção DDoS inclusa — útil pra evitar dor de cabeça com ataques volumétricos que derrubam hospedagens compartilhadas.
Perguntas frequentes
Quanto tempo demora a migração completa?
Pra um WordPress típico de até 5 GB com banco MySQL pequeno (< 500 MB), o processo leva entre 2 e 4 horas — incluindo backup, transferência, instalação do stack e ajuste de DNS. Sites maiores ou com várias aplicações podem precisar de uma janela de manutenção planejada.
Vou perder posicionamento no Google durante a migração?
Não, desde que você mantenha as mesmas URLs, redirecione corretamente quaisquer paths que mudarem e configure HTTPS na nova VPS antes de apontar o DNS. O Google recupera o ranking em poucos dias se o conteúdo permanecer idêntico e o servidor responder rápido.
Preciso desligar o site antigo antes de subir o novo?
Não. A prática correta é deixar o site antigo no ar enquanto sobe a cópia funcional na VPS, valida via arquivo hosts ou subdomínio temporário e só então altera o DNS. Mantenha a hospedagem antiga ativa por mais 48-72h após a propagação como segurança.
Como lido com e-mails que estavam na hospedagem compartilhada?
VPS não inclui serviço de e-mail por padrão. A recomendação é migrar e-mails pra um provedor dedicado (Google Workspace, Zoho, Microsoft 365) antes de mudar o DNS. Tente evitar montar servidor SMTP próprio em VPS nova — entregabilidade é baixa por reputação de IP.
O que faço se o site usa funções de SMTP do PHP pra enviar e-mail?
Configure o PHP pra enviar via SMTP autenticado de um provedor transacional (Amazon SES, Brevo, Mailgun, Postmark). Plugins como WP Mail SMTP no WordPress fazem isso sem alterar código. Evite a função mail() nativa em VPS — quase nunca entrega.
E se eu não tiver acesso SSH na hospedagem antiga?
Use o gerenciador de arquivos do painel pra criar um arquivo .tar.gz da public_html e baixar via HTTPS, e exporte o banco via phpMyAdmin como SQL bruto. Funciona mas é mais lento — em sites grandes, peça acesso SSH temporário ao suporte da hospedagem antiga.