Como fazer migração de hospedagem compartilhada para VPS

Resposta direta

A migração de hospedagem compartilhada para VPS deve ser executada em etapas: inventário do ambiente atual, preparação segura do novo servidor, cópia inicial dos arquivos, sincronização do banco de dados, transferência dos emails e troca controlada do DNS. Para reduzir a indisponibilidade, diminua o TTL dos registros DNS entre 24 e 48 horas antes, faça uma sincronização incremental pouco antes do corte e mantenha a hospedagem antiga ativa por pelo menos 72 horas. Um site WordPress pequeno costuma iniciar com 2 vCPUs, 4 GB de RAM e 60 GB de SSD, mas lojas virtuais, vários sites e bancos intensivos podem exigir 4 vCPUs, 8 GB de RAM e armazenamento maior. O rollback precisa ser definido antes da mudança, não depois de uma falha.

Resumo rápido

• Liste domínios, subdomínios, bancos, contas de email, tarefas cron e versões de software antes de iniciar.
• Configure firewall, SSH, servidor web, PHP, banco de dados, TLS e monitoramento na VPS.
• Faça uma primeira cópia enquanto o site antigo continua atendendo visitantes.
• Coloque aplicações dinâmicas em manutenção apenas durante a sincronização final.
• Reduza o TTL do DNS com antecedência e confirme os novos registros antes do corte.
• Migre caixas postais com sincronização incremental ou mantenha o email em um serviço separado.
• Preserve a hospedagem antiga por pelo menos 72 horas e documente um procedimento de rollback.

Planeje a migração antes de copiar qualquer arquivo

Migrar sem inventário costuma produzir problemas que só aparecem depois da troca do DNS. Um formulário deixa de enviar mensagens, uma tarefa cron para de executar ou um subdomínio interno continua apontando para o servidor antigo. Comece registrando todos os domínios, aliases, redirecionamentos, certificados, bancos, usuários, caixas postais e integrações externas. Também anote as versões de PHP, Node.js, MySQL ou MariaDB usadas atualmente. Uma aplicação antiga em PHP 7.4, por exemplo, pode falhar se for colocada diretamente em PHP 8.3.

Faça um inventário completo

No caso de WordPress, registre o tamanho de wp-content, o volume do banco e os plugins que dependem de extensões específicas. Um site com 12 GB de uploads, banco de 1,8 GB e 20 caixas de email exige um plano diferente de um portfólio estático de 500 MB. Confira ainda limites de upload, regras do .htaccess, filas, webhooks, chaves armazenadas em variáveis de ambiente e diretórios fora da pasta pública. Credenciais não devem ser colocadas no documento de migração. Registre apenas onde elas estão armazenadas e quem tem autorização para acessá-las.

Use um checklist por serviço. Para um e-commerce, os itens podem incluir catálogo, pedidos, gateway de pagamento, Redis, SMTP transacional e integração com ERP. Para uma agência, o inventário pode abranger 15 instalações de WordPress, cada uma com banco, versão de PHP e certificado próprios. Quem está consolidando projetos deve avaliar antes se uma VPS para múltiplos sites oferece isolamento e capacidade suficientes para evitar que um cliente consuma os recursos dos demais.

Defina janela de mudança e rollback

Escolha uma janela baseada no tráfego real, não apenas na conveniência da equipe. Se o menor volume ocorre entre 2h e 4h, reserve esse período para bloquear gravações, executar a sincronização final e alterar o DNS. Determine critérios objetivos de cancelamento, como erro HTTP acima de 2%, falha na finalização de pedidos ou diferença na contagem de registros do banco.

O rollback pode consistir em restaurar os registros DNS anteriores, retirar o modo de manutenção e reabrir a aplicação no servidor antigo. Esse caminho só funciona se nenhum dado novo tiver sido gravado exclusivamente na VPS. Por isso, sites com pedidos, comentários ou cadastros devem ficar em modo somente leitura durante o corte. Documente responsáveis, horários, contatos e comandos antes de iniciar. Em uma migração de produção, improvisar custa mais tempo do que escrever uma página de procedimento.

