A migração de hospedagem empresarial sem parar o site exige planejamento, validações e um corte (DNS) controlado para evitar perdas de vendas e SEO. Neste checklist, você confere o que preparar, como executar com zero downtime e quando envolver um time especializado para reduzir riscos.
Migração de hospedagem empresarial: como garantir zero downtime na prática
Zero downtime é possível quando a migração é tratada como projeto: inventário, ambiente espelhado, sincronização de dados e troca de DNS com janela segura. O objetivo é que o usuário sempre encontre o site respondendo, mesmo enquanto você muda de servidor.
Para agências, e-commerce e web designers, o ponto crítico é coordenar cache, SSL, banco de dados e e-mails, evitando inconsistências e "surpresas" após o corte. Atualizado em fevereiro de 2026.
O que normalmente causa indisponibilidade (e como prevenir)
Quedas acontecem por falhas previsíveis: TTL alto no DNS, SSL mal instalado, sincronização incompleta do banco e cache servindo conteúdo antigo. Prevenir é mais barato do que "apagar incêndio" com carrinho abandonado e tickets do suporte.
- DNS com TTL alto: reduz a velocidade de propagação do corte. Ajuste antes da migração.
- Banco fora de sincronia: pedidos e cadastros podem se perder. Use estratégia de replicação ou janela de escrita controlada.
- SSL/HTTPS quebrado: gera erro de segurança e derruba conversão. Valide cadeia e renovação.
- Diferenças de versão (PHP, MySQL/MariaDB): quebram plugins/temas. Homologue em staging.
- Jobs e CRON não migrados: rotinas de e-commerce e integrações param silenciosamente.
Checklist pré-migração (antes de copiar qualquer arquivo)
Antes de mover dados, você precisa reduzir variáveis: mapear dependências e definir o plano de corte. Essa etapa define se a migração será previsível ou uma sequência de correções emergenciais.
Use o checklist abaixo como "pré-flight" para ambientes WordPress, lojas e sites institucionais com integrações.
Inventário técnico e requisitos
- Mapeie o escopo: site(s), subdomínios, APIs, ambientes (produção/staging), tarefas CRON, filas e caches.
- Liste integrações: gateways de pagamento, ERPs, CRM, webhooks, SMTP, antifraude, CDN, WAF.
- Registre versões: PHP, extensões, Nginx/Apache, MySQL/MariaDB, Redis, Elasticsearch (se houver).
- Defina RTO/RPO: tempo máximo aceitável para recuperação e perda máxima de dados (ideal: RPO próximo de zero).
DNS e e-mail (as duas áreas que mais "vazam" problema)
DNS e e-mail costumam ser esquecidos, e isso vira incidentes: formulários não entregam, clientes não recebem confirmação de pedido, e o time perde tempo rastreando MX/SPF/DKIM.
- Baixe o TTL dos registros relevantes (A/AAAA, CNAME, www) com antecedência (ex.: 24–48h).
- Exporte a zona DNS atual e documente todos os registros.
- Valide e-mail: MX, SPF, DKIM e DMARC; confirme se haverá mudança de provedor de e-mail ou só do site.
- Mapeie serviços externos que dependem do domínio (ex.: verificação de domínio, webhooks, SSO).
Backups e plano de rollback
Backup não é "ter um arquivo zipado". É ter restauração testada e um caminho claro para voltar ao estado anterior sem perda operacional.
- Backup completo (arquivos + banco) e backup incremental próximo ao corte.
- Teste de restore em ambiente separado para validar integridade.
- Plano de rollback: quem executa, em quanto tempo, e quais sinais acionam a volta.
Execução com zero downtime: staging, sincronização e corte controlado
A execução segura segue um padrão: criar um ambiente novo idêntico, migrar dados, validar, sincronizar alterações e só então trocar o DNS. Assim, o tráfego nunca "cai no vazio".
Para e-commerce, o cuidado extra é com o banco de dados (pedidos, estoque, usuários) e com sessões/carrinho.
1) Suba um ambiente espelhado (staging/preview)
O novo servidor deve rodar com a mesma aplicação e configurações compatíveis. A homologação precisa simular o máximo possível da produção, incluindo cache e HTTPS.
- Configure o stack (PHP, banco, webserver) e limites (memory_limit, max_execution_time) conforme o projeto.
- Importe arquivos e banco iniciais para o novo ambiente.
- Teste rotas críticas: home, categoria, produto, checkout, login, busca, formulários e páginas com maior tráfego.
- Valide headers e cache (CDN, page cache, object cache) para evitar conteúdo "congelado".
2) Sincronize dados próximos ao corte (o "delta")
Entre a primeira cópia e o momento da virada, o site continua recebendo alterações. Zero downtime depende de sincronizar esse delta com estratégia adequada ao seu sistema.
- Sites institucionais: normalmente basta um freeze curto de conteúdo ou uma sincronização final do banco.
- E-commerce: considere replicação, manutenção de escrita por janela curta, ou mecanismo de fila para evitar pedidos divergentes.
- Uploads: garanta que mídias novas (imagens) também sejam sincronizadas.
3) Corte de DNS com validação em paralelo
Com TTL baixo, a troca de DNS propaga rápido. Durante a propagação, usuários podem alternar entre servidores; por isso, o ambiente novo precisa estar pronto para atender 100% do tráfego.
- Ative SSL no novo ambiente e valide redirecionamentos (www, http→https).
- Troque os registros (A/AAAA/CNAME) e monitore propagação.
- Mantenha o servidor antigo ativo por um período de segurança para absorver resoluções antigas.
Validações pós-migração que protegem vendas, SEO e reputação
Após o corte, o trabalho é confirmar que a operação está íntegra e que o Google e os usuários não estão vendo erros. As validações abaixo reduzem chargeback, abandono e queda de posicionamento.
O ideal é monitorar por 24–72 horas com logs, métricas e testes de jornada.
Checklist pós-corte (produção)
- HTTP status: verifique 200/301/302 e elimine 404 em páginas críticas.
- Performance: TTFB, LCP e estabilidade sob pico; ajuste cache e compressão.
- Checkout e pagamentos: teste compra real (ambiente de produção) e retorno do gateway.
- E-mails transacionais: confirmação de pedido, reset de senha, formulários e SMTP.
- Search Console/Logs: monitore picos de erro de rastreamento e redirecionamentos inesperados.
- CRON e rotinas: reative e valide tarefas (ex.: sincronização de estoque, webhooks, relatórios).
Quando terceirizar a migração: sinais de que você precisa de um time especializado
Terceirizar faz sentido quando o custo do risco supera o custo do serviço. Se o site fatura diariamente, uma hora instável pode custar mais do que uma migração bem conduzida.
Para agências, também é uma forma de proteger SLA e reduzir retrabalho com incidentes de infraestrutura.
Indicadores práticos
- Seu e-commerce depende de integrações (ERP, antifraude, múltiplos meios de pagamento) e não pode perder pedidos.
- Há múltiplos domínios, subdomínios, APIs e rotinas CRON.
- Você já teve problemas com DNS, SSL, e-mail ou cache em migrações anteriores.
- Precisa de janela de mudança curta (ex.: madrugada) com validação e rollback planejados.
Por que fazer com a Hivehost: foco em previsibilidade, performance e suporte
A diferença entre "migrar" e "migrar sem trauma" está no método e no acompanhamento. A Hivehost atua com checklist, homologação e corte assistido para reduzir risco operacional e proteger receita.
Você ganha um processo orientado a impacto: menos incerteza, menos retrabalho e mais estabilidade no pós-migração.
O que você deve exigir do provedor na migração
- Plano de migração com etapas, responsáveis e critérios de sucesso.
- Ambiente de staging para validação antes do corte.
- Estratégia de sincronização para banco e uploads (principalmente em e-commerce).
- Monitoramento e suporte durante e após a virada.
- Rollback documentado e executável.
Perguntas Frequentes
Quanto tempo leva uma migração sem parar o site?
Depende do volume de dados e integrações. Em muitos projetos, a preparação e validação levam mais tempo que o corte de DNS, que pode ser feito em minutos com TTL baixo.
Preciso colocar o site em manutenção para migrar?
Nem sempre. Para sites institucionais, geralmente não. Para e-commerce, pode haver uma janela curta para garantir consistência de pedidos, dependendo da estratégia de sincronização.
O que é TTL e por que ele importa no DNS?
TTL é o tempo que provedores e dispositivos "guardam" o DNS em cache. TTL alto torna a troca mais lenta; reduzir antes da migração acelera a propagação.
Vou perder posicionamento no Google ao trocar de hospedagem?
Se URLs, redirecionamentos, HTTPS e performance forem mantidos ou melhorados, a tendência é não perder. Quedas acontecem quando surgem erros 404, instabilidade ou lentidão prolongada.
Como garantir que o SSL não vai quebrar?
Instale e valide o certificado no novo servidor antes do corte e teste redirecionamentos. Também confirme renovação automática e cadeia completa do certificado.
E se algo der errado após a virada?
Um plano de rollback permite voltar rapidamente ao ambiente anterior. O ideal é manter o servidor antigo ativo por um período e ter backups restauráveis testados.
Vocês migram WordPress e e-commerce?
Sim. O processo inclui validação de plugins/temas, banco de dados, rotinas e testes de jornada (incluindo checkout) para reduzir risco operacional.
Se a sua empresa não pode correr o risco de instabilidade, a migração precisa ser conduzida com método e suporte. Fale com a Hivehost agora mesmo.
