Como migrar o servidor de um website sem tempo de inatividade

Publicado em 15 de julho de 2026

Inicie a migração com um backup completo e restaurável, e um plano de cutover por escrito. Essa é a resposta mais segura para como migrar a infraestrutura do servidor de um website sem transformar uma mudança de rotina numa indisponibilidade. O seu novo servidor deve estar configurado, protegido e testado antes de o DNS direcionar quaisquer visitantes para ele. O servidor antigo permanece online até que o novo ambiente tenha passado em verificações reais.

Uma migração de servidor é mais do que copiar ficheiros do website. O website, a base de dados, as tarefas agendadas, o encaminhamento de email, os certificados SSL, o runtime da aplicação, o comportamento da cache, os registos DNS e as regras de firewall podem todos fazer parte do serviço. Deixar de fora uma pequena dependência é a forma como um site pode parecer funcionar bem na página inicial enquanto emails de checkout, formulários ou tarefas em segundo plano falham silenciosamente. Não é uma falha muito glamorosa, mas continua a ser dispendiosa.

Mapeie o servidor atual antes de o mover

Comece com um inventário do que está realmente em execução. Não confie apenas no que o painel de controlo do alojamento mostra. Verifique a raiz de documentos, a versão da aplicação, o motor e a versão da base de dados, as definições de PHP ou Node.js, os cron jobs, os queue workers, os caminhos de armazenamento, os redirecionamentos, as variáveis de ambiente e a configuração de email de saída.

No caso de um website empresarial, identifique também tudo o que está fora do domínio principal. Isto pode incluir subdomínios, sites de staging, endpoints de API, callbacks de pagamento, armazenamento de objetos, fornecedores de email de terceiros, scripts de analytics e registos DNS usados para verificação. Se o servidor enviar email diretamente, registe o seu IP de envio, a configuração de reverse DNS e os registos SPF, DKIM e DMARC. O email é muitas vezes o último item de que se dá conta e o primeiro de que os clientes se queixam.

Documente também a utilização de recursos do servidor atual. Analise a carga de CPU, o consumo de memória, o espaço em disco, o tamanho da base de dados, os padrões de tráfego e os registos de erros. Isto diz-lhe se o novo VPS ou servidor dedicado tem o dimensionamento correto. Uma migração é um momento útil para deixar para trás um disco subdimensionado, uma versão desatualizada do PHP ou um servidor que tem sobrevivido sobretudo por otimismo.

Prepare primeiro o novo ambiente

Provisione o servidor de destino antes de copiar os dados de produção. Aplique atualizações do sistema operativo, crie acesso administrativo restrito, configure a firewall e instale apenas os serviços de que o site necessita. Use chaves SSH em vez de acesso apenas por palavra-passe, sempre que possível. Desative serviços desnecessários e garanta que as atualizações automáticas de segurança estão alinhadas com a sua política operacional.

Corresponda cuidadosamente aos requisitos da aplicação. Um site que passe de PHP 7.4 para PHP 8.3, ou de MySQL para uma versão mais recente do MariaDB, pode precisar de alterações ao código antes de funcionar corretamente. O mesmo se aplica à configuração do servidor web. As regras de rewrite do Apache, os locations do Nginx, as permissões de ficheiros e as extensões de PHP nem sempre se traduzem de forma direta.

Configure a monitorização antes do cutover, não depois de um incidente. Monitorize disponibilidade, tempo de resposta, CPU, memória, utilização de disco, expiração de SSL e portas dos principais serviços. Para aplicações com processamento em segundo plano, monitorize também a profundidade da fila e as tarefas falhadas. Com infraestrutura gerida e monitorização implementadas, os logs contam agora a mesma história, em vez de o deixarem a adivinhar depois de os visitantes reportarem um problema.

Faça backup para recuperação, não apenas para tranquilidade

Crie um backup recente imediatamente antes da janela de migração. Deve incluir ficheiros do website, bases de dados, ficheiros de configuração, uploads gerados pelos utilizadores e quaisquer segredos da aplicação armazenados fora da raiz web. Verifique se o backup pode ser restaurado para uma localização separada. Um backup que nunca foi testado é um arquivo esperançoso, não um plano de recuperação.

Para bases de dados, use uma exportação consistente. Bases de dados grandes ou ativas podem exigir tratamento especial para evitar copiar dados enquanto estão a mudar. Dependendo da base de dados e da aplicação, pode usar uma janela de manutenção, um modo só de leitura, replicação ou uma sincronização incremental final. Lojas de e-commerce, sistemas de reservas, produtos SaaS e sites de membros requerem um cuidado especial porque encomendas e alterações de conta podem chegar a cada minuto.

Mantenha o servidor original inalterado durante a migração. Não o cancele nem apague os dados assim que os ficheiros aparecerem no destino. Manter o ambiente antigo dá-lhe um caminho limpo de rollback se surgir uma dependência oculta após a mudança.

Transfira ficheiros e bases de dados em etapas

Copie o conjunto de dados inicial enquanto o site existente permanece ativo. Ferramentas seguras de transferência de ficheiros, como rsync sobre SSH, são úteis porque conseguem sincronizar apenas os ficheiros alterados numa passagem final posterior. Para bases de dados, importe o dump inicial para o novo servidor e depois teste a aplicação contra ele usando um hostname temporário ou uma substituição local do ficheiro hosts.