Prepare a VPS para receber o ambiente

A VPS precisa estar pronta e testada antes da primeira cópia. A escolha entre administração própria e serviço assistido muda bastante o trabalho operacional. Uma VPS não gerenciada normalmente entrega acesso ao sistema, rede e recursos computacionais, enquanto atualizações, firewall, banco, backups e resposta a incidentes ficam com o cliente. Se a equipe não domina Linux, a comparação entre VPS gerenciada ou não gerenciada ajuda a calcular o custo além da mensalidade.

Dimensionamento inicial

Use o consumo atual como referência e mantenha margem para picos. Um WordPress institucional com até 100 mil visualizações mensais pode começar com 2 vCPUs, 4 GB de RAM e 60 GB de SSD. Uma loja WooCommerce com consultas frequentes, 30 mil produtos e integrações em segundo plano tende a trabalhar melhor com 4 vCPUs, 8 GB de RAM e pelo menos 100 GB de SSD. Uma agência com dez sites pequenos pode adotar 4 vCPUs e 8 GB, desde que monitore CPU steal, memória, IOPS e processos PHP simultâneos.

Perfil de migração	Configuração inicial sugerida	Disco livre recomendado	Arquitetura indicada	Principal risco
Site institucional em WordPress	2 vCPUs e 4 GB de RAM	60 GB SSD, com 30% livres	Nginx ou Apache, PHP-FPM e MariaDB	Plugins incompatíveis com a nova versão de PHP
WooCommerce de porte médio	4 vCPUs e 8 GB de RAM	100 GB SSD ou NVMe	Nginx, PHP-FPM, Redis e banco ajustado	Pedidos gravados durante a sincronização final
Agência com 10 a 20 sites	4 a 8 vCPUs e 8 a 16 GB de RAM	160 GB ou mais	Contêineres, pools PHP separados ou painel	Um site consumir CPU e afetar os demais
Aplicação PHP com banco intenso	4 vCPUs e 8 GB de RAM	100 GB com IOPS monitoradas	Aplicação e banco isolados quando possível	Consultas lentas saturarem disco e CPU

As configurações são pontos de partida, não garantias de capacidade. Tráfego, cache, consultas SQL, extensões e concorrência alteram o consumo. SSD ou NVMe também não corrige código com consultas sem índice.

Segurança e serviços essenciais

Crie um usuário administrativo sem usar login cotidiano como root, instale atualizações e limite o SSH por chave. Não publique chaves privadas em scripts ou repositórios. No firewall, libere apenas as portas necessárias, normalmente 22 para administração, 80 para HTTP e 443 para HTTPS. Se o banco não recebe conexões externas, mantenha a porta 3306 acessível somente pelo endereço local.

Configure NTP, logs, rotação, alertas e backup antes de hospedar dados reais. Um exemplo simples de firewall no Ubuntu usa ufw allow OpenSSH, ufw allow 80/tcp, ufw allow 443/tcp e, por fim, ufw enable. Confirme a sessão SSH em outro terminal antes de fechar a conexão atual. Para equipes que preferem administrar domínios e versões de PHP por interface, uma VPS com painel de controle pode reduzir tarefas repetitivas, mas não elimina a necessidade de atualizações, cópias externas e controle de acesso.

Migre arquivos e bancos de dados sem perder alterações

A cópia deve ocorrer em pelo menos duas passagens. Na primeira, transfira a maior parte dos dados enquanto o site antigo continua online. Na segunda, já perto do corte, copie apenas arquivos alterados e faça uma exportação recente do banco. Essa abordagem encurta o período em que comentários, pedidos ou uploads precisam ficar bloqueados.

Transferência incremental dos arquivos

Quando existe acesso SSH nos dois ambientes, rsync é uma opção eficiente porque envia apenas diferenças. Um comando típico no servidor novo seria rsync -avz usuario@servidor-antigo:/caminho/site/ /var/www/site/. Execute primeiro sem a opção --delete. A remoção automática pode apagar arquivos legítimos se o caminho estiver incorreto. Em uma instalação com 25 GB, a primeira cópia pode levar dezenas de minutos ou algumas horas, enquanto a segunda pode transferir apenas 200 MB modificados.

