Como migrar sites com segurança

Publicado em 21 de junho de 2026

Uma migração de site segura começa antes que qualquer arquivo seja movido. Se você quer saber como migrar sites com segurança, a primeira tarefa não é copiar dados — é reduzir as incertezas. Verificamos a stack atual, congelamos alterações desnecessárias, confirmamos que os backups podem realmente ser restaurados e criamos um caminho de rollback antes de mexer no DNS. Essa é a parte que muitas equipes pulam, e depois os logs contam a mesma história.

Migrações falham por motivos banais. Um cron job esquecido continua gravando no banco de dados antigo. O DNS é virado antes que o SSL esteja pronto. As regras de redirecionamento são copiadas pela metade. O cache faz o novo site parecer correto para uma pessoa e quebrado para todas as outras. Nada disso é dramático, mas é caro. Uma migração segura é, em grande parte, sequenciamento disciplinado.

Como migrar sites com segurança sem surpresas de indisponibilidade

As migrações mais limpas começam com um inventário. Você precisa saber exatamente o que será movido, o que pode mudar durante a mudança e quais dependências ficam fora do servidor. Isso significa arquivos do site, bancos de dados, armazenamento de mídia, certificados SSL, zonas DNS, tarefas agendadas, roteamento de e-mail, integrações de API, callbacks de pagamento e regras de firewall. Se o site usa uma CDN, armazenamento externo de imagens, object cache ou busca de terceiros, inclua isso também.

É aqui que as equipes encontram as pequenas armadilhas. Uma loja WooCommerce pode depender de um webhook de pagamento apontando para o IP antigo. Uma aplicação SaaS pode ter queue workers em uma segunda máquina. Um site de marketing pode ser simples, mas o formulário de contato envia por meio de um serviço SMTP restrito pelo hostname do servidor. Migrações seguras raramente são sobre a página inicial. Elas são sobre as bordas.

Antes de mover qualquer coisa, decida que tipo de migração você está fazendo. Uma mudança equivalente de um VPS para outro tem um nível de risco. Migrar de hospedagem compartilhada para VPS gerenciado, trocar painéis de controle, atualizar o PHP e mudar o servidor web de Apache para Nginx ao mesmo tempo é outra história. Você pode fazer várias mudanças de uma vez, mas cada variável extra torna a solução de problemas mais lenta. Se possível, separe as mudanças de infraestrutura das mudanças da aplicação.

Comece com backups que você já testou

Todo provedor diz que existem backups. Isso é bom, mas um backup só é útil se for restaurado de forma limpa e rápida o suficiente para sua meta de recuperação. Crie um backup novo dos arquivos e bancos de dados imediatamente antes da migração. Mantenha também uma cópia fora do ambiente de origem, para não depender de uma única plataforma em um dia bom.

Se o site impacta a receita, faça uma restauração de teste em um ambiente de staging. Abra o site restaurado, verifique a conectividade com o banco de dados, confira as permissões de arquivo e garanta que a mídia carregue. Se você não puder testar a aplicação inteira, pelo menos confirme que o arquivo de backup está completo e que o dump do banco de dados é legível. Este não é um trabalho glamouroso, mas explicar ao financeiro por que os pedidos da noite passada desapareceram na floresta também não é.

Congele mudanças durante a janela de migração

Edições de conteúdo, instalações de plugins e implantações de código durante a migração criam problemas de split-brain. Um sistema é atualizado, o outro não, e agora ninguém sabe ao certo qual versão é real. Defina um congelamento curto de mudanças. Para sites com muito conteúdo ou transacionais, use o modo de manutenção ou coloque partes críticas em estado somente leitura durante a sincronização final.

Para e-commerce, reservas ou conteúdo gerado por usuários, planeje uma sincronização delta. Copie a maior parte dos arquivos e dados com antecedência e depois faça uma sincronização final durante a janela de cutover para capturar mudanças de última hora. Isso mantém o downtime baixo sem arriscar desvio de dados.

