Migrar a loja Magento de servidor sem parar as vendas: o plano de corte

Janela de migração da loja virtual: quando trocar de servidor

Troca de servidor tem dois tempos: dias de preparação, que não afetam a loja, e uma janela curta de corte, que afeta. As regras que eu uso para marcar a data:

• Fora de pico. Com a Black Friday em 27/11/2026, migrar em novembro coloca um servidor sem histórico de carga na semana de maior movimento, com pouco tempo para corrigir o que aparecer. Se a hospedagem atual aguenta o pico, a migração fica para depois dele.
• Horário pelo dado. O horário do corte sai do relatório de pedidos por hora da própria loja, e não de suposição.
• Contrato antigo vivo. Não cancele a hospedagem atual antes de alguns dias de operação estável no servidor novo: ela é o caminho de volta.
• Migrar servidor não é atualizar versão. O servidor novo sobe com as mesmas versões da produção. Mudar duas coisas ao mesmo tempo esconde a causa de qualquer erro.

Migração de servidor de loja virtual passo a passo: o plano de corte

Os comandos do corte servem de prova para você pedir ao fornecedor:

dig +noall +answer www.sualoja.com.br
bin/magento maintenance:enable
bin/magento maintenance:status
rsync -a pub/media/ usuario@servidor-novo:/caminho/da/loja/pub/media/

O dig mostra o TTL em segundos, na segunda coluna da resposta. Pela documentação da Adobe, depois de ligar o modo de manutenção é preciso parar também os consumers das filas. O rsync no dia do corte transfere só o que mudou desde a cópia do T-2, e por isso a janela fica menor.

Mudar a hospedagem do Magento sem perder pedido: a conta da janela

Na janela há dois riscos, e eles puxam para lados opostos. Com a loja antiga em manutenção, os pedidos daquele intervalo não entram. Sem manutenção, parte dos clientes continua comprando no servidor antigo enquanto o DNS muda, e esses pedidos ficam num banco que já foi copiado: alguém precisa lançar cada um no servidor novo, com estoque, pagamento, nota e integração.

A conta ajuda a escolher o horário. Exemplo: numa loja com média de 6 pedidos por hora no horário escolhido, uma janela de 90 minutos em manutenção deixa de receber cerca de 6 × 1,5 = 9 pedidos, e parte desses clientes volta depois. O mesmo corte num horário com 20 pedidos por hora afeta cerca de 20 × 1,5 = 30. Troque pelos números do seu relatório de pedidos por hora e pelo tempo medido na cópia do T-2.

TTL do DNS na troca de servidor da loja: o TTL é o intervalo, em segundos, em que a resposta do DNS pode ficar em cache antes de ser consultada de novo (RFC 1035). Se o registro estava com TTL de um dia, a redução precisa acontecer mais de um dia antes do corte. Mesmo com o TTL baixo, a loja antiga fica em manutenção até o fim da semana: quem ainda cair nela não fecha pedido lá.

Checklist pós-migração de hospedagem Magento: o que mais se esquece

• IP novo liberado no gateway de pagamento, no ERP, na transportadora e em qualquer hub de marketplace que filtre por IP.
• Cron do Magento instalado no servidor novo (bin/magento cron:install) e rodando. A Adobe lista entre as tarefas que dependem do cron a reindexação e todos os e-mails, inclusive a confirmação de pedido.
• Consumers das filas ativos, pelo cron ou pelo gerenciador de processos que a loja usa.
• SPF e DKIM ajustados se o servidor novo envia e-mail direto; sem isso, o e-mail de pedido pode ir para o spam ou ser recusado.
• Certificado pronto antes do corte. Na validação HTTP-01 do Let's Encrypt, o desafio é buscado no próprio domínio, que ainda aponta para o servidor antigo: use outro tipo de validação ou leve o certificado atual.
• Permissões e dono dos arquivos como o servidor web e o PHP esperam.
• Endereços no app/etc/env.php: banco, cache, sessão, busca e fila apontando para os serviços do servidor novo.
• Sessões: se não forem copiadas, cliente logado precisa entrar de novo.
• Backup e monitoramento apontados para o servidor novo, e não para o antigo.
• Arquivo hosts limpo nas máquinas de quem testou, para que o teste final passe pelo DNS público.

Critério de rollback: quando voltar para o servidor antigo

O critério de volta se decide antes da janela, por escrito. Os gatilhos que eu uso:

• a compra de teste não fecha no servidor novo, por pagamento, frete ou erro de página;
• o pedido de teste não chega ao ERP ou o e-mail de pedido não sai, sem correção à vista;
• erro de servidor nas páginas de categoria, produto ou carrinho.

Voltar é apontar o DNS de novo para o IP antigo e tirar a loja antiga da manutenção; com o TTL baixo, a volta é rápida. O custo está nos pedidos que entraram no servidor novo nesse meio tempo, que precisam ser lançados no antigo. Por isso o teste pelo arquivo hosts vem antes da troca do DNS. Tela estranha depois do corte tem leitura própria: veja o que cada tela de erro do Magento significa. E antes de marcar a data, confira se a cópia tem todas as partes da lista do que o backup precisa conter.