Migrando sua aplicação de um VPS para outro sem downtime
Olá! Aqui é a Sensei da GeHost 🌸 Se você chegou até este guia, provavelmente está de olho num servidor mais robusto, mais rápido, ou só quer trocar de casa sem deixar o site "apagando luzes" no meio do caminho. Migrar uma aplicação entre servidores é como mudar de apartamento com a família toda dormindo dentro: dá pra fazer, mas exige planejamento, calma e um bom checklist. Vamos passo a passo, sem pressa.
💡 Dica da Sensei: "Sem downtime" não significa "sem risco". Significa reduzir o risco ao mínimo através de planejamento e testes antes de qualquer corte definitivo. Nunca migre em cima da hora — principalmente sextas à noite!
Passo 1 — Faça um inventário completo do que precisa migrar
Antes de tocar em qualquer servidor, escreva (sim, escreva mesmo) tudo que compõe sua aplicação:
- Código-fonte e dependências (linguagem, versão, bibliotecas)
- Banco(s) de dados e seus respectivos usuários/senhas
- Arquivos estáticos, uploads e mídias dos usuários
- Variáveis de ambiente, chaves de API e certificados SSL
- Configurações de e-mail, filas, cron jobs e serviços em segundo plano
Essa lista é o seu mapa. Sem ela, é fácil esquecer um pedacinho da aplicação e ele só aparecer quebrado depois da virada — geralmente no pior momento possível.
Passo 2 — Prepare o novo servidor com calma
Configure o servidor novo do zero, instalando as mesmas versões de linguagem, banco de dados e demais dependências do ambiente atual. A ideia aqui é criar um "gêmeo" do ambiente antigo, só que numa casa nova.
- Instale o sistema operacional, runtime e serviços necessários
- Restaure uma cópia recente do banco de dados
- Copie o código-fonte e os arquivos estáticos
- Configure as variáveis de ambiente e credenciais
💡 Dica da Sensei: teste tudo isso com a aplicação rodando em uma porta ou domínio temporário (tipo teste.seusite.com ou pelo IP direto), sem que ninguém do público veja ainda. É o seu "ensaio geral".
Passo 3 — Sincronize os dados continuamente
Enquanto o site antigo continua no ar recebendo visitantes normalmente, mantenha o banco de dados e os arquivos do servidor novo sincronizados com o antigo. Existem ferramentas de replicação de banco de dados e de sincronização de arquivos que fazem isso automaticamente, copiando só o que mudou de tempos em tempos. O objetivo é que, na hora do corte final, a diferença entre os dois servidores seja mínima — segundos, não horas.
Passo 4 — Reduza o TTL do DNS com antecedência
O DNS é o "GPS" que diz aos navegadores onde seu site mora. Ele guarda essa informação em cache por um tempo chamado TTL (tempo de vida). Se o TTL estiver alto (por exemplo, 24 horas), quando você trocar o endereço, muita gente vai continuar sendo levada pro servidor antigo por até um dia inteiro.
Por isso, de 24 a 48 horas antes da migração, reduza o TTL do registro DNS da sua aplicação para um valor bem baixo (poucos minutos). Isso faz com que, na hora da troca, a mudança se espalhe pela internet muito mais rápido.
Se o DNS do seu domínio for gerenciado pelo painel de hospedagem, é lá no Editor de Zona de DNS que você ajusta esse valor e, mais adiante, atualiza o endereço para o novo servidor.
Passo 5 — Teste tudo no servidor novo antes de virar a chave
Esse é o passo que mais economiza dor de cabeça. Antes de apontar qualquer domínio, teste a aplicação inteira no servidor novo:
- Login, cadastro e principais fluxos do usuário
- Envio e recebimento de e-mails
- Upload de arquivos e integrações externas (pagamento, APIs etc.)
- Certificado SSL instalado e funcionando
- Cron jobs e tarefas automáticas
💡 Dica da Sensei: peça pra uma segunda pessoa testar também, com outro olhar. Quatro olhos veem mais do que dois — principalmente quando você já está cansado de olhar pro próprio projeto.
Passo 6 — Faça o corte (cutover) num horário de baixo movimento
Chegou a hora da virada. Escolha um horário de menor acesso dos seus usuários (normalmente de madrugada) e siga esta ordem:
- Coloque a aplicação antiga em modo "somente leitura" ou pause novas escritas, se possível
- Faça uma última sincronização de dados entre o servidor antigo e o novo, garantindo que não falte nada
- Confirme mais uma vez que tudo está funcionando no servidor novo
- Atualize o registro DNS apontando para o novo servidor
Como o TTL já está baixo (Passo 4), a propagação tende a ser rápida — mas lembre-se que ela nunca é 100% instantânea para todo mundo, porque cada provedor de internet guarda cache à sua maneira.
Passo 7 — Monitore de perto após a virada
Nas primeiras horas depois do corte, fique de olho: acompanhe os logs da aplicação, o volume de acessos chegando no servidor novo e possíveis erros. Se notar algo estranho, tenha sempre um plano B claro — normalmente, voltar o DNS para o servidor antigo, que você vai manter ligado justamente por precaução (próximo passo).
Passo 8 — Mantenha o servidor antigo "de prontidão" por alguns dias
Não desligue o servidor antigo assim que a migração terminar. Por causa do cache de DNS, alguns visitantes ainda podem chegar até ele por um tempo — e ele também serve como sua rede de segurança caso algo precise ser revertido. Depois de alguns dias confirmando que tudo está estável no servidor novo, aí sim você pode desativá-lo com tranquilidade.
🌸 Resumo da Sensei: planeje, prepare um gêmeo do ambiente, sincronize os dados continuamente, abaixe o TTL antes, teste tudo, faça o corte num horário calmo, monitore de perto e só desligue o servidor antigo depois de confirmar que está tudo certo. Migração sem downtime não é mágica — é preparação!
Se tiver dúvidas durante o processo ou quiser apoio com a configuração do seu ambiente, é só chamar o suporte pelo painel.gehost.com.br. Boa migração! 🚀
