Como migrar um servidor ou VPS sem downtime: passo a passo e checklist

Migrar um servidor não é apenas copiar arquivos e trocar o IP. Sem planejamento, a mudança pode causar indisponibilidade, inconsistência ou perda de dados, banco desatualizado, falhas de DNS e SSL, além de APIs, jobs e webhooks que deixam de funcionar. A página inicial abrir no destino não comprova que o sistema inteiro foi migrado.

O caminho seguro é preparar o novo ambiente, testar sem interferir na produção, sincronizar os dados e controlar o corte. Downtime zero depende da arquitetura, da aplicação e do banco de dados. Replicação, roteamento e tratamento de sessões precisam permitir a transição; em outros cenários, uma pausa de escrita pode ser necessária para preservar a consistência.

Este roteiro prioriza o mínimo de indisponibilidade possível, sem transformar uma promessa comercial em garantia técnica. Antes de começar, defina quem autoriza o corte, quais testes liberam o destino e em que condições a operação será interrompida.

Quando vale a pena migrar um servidor?

A migração faz sentido quando CPU, RAM ou disco limitam a operação, o servidor está lento, o custo deixou de compensar, o provedor apresenta falhas recorrentes ou o negócio precisa escalar. Também pode resolver restrições de rede, suporte ou localização, desde que o destino realmente atenda à necessidade identificada.

Os cenários incluem migrar um site da hospedagem compartilhada para VPS, transferir uma VPS para outro provedor, trocar um dedicado por VPS ou cloud e mudar de datacenter ou região. Nesta última, avalie latência para usuários e integrações, além dos requisitos de localização dos dados. Mudar a infraestrutura não corrige automaticamente consultas lentas ou vazamentos de memória.

Antes de contratar, use o checklist para servidor Linux lento para identificar gargalos e compare VPS, cloud e servidor dedicado conforme carga, disponibilidade e orçamento.

O que verificar antes de iniciar a migração?

Monte um inventário verificável. Registre configurações e responsáveis, mas guarde credenciais em local protegido, não em documentos compartilhados sem controle.

Um backup existente não basta: confirme integridade, acesso e restauração. O rollback precisa explicar como recuperar o serviço e os dados, não apenas como desfazer o DNS.

Como migrar um servidor com o mínimo de downtime

Adapte estes 15 passos ao inventário. Não combine migração com grandes atualizações sem necessidade: quanto menos variáveis mudarem, mais simples será validar e recuperar.

1. Auditar o ambiente atual

   Mapeie serviços, dados mutáveis, dependências e desempenho. Planeje a redução do TTL desde agora, antes do corte, considerando o TTL antigo. Defina backup, janela, responsáveis e critérios objetivos de rollback.

2. Preparar o novo servidor

   Provisione CPU, RAM, disco e rede adequados. Configure sistema, horário, armazenamento e acesso de recuperação. Reserve espaço para restauração, arquivos temporários e logs, não apenas para os dados finais.

3. Instalar as dependências compatíveis

   Reproduza versões de runtimes, bibliotecas, Docker e serviços auxiliares. Confirme extensões e conectividade. Prefira compatibilidade comprovada à instalação indiscriminada da versão mais recente durante a mudança.

4. Configurar a segurança

   Aplique usuários, chaves SSH e firewall com acesso administrativo restrito. Abra somente portas necessárias, preserve permissões e proteja secrets. Não exponha o banco à internet para facilitar a transferência.

5. Fazer a cópia inicial

   Transfira arquivos e configurações por canal seguro. Uma cópia inicial com rsync reduz o volume restante, mas não produz um backup consistente do banco. Nunca trate a cópia do diretório de dados de um banco ativo como restauração válida.

6. Restaurar e configurar o banco

   Use backup consistente ou replicação planejada. Configure usuários, permissões, extensões e conexões. Esta restauração prepara os testes; dados escritos depois do backup ainda precisam chegar ao destino antes da liberação.

7. Configurar as aplicações

   Ajuste serviços, proxy, variáveis, persistência e caminhos. Preserve URLs públicas exigidas por integrações. Mantenha cron e workers desativados no destino durante a preparação para evitar processamento duplicado.

8. Testar antes de publicar

   Use IP ou hostname temporário; para testar HTTPS e rotas reais, direcione a conexão ao novo IP preservando o Host original e o SNI. Isole dados e credenciais de teste, bloqueie e-mails, jobs e chamadas com efeitos reais. Preserve URLs externas de produção, usando sandbox ou bloqueios nos ensaios.

9. Reduzir o TTL com antecedência

   Execute a redução planejada antes da janela e aguarde o TTL antigo dos registros envolvidos. Se não houve antecedência suficiente, ajuste o plano. Baixar o TTL no momento do corte não apaga caches existentes.