Construa o ambiente de destino antes do cutover

Um erro comum é tratar o servidor de destino como uma caixa vazia que pode ser configurada depois. A migração segura funciona do jeito oposto. O ambiente de destino deve estar pronto antes da troca: SO com patches aplicados, stack web instalada, versão do PHP confirmada, banco de dados ajustado, SSL preparado, backups agendados e monitoramento habilitado.

Atenda primeiro aos requisitos da aplicação e depois melhore com cuidado. Se o site antigo é executado em PHP 7.4 e a aplicação não é certificada para PHP 8.2, o dia da migração não é o momento para atos de bravura. Você pode modernizar depois que a estabilidade for confirmada. Primeiro calma, depois otimização.

Permissões e propriedade merecem atenção extra. Muitos incidentes de “o site migrou, mas os uploads falham” são apenas propriedade de usuário/grupo incorreta ou caminhos graváveis ausentes. Revise também cron jobs, queue workers e tarefas agendadas. Um site pode carregar bem enquanto um processamento importante em segundo plano parou silenciosamente há uma hora.

Teste usando um arquivo hosts ou URL temporária

Não aponte o DNS em produção até que o site tenha sido verificado no novo servidor. Use uma substituição no arquivo hosts ou um domínio temporário de pré-visualização para testar a aplicação de forma privada. Navegue pelas páginas principais, envie formulários, faça login como administrador, faça um pedido de teste se for relevante e verifique o envio de e-mails. Verifique imagens, busca, APIs, ações administrativas e qualquer coisa ligada a sessões ou cache.

Vá além das verificações visuais. Revise logs de erro, logs do servidor web, status do PHP-FPM, consultas lentas ao banco de dados e uso de disco. Confirme se os redirecionamentos funcionam como esperado. Certifique-se de que URLs canônicas, regras de robots e variáveis de ambiente estejam corretas. É surpreendentemente fácil migrar um site de produção com um cabeçalho noindex de staging ainda anexado. Os mecanismos de busca são obedientes nos piores momentos possíveis.

DNS, TTL e planejamento de cutover

Se você está aprendendo como migrar sites com segurança, DNS é onde a preparação compensa. Reduza o TTL nos registros DNS relevantes bem antes da janela de migração, idealmente com 24 a 48 horas de antecedência. Isso ajuda os resolvedores a atualizarem mais rápido quando você troca o site para o novo servidor. Não garante propagação global instantânea, mas reduz por quanto tempo os usuários podem chegar ao local antigo.

No cutover, atualize apenas o que for necessário. Normalmente isso significa o registro A, talvez AAAA e, às vezes, registros relacionados a e-mail se o e-mail também estiver sendo movido. Tenha cuidado para não misturar migração de site com migração de e-mail, a menos que haja um motivo claro. Combinar as duas aumenta o raio de impacto. A migração mais bonita muitas vezes é a que mudou menos coisas.

Mantenha o servidor antigo ativo por um período seguro de sobreposição. Mesmo após a mudança de DNS, alguns usuários e bots ainda chegarão ao host antigo por algum tempo. Durante esse período, monitore os logs de acesso nos dois sistemas. Se o servidor antigo ainda estiver recebendo tráfego significativo, mantenha-o disponível e, se possível, direcione a atividade de gravação com cuidado para não perder dados.

Fique atento a problemas de cache e SSL

Caches de CDN, caches da aplicação e cache local do navegador podem esconder problemas após a migração. Faça a limpeza onde for necessário. Se um cache de página inteira estiver em uso, limpe-o após a sincronização final e depois do cutover de DNS. Confirme se a origem da CDN foi atualizada, caso exista uma.

