Migre WordPress para outro host sem perder seus pedidos

9 min de leitura

Uma migração de WordPress para outro host, com o mesmo domínio, deverá preservar os pedidos, seus pagamentos e atualizações de estoque. O ponto crítico não é a cópia: é o momento em que o servidor antigo para de escrever e o novo passa a ser a única autoridade.

Um backup restaura um estado passado. Uma migração organiza a continuidade entre dois estados. Prepare o novo servidor enquanto o armazenamento permanece aberto, congele as gravações, sincronize e abra somente após a validação.

Corrija autoridade e acesso antes de qualquer cópia

Combine o acesso a hospedagem, DNS e serviços de pagamento. Identifique quem autoriza o congelamento, quem executa a troca e quem valida os comandos. O gerente da loja deve poder recusar a reabertura.

Faça um inventário de versões de PHP e WordPress, extensões, armazenamento de comandos, mídia, tarefas agendadas, remetentes de e-mail e conexões logísticas. Adicione webhooks de entrada e saída, API modificando estoque e dados armazenados em outro lugar.

WordPress pede para salvar os arquivos do site e seu banco de dados antes de mudar de servidor ^[3]. Uma restauração completa requer estes dois conjuntos ^[2]. Verifique também sua restauração em ambiente isolado.

Combine uma regra operacional: apenas um servidor pode aceitar gravações. Valide as condições de processamento de dados no novo host, restrinja o acesso aos clones e planeje sua exclusão após a validação.

Cópia para preparar, sem abrir uma segunda loja

O exemplo é fictício e não descreve um cliente de 4SYSTEM: uma loja de peças de reposição ainda está recebendo pedidos durante a cópia preparatória. O antigo site continua sendo a referência. O clone é usado para verificar hospedagem, mídia, carrinho de compras e conexões, e não para produzir pedidos reais.

Isole este clone antes de seu primeiro início: bloqueie o envio de e-mails, pagamentos reais, chamadas logísticas e a execução de tarefas. Uma visualização local com o domínio normal não constitui proteção.

Com assinaturas WooCommerce, manter o mesmo domínio após copiar o banco de dados não aciona o modo de teste: as renovações podem ser processadas em modo real ^[9]. Portanto, não se deixe enganar pela palavra “pré-produção” no painel de hospedagem.

Mantenha as URLs públicas usuais e ajuste a conexão com o banco de dados se seus parâmetros mudarem: WordPress distingue entre manter o domínio e alterar a configuração ^[3]. Adie atualizações funcionais: elas complicariam o diagnóstico e a reversão.

Migração de WordPress para outro host: congelar e depois sincronizar

A cópia preparatória fica desatualizada assim que chega um novo pedido. Para obter o estado de alternância, siga esta ordem:

1. Feche a passagem do pedido e suspenda alterações de back office, importações, sincronizações e gravação de chamadas API. Uma simples página de manutenção não é suficiente.
2. Reconcilie pagamentos já efetuados com pedidos do site antigo. As notificações em trânsito devem ser processadas lá antes de serem cortadas ou mantidas em uma fila durável para reprodução testada.
3. Verifique as opções de recuperação do provedor de pagamento. Não confirme o recebimento de um webhook sem preservação duradoura. Sem repetição documentada ou possível reconciliação, adie a troca.
4. Interrompa tarefas WordPress, hospedando crons e arquivos de extensões. Registrar o último estado permitido e os eventos ainda pendentes.
5. Crie o backup final, baseie os arquivos; restaurar os arquivos e depois o banco de dados para o destino isolado, de acordo com a ordem recomendada por WordPress ^[2].

A sincronização final substitui o estado preparatório pelo conjunto coerente de dados congelados, incluindo as tabelas de extensão e mídia recente. Não copie apenas pedidos: estoques, contas, notas e status relacionados devem seguir. Exigir prova de congelamento e reconciliação de ordens pendentes antes de autorizar DNS.

Alternar DNS sem criar dois sites ativos

Observe os registros que realmente direcionam o tráfego da web: IPv4, IPv6 e possivelmente CDN. Verifique se a alteração planejada não afeta os registros de email. Se você reduzir o TTL, faça-o com antecedência e anote seu valor anterior.

O DNS não alterna todos os visitantes simultaneamente. Alguns caches ainda podem levar ao servidor antigo, enquanto outros chegam ao novo. Portanto, escolha o novo como autoridade de escrita, independentemente do que seu navegador vê.

O servidor antigo deve permanecer incapaz de aceitar comandos, retornos de chamada ou modificações administrativas. Mantenha-o em manutenção; uma retransmissão para o destino só é aceitável após validação técnica do roteamento e das assinaturas dos webhooks.

Controle HTTPS, domínio canônico, administração e caches de múltiplos acessos. A exibição não prova que a base correta está respondendo, nem que todos os pagamentos estão chegando até ela. Guarde o comprovante do endereço do servidor contatado.

Receba a recuperação e neutralize as automações antigas

