Pular para o conteúdo principal

Migrar site cPanel para VPS sem tempo de inatividade

· Leitura de 6 minutos
Customer Care Engineer

Publicado em 10 de setembro de 2026

Migrar site cPanel para VPS sem tempo de inatividade

Para migrar um site cPanel para um VPS sem uma indisponibilidade inesperada, trate o DNS como a etapa final, não como a primeira tarefa. Prepare o servidor de destino, copie a conta, teste-a no novo endereço IP, reduza o TTL do DNS e então altere os registros somente depois que as verificações da aplicação, do e-mail e do SSL forem aprovadas. O site permanece disponível enquanto o trabalho acontece em segundo plano.

Para o site de uma pequena empresa, uma conta de agência ou uma loja com pedidos em tempo real, a migração trata menos de mover arquivos e mais de preservar o comportamento do serviço. Versões e extensões do PHP, permissões de banco de dados, cron jobs, roteamento de e-mail, redirecionamentos e regras de firewall precisam chegar em um estado comprovadamente funcional. Os arquivos normalmente são a parte fácil. As pequenas configurações escondidas ao redor deles são onde as migrações ganham seus cabelos grisalhos.

Antes de migrar um site cPanel para VPS

Comece com um inventário da conta existente. Registre os nomes de domínio e subdomínios, o uso de disco da conta, a versão e as extensões do PHP, os tamanhos dos bancos de dados, os cron jobs, as contas de e-mail, os encaminhamentos, as respostas automáticas, os registros DNS, os certificados SSL e quaisquer serviços externos que dependam do endereço IP do servidor. Para cargas de trabalho de e-commerce e SaaS, identifique também callbacks de pagamento, listas de permissões de API, provedores de e-mail transacional e workers em segundo plano.

Verifique se o VPS de destino tem capacidade de sobra suficiente. O espaço em disco deve cobrir a conta de origem, o arquivo temporário de migração, os bancos de dados, os backups e o crescimento normal. Os requisitos de RAM e CPU dependem do tráfego e da pilha de software. Um site institucional pode funcionar bem em um VPS modesto; WooCommerce, Magento, WordPress multisite grande ou uma aplicação com muito movimento normalmente precisam de mais memória e capacidade de banco de dados.

O destino deve estar preparado antes que qualquer dado de produção seja copiado. Defina o hostname do servidor, instale e atualize o cPanel e o WHM se esse for o painel de controle escolhido, configure os nameservers se o VPS hospedar DNS e habilite um firewall com apenas as portas necessárias abertas. Confirme que os backups estão configurados independentemente do servidor de origem. Um backup armazenado apenas no VPS é útil, mas não é um plano completo de recuperação se o próprio VPS tiver um problema.

Se você estiver migrando de uma hospedagem cPanel compartilhada para um VPS, verifique o que antes era gerenciado para você. O host antigo pode ter cuidado da filtragem de e-mail, DNS, renovação automática de SSL, varredura de malware ou backups fora do servidor. Em um VPS gerenciado, esses itens podem ser verificados e mantidos com você. Em um servidor não gerenciado, eles passam a ser sua responsabilidade operacional. Nenhuma das abordagens está errada, mas suposições custam caro.

Reduza o TTL do DNS antes da mudança

Cerca de 24 a 48 horas antes da mudança planejada, reduza o TTL nos registros DNS relevantes para 300 segundos, se for prático. Isso permite que os registros A, AAAA e MX atualizados se propaguem mais rapidamente quando chegar o momento da mudança. Não o reduza cinco minutos antes da migração e espere que a internet fique filosófica sobre isso. Os resolvedores recursivos talvez já tenham o valor antigo em cache.

Mantenha um registro da zona DNS atual antes de editá-la. Se algo inesperado aparecer após a mudança, restaurar registros conhecidos é mais rápido do que reconstruí-los de memória.

Escolha o método de transferência certo

A Transfer Tool do WHM normalmente é o método mais limpo para mover contas cPanel completas entre servidores compatíveis. Ela transfere dados da conta, bancos de dados, e-mail, informações da zona DNS e muitas configurações no nível da conta em um único processo controlado. Use acesso root ou de nível revendedor sempre que possível e verifique se o servidor de origem permite a conexão SSH necessária.

Um backup completo do cPanel também pode funcionar bem quando a transferência direta de servidor para servidor não está disponível. Gere o backup, mova-o com segurança para o novo VPS e restaure-o pelo WHM. Essa abordagem é mais manual, e o backup pode representar um ponto no tempo em vez das alterações mais recentes, portanto agende a sincronização final com cuidado.

Para aplicações com configurações incomuns, uma migração manual pode ser mais segura. Copie os arquivos do site com rsync ou outro método de transferência seguro, exporte e importe bancos de dados, recrie usuários e permissões e então reconstrua a configuração fora da conta. Isso leva mais tempo, mas dá mais controle quando o sistema de origem tem regras Nginx personalizadas, caminhos não padrão, armazenamento externo ou workers da aplicação.

Evite copiar apenas o diretório public_html, a menos que você tenha confirmado que não há mais nada a preservar. E-mail, bancos de dados, arquivos ocultos, definições de cron, materiais de SSL e arquivos de configuração geralmente estão fora dessa pasta.