O SSL deve estar pronto antes da troca, não depois. Instale os certificados no novo ambiente, verifique a cadeia completa e teste o comportamento de HTTP para HTTPS. Avisos de conteúdo misto podem aparecer se URLs de ativos codificadas de forma fixa ainda apontarem para o domínio ou protocolo antigo. Esses são detalhes pequenos, mas os usuários percebem o ícone de cadeado mais rápido do que percebem seu planejamento cuidadoso.

Redirecionamentos, SEO e integridade da aplicação

Se o domínio permanecer o mesmo, o risco de SEO é menor, mas as verificações técnicas ainda importam. Certifique-se de que redirecionamentos de HTTP para HTTPS, de www para sem www ou o inverso, e quaisquer mapeamentos de caminhos antigos se comportem exatamente como esperado. Se o domínio mudar, use redirecionamentos 301 de forma abrangente e atualize tags canônicas, sitemaps e referências internas.

Não lance com cadeias de redirecionamento se puder evitá-las. Elas deixam tudo mais lento e criam bagunça de indexação. Verifique também páginas de erro personalizadas, robots.txt, geração de sitemap XML e dados estruturados se o site depender disso. Migração não é apenas “o site carrega”. É “o site se comporta corretamente em condições normais e de borda”.

Para aplicações dinâmicas, teste autenticação, sessões e permissões com funções reais de usuário. O admin pode funcionar enquanto o login do cliente falha por causa do escopo do cookie, armazenamento de sessão ou cabeçalhos de proxy. Isso é especialmente comum atrás de balanceadores de carga ou proxies reversos.

O plano de rollback faz parte da migração

Uma migração só é segura se a reversão for possível. Defina as condições de rollback com antecedência. Por exemplo: erros 5xx sustentados, falha no checkout, login quebrado, regressão severa de desempenho ou incompatibilidade de dados. Defina também quem toma a decisão de rollback e quanto tempo dura a janela de observação após o cutover.

O rollback deve ser simples o suficiente para ser executado sob estresse. Isso normalmente significa manter o ambiente antigo intacto, preservar o estado antigo do banco de dados se possível e reverter rapidamente o DNS ou o roteamento de tráfego. Se ocorreram gravações no novo ambiente, você precisa de uma política para reconciliação de dados. É por isso que sites transacionais exigem cuidado extra durante a troca final.

Monitore intensamente nas primeiras 24 horas

Após o cutover, acompanhe uptime, tempo de resposta, CPU, memória, E/S de disco, carga do banco de dados, validade do SSL, profundidade da fila e jobs de backup. Acompanhe também sinais visíveis para o usuário: fluxo de pedidos, formulários de contato, sucesso de login e relatórios de erro. Uma migração pode parecer boa no minuto dez e falhar na terceira hora, quando as tarefas agendadas entram em ação ou o cache expira.

É aqui que o suporte gerenciado mostra seu valor. Um bom monitoramento captura picos de recursos, serviços com falha e problemas de certificado antes que os clientes se tornem seu sistema de alertas. Para equipes sem grande profundidade operacional interna, essa camada operacional tranquila importa mais do que mais uma caixa de seleção em um plano de hospedagem.

Uma regra prática para migrações mais seguras

Não mude tudo só porque finalmente tem a oportunidade. Migre primeiro, estabilize depois, melhore em terceiro lugar. Essa ordem economiza tempo, mesmo que pareça mais lenta no papel. Se você precisa de ajuda para saber como migrar sites com segurança, o parceiro de hospedagem certo deve conseguir ajudar não apenas com o servidor em si, mas também com backups, monitoramento, planejamento de rollback e aqueles pequenos casos de borda incômodos que aparecem só depois da meia-noite.

Uma boa migração parece quase sem acontecimentos. Esse é o objetivo. Logs silenciosos, tráfego estável, formulários funcionando, nenhum desastre misterioso de cron e uma equipe que consegue dormir depois da troca de DNS. Na kodu.cloud, esse normalmente é o padrão que buscamos — nada espalhafatoso, apenas sob controle.

Andres Saar Engenheiro de Atendimento ao Cliente