A receita começa antes de abrir: conexão de administrador, mídia, cesta, entrega, impostos e processo de pagamento em modo teste, sem cobrança real no clone. Em seguida, compare os exemplos de pedidos e pagamentos pendentes com o status final salvo e as referências do provedor de serviços. Verifique seus status, classificações e ações associadas.

Reative o processamento no novo servidor somente após esta validação. Verifique cada fila antes de iniciar para evitar a repetição de uma ação que já foi executada. A reprodução dos webhooks deve controlar seus identificadores para evitar duplo processamento. Reabra pedidos e rastreie um pedido autorizado por meio de notificação e processamento logístico.

O alojamento antigo mantém os seus automatismos desde que não os neutralize. Para assinaturas, o modo de teste não interrompe todos os eventos agendados e outras extensões ainda podem enviar e-mails ^[9]. Controle separadamente o Action Scheduler, WP-Cron, crons externos e remetente SMTP. Interromper o executor do Action Scheduler também pode bloquear eventos de outras extensões usando esta biblioteca ^[9].

Documente verificações recorrentes em seu processo de gerenciamento manutenção e backups. Somente exclua o ambiente antigo após a reconciliação dos eventos diferidos e a confirmação do roteamento e da ausência de gravações residuais.

Log de comutação: decisões rastreáveis

O log a seguir fornece entradas concluídas para a loja fictícia. O piloto técnico detém as provas; o gerente da loja assina a decisão de abertura. As partes mostradas são validações esperadas, não resultados observados.

Insira para cada linha a hora real, o orador e a localização segura da evidência. Observe os identificadores úteis para reconciliação, nunca os dados do cartão.

Voltar sem excluir novas entradas

A reversão depende de gravações, não apenas da operação do servidor. Aplique esta árvore de decisão:

• Não há novas entradas no destino? Mantenha ambos os sites fechados, confirme esta ausência e restabeleça o antigo como autoridade antes de modificar o DNS e reativar seu processamento.
• Os pedidos, pagamentos, contas ou estoques foram alterados? Preservar o novo estado imediatamente. Priorize uma correção no novo servidor; um backup antigo apagaria essas alterações.
• A devolução da acomodação ainda é necessária? Congele o destino, salve seu estado completo e restaure esse estado recente no antigo servidor isolado. Revalide integrações e eventos pendentes antes de devolver autoridade a eles.
• Ambos os servidores escreveram? Congele todas as gravações em ambos os servidores de acordo com o procedimento acima e mantenha seus estados separadamente. Ter pedidos, pagamentos e ações logísticas reconciliados antes de qualquer recuperação; nenhuma mesclagem SQL improvisada garante sua consistência.

Um reembolso, e-mail ou remessa já acionado não é cancelado pela restauração. Reconcilie referências de provedores de serviços e registros logísticos para decidir quais eventos serão retomados. Se a ausência de novas entradas não for demonstrável, trate o caso como uma recuperação após entradas.

Perguntas frequentes

Um webhook chega no servidor antigo após a abertura: o que fazer?

Não tente reativar seu armazenamento para processar este evento sozinho. Verifique se o provedor planeja uma nova tentativa e se a notificação está na sua fila durável. Reconcilie a sua referência com o pagamento registado no novo site e aplique o mecanismo de recuperação testado. Sem provas suficientes, mantenha o caso em revisão manual.

Podemos manter a hospedagem antiga apenas para emails?

Sim, se as caixas e seus registros DNS permanecerem voluntariamente com este provedor de serviços. Em seguida, separe a manutenção de mensagens daquela de WordPress: a aplicação antiga, suas tarefas e seu envio automático devem permanecer neutralizados. Verifique as dependências do contrato antes da rescisão e teste o recebimento, envio e autenticação do serviço selecionado.

Uma cesta aberta antes da geada pode ser garantida?

Não apenas copiando os comandos. Um carrinho de compras pode depender de sessões, cookies ou armazenamento externo cuja retomada deve ser verificada. Avise os compradores sobre o congelamento e teste este caso no destino. Não confunda carrinho abandonado com pagamento comprometido: este último exige conciliação antes de pedir ao cliente para começar de novo.

Prepare a próxima troca

Comece concluindo o inventário de entrada e atribuindo as decisões do diário. Em seguida, programe o congelamento apenas quando a cópia isolada e a retomada das notificações estiverem habilitadas. Se ninguém puder confirmar a autoridade exclusiva ou preservar os pedidos que apareceram após a abertura, adie a troca. Para enquadrar esta preparação, você pode consultar o serviços web de 4SYSTEM.

Fontes

• Backups : Advanced Administration Handbook | Developer.WordPress.org (acessado em 2026-10-08)
• Migrating WordPress : Advanced Administration Handbook | Developer.WordPress.org (acessado em 2026-10-08)
• How Subscriptions Handles Staging Sites and Migrations Documentation - WooCommerce (acessado em 2026-10-08)