Se a hospedagem compartilhada oferece apenas FTP ou SFTP, baixe os arquivos para uma estação segura e depois envie à VPS. Preserve datas e permissões quando possível. Após a cópia, ajuste o proprietário com algo como chown -R www-data:www-data /var/www/site, adaptando o usuário ao servidor web. Diretórios costumam usar permissão 755 e arquivos 644. Não aplique 777 como solução genérica, pois isso amplia a superfície de ataque.

Para testar antes do DNS, associe temporariamente o domínio ao IP novo no arquivo hosts do computador. Assim, o navegador acessa a VPS enquanto o público continua no servidor antigo. Verifique páginas, uploads, login, imagens e URLs amigáveis. Em WordPress, confirme também siteurl e home, especialmente quando o ambiente temporário utilizou outro endereço.

Exportação e importação do banco

Para MySQL ou MariaDB, uma exportação básica pode usar mysqldump --single-transaction --routines --triggers nome_banco > banco.sql. A opção --single-transaction reduz bloqueios em tabelas InnoDB, mas não oferece a mesma consistência para tabelas MyISAM. Compacte transferências grandes com gzip banco.sql e importe na VPS com gunzip < banco.sql.gz | mysql nome_banco.

Antes da importação, crie banco e usuário com privilégios restritos à aplicação. Nunca exponha a senha diretamente no histórico do shell. Prefira o prompt interativo, um arquivo de configuração protegido ou um gerenciador de segredos. Compare a quantidade de tabelas e registros críticos. Em uma loja, confronte o número do último pedido, total de clientes e pedidos das últimas 24 horas. Em um CMS, valide usuários, posts, comentários e metadados.

Pouco antes do corte, coloque a aplicação antiga em manutenção, repita o rsync para uploads recentes e gere uma nova exportação. Uma loja que recebe quatro pedidos por minuto não pode depender de um dump feito duas horas antes. Para bancos grandes, replicação temporária ou ferramentas de migração online podem reduzir a janela, mas exigem teste e experiência operacional.

Transfira emails sem interromper a comunicação

Email merece um plano próprio. Muitas hospedagens compartilhadas concentram site, DNS e caixas postais na mesma conta, enquanto uma VPS pode ser contratada apenas para a aplicação. Hospedar o próprio servidor de email exige cuidar de reputação de IP, filas, antispam, atualizações, PTR, SPF, DKIM e DMARC. Para equipes pequenas, manter as caixas em um serviço especializado costuma reduzir riscos operacionais.

Escolha entre manter ou migrar o email

Se os registros MX já apontam para Google Workspace, Microsoft 365 ou outro serviço externo, a migração do site não precisa alterar o fluxo de mensagens. Copie a zona DNS preservando MX, SPF, DKIM e DMARC. Um erro comum é substituir toda a zona por um modelo padrão da VPS e remover registros de autenticação. Nesse cenário, o site pode funcionar enquanto emails entram em spam ou deixam de chegar.

Quando as caixas estão na hospedagem antiga, há duas opções. A primeira é mantê-las lá temporariamente, desde que o provedor permita conservar o serviço sem o site. A segunda é sincronizar as mensagens por IMAP para o novo destino. Ferramentas como imapsync conseguem copiar pastas e repetir o processo, transferindo apenas mensagens novas. Faça uma primeira sincronização dias antes e outra após a mudança do MX.

Considere uma empresa com 18 caixas, cada uma com 6 GB. São 108 GB de mensagens, volume que não deve ser deixado para a madrugada do corte. Outro exemplo é uma caixa compartilhada de suporte com 40 mil mensagens e várias subpastas. Teste primeiro com um usuário não crítico, confira datas, anexos, itens enviados e estrutura das pastas.

Sincronize mensagens e valide autenticação

Antes de alterar o MX, crie todas as contas, aliases, listas e encaminhamentos no destino. Configure SPF para autorizar apenas os remetentes usados. Publique a chave DKIM fornecida pelo serviço e adote DMARC inicialmente com política de monitoramento, se ainda não houver histórico. O registro PTR do IP precisa ser solicitado ao provedor quando a VPS enviar email diretamente.