Evite testar apenas a página inicial. Inicie sessão como administrador e como utilizador normal. Submeta um formulário de contacto, redefina uma palavra-passe, carregue um ficheiro, faça uma compra de teste se apropriado, reveja os emails transacionais e confirme que as tarefas agendadas estão a funcionar. Verifique os logs da aplicação e os registos de erros do servidor web durante os testes. Uma resposta HTTP 200 bem-sucedida não prova que o serviço está saudável.

Se estiver a mudar a arquitetura do servidor ao mesmo tempo, isole as alterações sempre que possível. Por exemplo, passar para um novo VPS já é trabalho suficiente sem também redesenhar a base de dados, substituir a camada de cache e atualizar o framework da aplicação na mesma noite. Projetos separados tornam as falhas mais fáceis de diagnosticar e reverter.

Reduza o TTL do DNS antes do cutover

O DNS é onde uma migração tecnicamente bem-sucedida pode tornar-se confusa para os visitantes. Reduza o TTL dos registos A, AAAA, CNAME e dos registos relacionados com email relevantes 24 a 48 horas antes da mudança planeada. Um TTL mais baixo incentiva os resolvedores a atualizar os registos mais rapidamente assim que apontar o domínio para o novo servidor.

Isto não garante que todos os resolvedores atualizem instantaneamente. Algumas redes mantêm a cache durante mais tempo do que o pedido, e os utilizadores podem ter cache DNS local. Planeie um período de transição em que uma pequena parte do tráfego ainda possa chegar ao servidor antigo. Se o site aceitar dados em alteração, precisa de uma estratégia para essa sobreposição. Um modo de manutenção durante a sincronização final é muitas vezes mais seguro do que aceitar novas encomendas em dois servidores separados.

Não altere os nameservers a menos que haja uma razão para também mover o alojamento DNS. Alterar os nameservers autoritativos acrescenta outra camada de propagação e mais registos para validar. Mantenha a migração aborrecida onde puder. Infraestrutura aborrecida é normalmente infraestrutura saudável.

Execute a sincronização final e mude o tráfego

À hora de cutover acordada, coloque a aplicação em modo de manutenção se ela escrever dados de clientes. Pare os queue workers e as tarefas agendadas no servidor antigo para que não possam processar a mesma tarefa duas vezes. Execute a sincronização final de ficheiros e a exportação/importação da base de dados, depois atualize a configuração de destino com as credenciais da base de dados de produção, as chaves da aplicação e os URLs corretos.

Ative a aplicação no novo servidor e atualize o DNS para o seu endereço IP. Confirme que o certificado SSL está instalado e que HTTP redireciona corretamente para HTTPS. Se existir um load balancer, CDN ou proxy à frente do site, atualize a configuração de origem e verifique se reconhece as verificações de estado do novo servidor.

Observe ambos os servidores durante a propagação. O novo servidor deve mostrar pedidos recebidos, enquanto o servidor antigo deve receber progressivamente menos tráfego. Reveja erros 404, 500 e de permissões, bem como alertas específicos da aplicação. Vigie a utilização de recursos porque um novo servidor pode comportar-se de forma diferente sob tráfego real do que durante os testes.

Valide o serviço após a migração

Quando o tráfego estiver a chegar ao novo ambiente, realize uma verificação focada em produção. Confirme que as páginas principais carregam, os utilizadores conseguem autenticar-se, os formulários são entregues, os fluxos de pagamento ou reserva funcionam, os dashboards mostram dados atuais e os ficheiros carregados estão acessíveis. Teste a partir de mais do que uma rede, se possível, uma vez que o seu próprio computador ainda pode ter DNS em cache.

Verifique a atividade agendada ao longo das horas seguintes. Cron jobs, backups, renovações, relatórios, queue workers e recetores de webhook expõem frequentemente problemas de migração depois de a validação inicial ter sido concluída. Reveja também os logs de email e os relatórios de entrega. Se o site usar um serviço SMTP remoto, confirme que o IP ou hostname do novo servidor está autorizado.

Deixe o servidor antigo disponível durante pelo menos 48 a 72 horas, ou mais em aplicações complexas ou ambientes DNS lentos. Durante esse período, preserve backups de ambos os lados e não faça alterações de configuração não relacionadas. Quando a monitorização estiver limpa, o tráfego estiver estável e a janela de rollback tiver passado, desative o servidor antigo de forma segura.

Saiba quando usar ajuda gerida

Um simples site institucional pode normalmente ser migrado com preparação cuidadosa e uma curta janela de manutenção. Uma loja com muito tráfego, um portefólio de agência com muitos sites de clientes, uma plataforma SaaS ou um servidor com serviços personalizados merece um plano mais controlado. A replicação da base de dados, as releases faseadas, o escoamento de tráfego e a monitorização ativa reduzem o risco, mas também exigem mãos experientes.

kodu.cloud pode ajudar com o lado operacional de uma migração, desde a preparação do servidor de destino e dos backups até à monitorização e validação. O objetivo não é tornar o processo misterioso. É garantir que alguém está a vigiar a infraestrutura enquanto mantém o negócio em movimento.

Uma boa migração termina silenciosamente: os visitantes usam o site, as tarefas agendadas correm, os backups são concluídos e ninguém tem de enviar uma mensagem nervosa para toda a equipa. Mantenha o plano, o backup e o servidor antigo até que as evidências digam que o serviço voltou a estar calmo.

Andres Saar Engenheiro de Apoio ao Cliente