A maioria das migrações de sites e aplicações não é difícil por causa da tecnologia. É difícil porque o ambiente antigo acumulou anos de decisões não documentadas: um cron job que alguém adicionou às pressas, um redirecionador de e-mail do qual a equipe de vendas depende, um endereço IP fixo no código de um callback de pagamento.
Este guia descreve um método de migração que mantém a indisponibilidade na faixa de minutos, e não de horas, para stacks web típicas: sites de conteúdo, lojas de e-commerce, portais de clientes e aplicações de negócio rodando em hospedagem compartilhada, em uma única VPS ou em um servidor físico antigo.
O que mínimo de indisponibilidade realmente significa
Indisponibilidade zero é possível, mas geralmente exige uma aplicação capaz de rodar em dois lugares ao mesmo tempo sobre um banco de dados compartilhado ou replicado. A maioria das stacks legadas não consegue. Uma meta mais realista é um congelamento de escritas curto e agendado: o período entre interromper as escritas no sistema antigo e aceitar escritas no novo. Para um site com alguns gigabytes de dados e um plano bem ensaiado, essa janela costuma ficar entre 5 e 30 minutos.
Defina a meta por escrito antes de qualquer trabalho começar. Estabeleça o congelamento máximo aceitável de escritas, a perda máxima aceitável de dados (idealmente nenhuma) e o horário do dia com menor tráfego.
Primeiro, monte um inventário completo
O inventário é o melhor indicador isolado de uma migração sem problemas. Levante-o a partir do sistema em execução, e não de memória ou de documentação antiga, e atribua um responsável a cada item.
- Domínios e DNS. Todos os domínios e subdomínios, o registrador, o provedor de DNS autoritativo e uma exportação completa dos registros atuais, incluindo os registros TXT usados para verificação.
- Aplicações e runtimes. Versões de linguagem (por exemplo, PHP 8.1 versus 8.3), servidor web e módulos, extensões, dependências do Composer ou do npm e quaisquer binários compilados.
- Armazenamentos de dados. Engines e versões de banco de dados, tamanhos dos bancos, caminhos e tamanhos do armazenamento de arquivos, quantidade de objetos e armazenamentos de sessão ou cache.
- Trabalhos agendados e em segundo plano. Entradas de cron, workers de filas, scripts de backup e qualquer job executado sob uma conta de usuário específica.
- Integrações. Gateways de pagamento, webhooks, relays SMTP, APIs que incluem seu endereço IP de saída em allowlist e conexões de SSO ou LDAP.
- Certificados e segredos. Certificados TLS e seu método de renovação, chaves de API, arquivos de ambiente e credenciais armazenadas em configuração.
- E-mail. Caixas postais, aliases, encaminhamentos, listas de distribuição, tamanhos das caixas e os clientes que as pessoas usam para se conectar.
Primeiro, procure no código e na configuração endereços IP fixos e caminhos absolutos de arquivos. Segundo, analise as conexões de saída ao longo de um dia útil normal (com uma ferramenta como ss ou netstat, ou com os logs do firewall) para encontrar integrações das quais ninguém se lembrava.
Prepare o DNS e o cronograma
O cache de DNS é o principal motivo pelo qual os usuários continuam chegando ao servidor antigo depois do cutover. Se o seu registro A tem um TTL de 86.400 segundos (24 horas), alguns visitantes podem continuar acessando o endereço IP antigo por um dia inteiro depois que você o alterar.
Reduza o TTL de todo registro que você pretende alterar para 300 segundos, e faça isso com antecedência de pelo menos um TTL antigo completo antes da virada, de preferência 48 horas antes. Alguns resolvers e proxies corporativos não respeitam TTLs curtos, então conte com uma cauda de tráfego chegando ao servidor antigo por várias horas de qualquer forma.
Confirme também quem controla as contas do registrador e do DNS, se a autenticação de dois fatores funciona e se as pessoas que vão executar o cutover conseguem fazer login.
Sincronize os dados sem paralisar o negócio
O objetivo é transferir quase todos os dados enquanto o sistema antigo ainda está no ar, para que a sincronização final, durante o congelamento de escritas, seja pequena. Um link de 1 Gbps transfere cerca de 10 TB por dia em plena carga, mas migrações reais raramente atingem a velocidade nominal, porque o servidor de origem, os limites da hospedagem compartilhada ou a grande quantidade de arquivos pequenos tornam tudo mais lento.
- Arquivos. Faça uma cópia completa inicial com uma ferramenta como o rsync e depois repita execuções incrementais diariamente. Cada execução transfere apenas as alterações, de modo que a passada final durante o cutover costuma levar de alguns segundos a poucos minutos.
- Bancos de dados com menos de alguns gigabytes. Um dump e restore durante o congelamento costuma ser aceitável. Cronometre uma restauração de teste para saber a duração real.
- Bancos de dados maiores ou mais movimentados. Configure a replicação do servidor antigo para o novo, deixe-a alcançar o primário e promova a réplica no cutover. Isso reduz o congelamento ao tempo necessário para interromper as escritas e confirmar que a réplica está atualizada.
- Uploads e conteúdo dos usuários. Se os usuários enviam arquivos continuamente, inclua os diretórios de upload na sincronização final ou aponte temporariamente os uploads para um armazenamento de objetos compartilhado que os dois lados consigam acessar.
Verifique os dados, não presuma. Compare a contagem de linhas das tabelas principais, checksums ou contagem de arquivos no armazenamento, e o ID do pedido, post ou registro mais recente nos dois lados.
Trate a migração de e-mail como um projeto à parte
O e-mail muitas vezes fica na mesma conta de hospedagem compartilhada que o site, e falha de um jeito diferente. Trate-o como uma frente de trabalho separada, com seu próprio horário de cutover, mesmo que o destino seja o mesmo provedor.
Crie primeiro as caixas postais na nova plataforma e depois copie os e-mails existentes com uma ferramenta de sincronização IMAP, executando uma passada incremental final depois que os registros MX mudarem. Publique os registros SPF, DKIM e DMARC dos novos servidores de envio antes da troca e mantenha o servidor antigo aceitando e-mails por pelo menos uma semana, para que mensagens de remetentes com DNS desatualizado não sejam devolvidas.
Escreva o plano de virada e o plano de rollback
Um plano de cutover é um runbook numerado com horários, responsáveis e uma decisão de seguir ou não seguir em cada etapa crítica. Ensaie-o pelo menos uma vez em uma cópia de staging, cronometrando cada etapa, para que a janela real não traga surpresas.
Uma sequência típica é a seguinte: anuncie a janela, ative uma página de manutenção ou coloque a aplicação em modo somente leitura, execute a sincronização final de arquivos e do banco de dados, rode as verificações, atualize os registros DNS, teste o novo ambiente pelo novo endereço e, então, reabra as escritas.
Defina com antecedência quais condições o acionam (por exemplo, erros no checkout acima de uma taxa acordada ou uma verificação de dados que falhou) e quem tem autoridade para acioná-lo. Mantenha o ambiente antigo intacto e em funcionamento por 7 a 14 dias.
Valide e depois faça o ajuste fino
A validação começa no momento em que o DNS muda e continua por vários dias. Teste de fora da sua rede, e de mais de um país se os seus usuários forem internacionais.
- Verificações funcionais. Página inicial, login, busca, formulários, checkout e qualquer transação crítica para o negócio, executados de ponta a ponta com contas de teste.
- Verificações técnicas. TLS válido em todos os hostnames, redirecionamentos corretos, nenhum alerta de conteúdo misto, códigos de status HTTP em um rastreamento das URLs principais e logs de erro limpos.
- Trabalho em segundo plano. Confirme que os cron jobs rodaram no horário, que as filas estão sendo esvaziadas, que os backups foram concluídos e que o e-mail de saída está sendo entregue.
- Integrações. Peça aos parceiros que atualizem as allowlists de IP e depois confirme que os callbacks de pagamento e os webhooks chegam ao novo ambiente.
Migrações normalmente começam com um dimensionamento conservador, então revise as métricas de CPU, memória e disco após uma a duas semanas de tráfego real e redimensione para cima ou para baixo. Ative o cache de objetos (por exemplo, Redis) e uma CDN para os arquivos estáticos, ajuste as configurações de memória do banco de dados ao novo hardware e defina limites de alerta com base nas linhas de base observadas, e não nos valores padrão. Por fim, faça uma restauração de teste a partir do novo sistema de backup.
Checklist de migração passo a passo
- Duas a quatro semanas antes. Conclua o inventário, defina os responsáveis, estabeleça o congelamento de escritas e as metas de perda de dados e escolha a janela de cutover.
- Duas semanas antes. Provisione o novo ambiente, alinhe as versões de runtime, faça o deploy da aplicação em staging e execute uma cópia completa inicial dos dados.
- Uma semana antes. Ensaie o cutover em staging, cronometre cada etapa, finalize o runbook e os gatilhos de rollback e confirme o acesso ao registrador e ao DNS.
- Quarenta e oito horas antes. Reduza os TTLs para 300 segundos, inicie sincronizações incrementais diárias ou a replicação do banco de dados e avise usuários e parceiros.
- Dia do cutover. Ative a página de manutenção, execute a sincronização final, rode as verificações de dados, altere os registros DNS e MX, valide pelo novo endereço e reabra as escritas.
- Primeiras 72 horas. Monitore erros e desempenho, execute verificações funcionais diariamente, sincronize o e-mail restante e mantenha o caminho de rollback pronto.
- Após duas semanas. Ajuste o dimensionamento dos recursos, ative cache e CDN, teste uma restauração completa, devolva os TTLs aos valores normais e desative o ambiente antigo.
Como a Vonahost pode ajudar
A nuvem gerenciada da Vonahost opera na plataforma própria da Vonahost, na AWS ou no Google Cloud, com CDN, backups, SSL, monitoramento, ambientes de staging, Redis e Elasticsearch incluídos. Você escolhe o país onde cada servidor é executado, e os dados não são transferidos sem a sua aprovação.
Se você está planejando sair de uma hospedagem compartilhada ou de um servidor mais antigo, a Vonahost pode revisar seu inventário e propor um ambiente de destino. Toda proposta informa a configuração, a localização, as responsabilidades de cada lado e o preço mensal em dólares americanos, para que o escopo da migração fique claro antes do início dos trabalhos.