10. Pré-sincronizar as alterações

    Atualize arquivos mutáveis e acompanhe o atraso da replicação, quando utilizada. Meça o volume restante e ensaie a etapa final. A pré-sincronização não elimina a necessidade de tratar alterações posteriores.

11. Controlar escritas e sincronizar definitivamente

    Quando necessário, bloqueie escritas na aplicação, pause produtores, cron e workers, drene tarefas e aguarde transações em andamento. Só depois faça a sincronização definitiva de banco e arquivos, ou confirme o catch-up completo da replicação. A promoção deve garantir um único destino autoritativo de escrita.

12. Realizar o corte de tráfego

    Atualize DNS ou load balancer e controle o drain de conexões existentes; WebSockets e sessões abertas não migram apenas com DNS. Durante os caches, a origem deve permanecer em manutenção, somente leitura ou encaminhar ao novo backend. Nunca deixe bancos ou volumes independentes recebendo escritas nos dois lados.

13. Validar a operação no destino

    Confirme destino das requisições, SSL, login, API, banco e uploads. Libere a escrita de forma controlada e execute transações verificáveis. Ative cron e workers somente no novo ambiente, conferindo filas e webhooks sem duplicações.

14. Monitorar após a mudança

    Compare erros, latência, CPU, RAM, disco e conexões com a referência. Observe logs, backlog das filas e acessos ainda chegando à origem. Confirme também tarefas que só executam em horários específicos.

15. Manter a origem para recuperação

    Preserve o servidor antigo protegido e sem escrita independente durante o período acordado. Depois de novas escritas no destino, rollback exige reconciliar ou replicar dados e controlar outra transição; voltar o DNS sozinho pode perder registros. Desative a origem apenas após validação e backup recuperável.

Migração de aplicações Docker

Copiar o Compose não copia os volumes. Inventarie volumes nomeados, persistentes externos e bind mounts, incluindo uploads, configurações e dados fora do diretório do projeto. No destino, confira caminhos absolutos, UID/GID, permissões, capacidade do storage e driver utilizado. Um container saudável pode estar gravando em um diretório vazio por montagem incorreta.

Fixe versões ou digests das imagens, valide acesso ao registry e compatibilidade do Docker e do Compose. Recrie redes e dependências, revise portas e injete variáveis e secrets com proteção. Não confie em imagens locais que nunca foram publicadas ou preservadas. Teste a ordem de inicialização e a disponibilidade real do banco, cache e filas.

Para bancos em containers, use o mecanismo de backup do banco: docker cp ou rsync sobre dados ativos não substituem backup consistente. Isole o ambiente de teste das integrações reais. No Coolify, inventarie configurações de projetos, domínios, serviços, persistência e secrets; valide a recuperação conforme a versão instalada, sem pressupor exportação automática de todo o ambiente.

Migração de PostgreSQL e MySQL/MariaDB

Escolha dumps e restauração ou replicação conforme tamanho, compatibilidade e janela disponível. Confira versões de origem, destino e ferramentas. No PostgreSQL, inclua extensões, roles, owners e permissões necessários; no MySQL/MariaDB, revise usuários, grants, triggers, rotinas e eventos. Confirme quais objetos o método escolhido realmente inclui.

O pg_dump trabalha com um snapshot consistente do banco exportado, mas novas escritas posteriores ficam fora desse dump. Ele não representa sozinho todos os objetos globais nem sincroniza uploads da aplicação. Bancos distintos e arquivos relacionados podem exigir coordenação adicional para representar o mesmo estado de negócio.

No mysqldump, uma estratégia de transação consistente depende de engines transacionais e das opções utilizadas. Tabelas não transacionais e alterações de estrutura, como DDL durante a exportação, exigem cuidados adicionais. Não suponha que qualquer dump feito com o sistema ativo será adequado.

Planeje o freeze final das escritas ou uma replicação testada com verificação de atraso e promoção. Após restaurar, valide registros críticos, contagens, índices, constraints, sequences ou auto incremento, encoding, collation e timezone. Teste consultas e integrações pela aplicação: um restore sem erro não garante que permissões, arquivos associados e comportamento estejam corretos.

DNS: onde muitas migrações dão problema

Revise A, AAAA e CNAME de cada domínio. Um A atualizado com AAAA antigo pode dividir o tráfego entre servidores. CNAMEs têm destinos e caches próprios; consulte a cadeia completa. Não existe prazo universal de propagação: TTL antigo, resolvedores e caches locais influenciam o resultado, e reduzir o TTL não remove respostas já armazenadas.