Teste o VPS antes das alterações públicas de DNS

Assim que a conta for restaurada, valide o site no IP de destino sem alterar o DNS público. Uma entrada no arquivo hosts local permite que seu computador resolva o domínio para o novo VPS enquanto todos os demais ainda acessam o servidor antigo. Esse é o momento certo para encontrar uma extensão PHP ausente, uma regra de rewrite quebrada ou um usuário de banco de dados que não foi transferido.

Teste as páginas principais, o fluxo de login, os formulários de contato, o checkout, a área administrativa, os uploads de imagens e as tarefas agendadas. Revise os logs da aplicação e o log de erros do servidor web enquanto faz isso. Verifique se o site está usando a versão de PHP pretendida e se a propriedade dos arquivos está correta. Uma página que carrega uma vez não é o teste completo. Ela também deve gravar no banco de dados, enviar as mensagens necessárias e lidar normalmente com sessões autenticadas.

Verifique também o SSL antes da mudança. Se o certificado estiver sendo reemitido depois que o DNS apontar para o VPS, confirme se o virtual host do servidor web está correto e se as portas 80 e 443 estão acessíveis. Se você estiver trazendo um certificado existente, instale com segurança sua cadeia de certificados e chave. Os navegadores são bastante honestos sobre erros de certificado, às vezes com mais drama do que o necessário.

Trate o e-mail separadamente do tráfego web

O e-mail é a parte mais comumente esquecida de uma migração para VPS. Se o domínio usa e-mail externo, como Google Workspace ou Microsoft 365, preserve os registros MX, SPF, DKIM e DMARC existentes. Não os substitua acidentalmente por registros de e-mail local do cPanel.

Se o e-mail estiver hospedado no cPanel, mova as caixas de correio e teste o envio e o recebimento no VPS. Durante a transição de DNS, novas mensagens podem chegar a qualquer um dos servidores. Mantenha a conta de hospedagem antiga ativa por pelo menos 48 a 72 horas após a mudança e execute uma sincronização final de e-mail e arquivos se a origem permanecer ativa. Para alto volume de e-mail ou caixas de entrada críticas para o negócio, planeje uma mudança de e-mail mais deliberada em vez de tratá-la como algo secundário.

Faça a mudança com cuidado e mantenha o servidor antigo disponível

Quando os testes estiverem limpos, coloque as partes dinâmicas do site em um breve modo de manutenção, se a aplicação permitir. Execute uma exportação final do banco de dados ou sincronização da conta para capturar pedidos, envios de formulários, alterações de usuários e atualizações de conteúdo feitas desde a transferência inicial. Restaure ou sincronize esses dados finais no VPS e depois remova o modo de manutenção quando o novo ambiente estiver pronto.

Atualize o registro A para o novo endereço IPv4 e o registro AAAA somente se o IPv6 estiver configurado e testado. Se os nameservers também estiverem mudando, faça essa alteração deliberadamente e confirme que a nova zona contém todos os registros necessários. Alterar os nameservers e reconstruir o DNS no mesmo momento adiciona partes móveis. Às vezes isso é necessário, mas não é a situação de DNS mais bonita.

Monitore o novo servidor durante as primeiras horas. Verifique os logs de acesso web, erros de PHP e da aplicação, carga de CPU, pressão de memória, uso de disco, status da fila de e-mail e atividade do banco de dados. Confirme que os backups automatizados são executados com sucesso e que o monitoramento consegue alcançar o novo VPS. Na kodu.cloud, é aqui que as operações gerenciadas e o monitoramento FASTCARE são úteis: o serviço volta a ficar calmo porque alguém está observando o comportamento real do servidor, não apenas a página inicial.

Não cancele o serviço antigo imediatamente. Deixe-o online até que a propagação do DNS tenha se estabilizado, o fluxo de e-mail seja confirmado, os backups sejam verificados e os usuários principais tenham testado o site ao vivo. Para a maioria dos sites padrão, 72 horas é uma janela de segurança razoável. Mantenha um plano de rollback durante esse período: retenha os valores antigos de DNS, evite alterações destrutivas na origem e saiba quem tomará a decisão se um retorno for necessário.

Verificações pós-migração que evitam problemas futuros

Após a migração, revise backups agendados, períodos de retenção, testes de restauração, atualizações de segurança, comportamento do firewall e tendências de recursos. Remova as entradas de teste antigas do seu arquivo hosts local. Atualize quaisquer listas de permissões externas, alvos de monitoramento, endpoints de webhook e documentação que façam referência ao endereço IP antigo.

Um VPS também dá a você a chance de limpar bagunças antigas de hospedagem. Remova contas de e-mail inativas, cópias antigas de staging, bancos de dados abandonados e plugins ou extensões que não são mais necessários. Faça isso depois que a migração estiver estável, não durante a janela crítica de transferência. Mudanças calmas são mais fáceis de reverter.

Uma boa migração deixa mais do que um site que simplesmente carrega. Ela deixa um servidor que você pode monitorar, restaurar, atualizar e no qual pode confiar quando o tráfego chegar em uma hora inconveniente. Inclua essa margem operacional na migração, e a próxima tarefa de manutenção parecerá muito menos uma operação de resgate.

Andres Saar Engenheiro de Atendimento ao Cliente