Mantenha os dois serviços recebendo mensagens durante a propagação. Depois do corte, execute uma sincronização final e teste envio nos dois sentidos com provedores diferentes. Confira cabeçalhos para verificar SPF, DKIM e DMARC. Não cancele a hospedagem antiga enquanto ainda houver mensagens chegando nela ou usuários configurados com o servidor anterior.

Troque o DNS com o menor downtime possível

A alteração do DNS é a etapa visível, mas o downtime geralmente nasce antes dela. Se a aplicação não foi testada, o banco está desatualizado ou o certificado ainda não existe, reduzir o TTL não resolverá o problema. O DNS apenas direciona visitantes. A consistência depende da preparação dos dois ambientes.

Reduza o TTL com antecedência

Entre 24 e 48 horas antes da migração, reduza o TTL dos registros que serão alterados para 300 segundos. Faça isso no registro A do domínio, no www e em subdomínios ligados à aplicação. Um TTL anterior de 14.400 segundos pode permanecer em caches por até quatro horas, mesmo depois de ser reduzido. Por isso, mudar o valor cinco minutos antes do corte não produz o efeito esperado.

Exporte ou fotografe a zona atual. Registre A, AAAA, CNAME, MX, TXT, CAA e entradas de validação. Se a VPS não possui IPv6 configurado, remova ou atualize o registro AAAA. Deixar o AAAA antigo pode fazer parte dos visitantes chegar ao servidor anterior enquanto usuários IPv4 acessam o novo. Em um caso prático, o domínio principal pode apontar para 203.0.113.10, enquanto mail, MX e registros TXT continuam no provedor de email existente.

Não altere nameservers e endereço do site ao mesmo tempo sem necessidade. Manter o DNS no mesmo provedor e trocar apenas os registros A e AAAA reduz variáveis. A mudança de nameservers envolve a replicação da zona completa e aumenta o risco de esquecer um TXT de autenticação, um subdomínio de API ou um registro usado por certificado.

Faça o corte e acompanhe a propagação

Na janela definida, ative manutenção no servidor antigo, conclua a última sincronização de arquivos e banco, valide a VPS pelo arquivo hosts e altere o DNS. Em seguida, acompanhe resoluções por redes e resolvedores diferentes. Comandos como dig dominio.com A, dig dominio.com AAAA e dig @1.1.1.1 dominio.com A ajudam a comparar resultados.

Mantenha o servidor antigo online, mas sem aceitar novas gravações. Uma página de manutenção ou um proxy para a VPS evita bancos divergentes. Preserve esse ambiente por pelo menos 72 horas. Caches corporativos e provedores podem reter respostas além do esperado, embora o TTL baixo reduza a duração normal.

Depois que o tráfego estiver estabilizado, aumente o TTL para 3.600 ou 14.400 segundos, conforme a frequência prevista de mudanças. Um TTL de 300 segundos permanente aumenta consultas DNS sem trazer benefício cotidiano para a maioria dos sites. Monitore requisições nos logs dos dois servidores. Quando o antigo deixar de receber acessos legítimos e a sincronização final estiver confirmada, o cancelamento pode ser programado.

Valide o novo servidor e mantenha um plano de rollback

Uma migração não termina quando a página inicial abre. É preciso testar caminhos de negócio, tarefas automáticas, entrega de email, certificados, cache e backups. Crie um roteiro reproduzível e registre o resultado de cada teste. Isso evita a falsa sensação de sucesso causada por uma verificação superficial.

Teste antes e depois do corte

Antes da mudança do DNS, use o arquivo hosts para acessar a VPS e execute testes de leitura e escrita. Em WordPress, publique um rascunho, envie uma imagem, faça login como usuário comum e abra URLs amigáveis. Em WooCommerce, simule carrinho, cupom, cálculo de frete e pagamento em sandbox. Para uma API, teste autenticação, criação de recurso, upload e webhooks de retorno.