Com a nuvem laranja da Cloudflare, o visitante acessa a borda, não diretamente o IP de origem. Confirme o novo destino na configuração e teste a conexão borda–origem. O proxy não corrige dados desatualizados, backend indisponível ou rotas erradas. Evite desligar proteções arbitrariamente para tentar acelerar a mudança.

Teste o novo servidor antes do corte e mantenha o antigo respondendo de forma controlada durante a transição. Ele não deve aceitar escritas separadas: manutenção, leitura ou proxy para o backend novo evitam split brain enquanto visitantes ainda usam respostas antigas.

SSL depois da migração

Prepare HTTPS antes de liberar tráfego. No Nginx ou Traefik, confira domínio, rotas do proxy reverso, certificado, cadeia intermediária e redirecionamentos. Preserve permissões, armazenamento ACME e secrets usados pelo cliente do Let’s Encrypt, sem expô-los. Verifique a renovação automática e o acesso de escrita ao armazenamento necessário.

O desafio HTTP-01 exige acesso público adequado pela porta 80; a porta 443 atende HTTPS. DNS-01 pode permitir emissão antes do corte, se houver controle do DNS e configuração compatível, com credenciais protegidas. Escolha o método conforme o ambiente, sem repetir emissões às cegas.

Valide o certificado para o domínio real, não apenas pelo IP. Na Cloudflare, o certificado da borda é diferente do certificado da origem: ver o cadeado no navegador não comprova que a segunda conexão está configurada corretamente. Confira também renovação e ausência de loops de redirecionamento.

Checklist pós-migração

Registre o resultado e a evidência de cada teste. Inclua fluxos de negócio, não apenas verificações de infraestrutura.

• Site e API respondem no destino correto, inclusive endpoints críticos.
• Login, sessões, permissões e recuperação de acesso funcionam.
• Banco permite leitura e escrita com dados recentes e consistentes.
• Uploads persistem após reinício; arquivos antigos continuam acessíveis.
• Cron e workers executam apenas no destino, sem duplicações.
• Filas processam tarefas; backlog, falhas e retentativas estão sob controle.
• Webhooks e integrações externas recebem e enviam eventos corretamente.
• SSL válido para o domínio, cadeia correta, redirecionamentos e renovação configurados.
• DNS A, AAAA e CNAME estão corretos; acessos à origem são acompanhados.
• E-mail envia e recebe quando aplicável, com autenticação e DNS revisados.
• Backup no novo ambiente executa e tem restauração validada.
• Monitoramento e alertas estão ativos e acompanham o novo ambiente.
• Logs sem erros críticos de aplicação, banco, proxy e serviços.

Se um teste falhar, investigue a camada afetada antes de reverter tudo. O guia de diagnóstico de site fora do ar ajuda a separar rede, DNS, proxy, aplicação e banco durante essa validação.

Quanto tempo demora uma migração de servidor?

O prazo depende do tamanho dos dados, velocidade efetiva da rede, banco, quantidade de aplicações e arquitetura. Transferência, restauração, criação de índices, testes e correções podem consumir mais tempo que a troca de tráfego. DNS e a janela autorizada também influenciam o cronograma; não há uma quantidade de horas válida para todos os casos.

Separe duração do trabalho de indisponibilidade. Preparação e cópia inicial podem ocorrer com a origem funcionando, enquanto a pausa fica concentrada na sincronização final e no corte. Um ensaio com volume representativo permite estimar essa janela com mais confiança, incluindo margem para recuperação.

Posso migrar para uma VPS menor ou mais barata?

Sim, se o consumo real e os picos couberem no destino com folga. Compare CPU, RAM, IOPS, capacidade de disco, tráfego e latência, considerando banco e containers juntos. Uma VPS com menos recursos pode funcionar após otimização, mas métricas médias escondem picos e disputas por armazenamento.

Reserve margem para crescimento, backups, builds e manutenção. Inclua gastos de egress, snapshots e armazenamento adicional na comparação. Faça o diagnóstico antes de contratar: economizar na mensalidade e perder desempenho ou capacidade de restauração não representa necessariamente redução de custo.

Migração de servidores com a Jupiter TI

A Jupiter TI atua com Linux, VPS, migração de aplicações Docker e bancos, Nginx, Traefik, Coolify, SSL, DNS, backups, monitoramento e gerenciamento. O planejamento considera dependências, consistência dos dados e condições reais para reduzir a indisponibilidade.

Conheça o serviço de migração de servidores e o suporte para servidores Linux. Para necessidades complementares, consulte os serviços da Jupiter TI ou entre em contato para apresentar seu ambiente e a mudança desejada.