Após o corte, verifique códigos HTTP, tempo de resposta e logs de erro. Um comando como curl -I https://dominio.com confirma status, redirecionamentos e cabeçalhos básicos. Use journalctl, logs do Nginx ou Apache e registros do PHP-FPM para localizar falhas. Confira também processos agendados. Uma tarefa cron que antes rodava no painel compartilhado precisa ser recriada, por exemplo */5 * * * * /usr/bin/php /var/www/site/artisan schedule:run para uma aplicação Laravel.

Teste o backup restaurando uma amostra em diretório ou banco separado. Um arquivo existente não prova que a recuperação funciona. Para um banco de 4 GB, cronometre exportação, transferência e restauração. Esse tempo informa o objetivo realista de recuperação. Mantenha pelo menos uma cópia fora da VPS para que uma falha de disco, exclusão acidental ou comprometimento do servidor não destrua produção e backup ao mesmo tempo.

Investigue falhas sem improviso

Erros 502 costumam indicar falha entre servidor web e PHP-FPM ou processo de aplicação. Erros 403 podem vir de permissões, regras do servidor ou políticas de segurança. Redirecionamentos infinitos aparecem quando proxy, HTTPS e configuração da aplicação discordam sobre o protocolo. Já caracteres quebrados no banco sugerem diferenças de charset ou collation.

Defina gatilhos de rollback. Se pedidos não forem concluídos por dez minutos, o banco apresentar divergência ou a taxa de erros ultrapassar o limite estabelecido, interrompa a mudança. Restaure o DNS anterior, reative o servidor antigo e preserve os logs da VPS para análise. Não tente dezenas de alterações simultâneas em produção. Uma correção por vez torna o diagnóstico mais rápido e reduz a chance de criar um segundo problema.

Recomendações por perfil

A melhor estratégia depende da experiência disponível, do impacto financeiro do site e da quantidade de serviços envolvidos. O mesmo procedimento não serve para um blog pessoal e para uma loja que recebe pedidos a cada minuto. Use os perfis abaixo como ponto de partida e ajuste recursos após medir o ambiente real.

Desenvolvedor solo

Para um desenvolvedor com um ou dois sites, uma VPS de 2 vCPUs, 4 GB de RAM e 60 GB de SSD costuma ser uma base prática. Use uma distribuição com suporte estável, automatize atualizações de segurança e mantenha backups externos diários. Faça a migração em duas cópias com rsync, teste pelo arquivo hosts e preserve o ambiente antigo por 72 horas. Se administrar Nginx, PHP-FPM e banco consumir tempo demais, um painel ou serviço gerenciado pode compensar. O objetivo não é criar a arquitetura mais sofisticada, mas obter um ambiente previsível que possa ser restaurado sem depender da memória de uma única pessoa.

Equipe pequena

Uma agência ou startup com vários projetos deve priorizar isolamento, controle de acesso e documentação. Considere 4 vCPUs, 8 GB de RAM e 100 a 160 GB de armazenamento para começar, ajustando após observar consumo. Separe pools de PHP, usuários de sistema, bancos e credenciais por aplicação. Centralize logs e configure alertas de CPU, memória, disco e disponibilidade. A migração deve ter um responsável técnico, alguém para validar funcionalidades e uma pessoa autorizada a decidir pelo rollback. Emails podem permanecer em serviço especializado, enquanto sites e APIs seguem para a VPS. Essa separação diminui o número de componentes alterados na mesma janela.

Produção crítica

Lojas, SaaS e portais com receita direta exigem ensaio prévio e métricas objetivas. Crie um ambiente de homologação semelhante à produção, meça o tempo de importação do banco e simule o corte completo. Bancos com dezenas de gigabytes podem exigir replicação temporária em vez de um único mysqldump. Configure monitoramento externo, backups com retenção, teste de restauração e um canal de comunicação para incidentes. Avalie separar banco e aplicação quando houver carga ou requisitos de disponibilidade que justifiquem a complexidade. O servidor antigo deve permanecer preservado até a confirmação de pedidos, integrações, filas, emails e rotinas agendadas. Nesse perfil, alguns minutos economizados não compensam uma migração sem rollback testado.