Lista de verificação de migração WordPress: mover arquivos, dados e domínios com segurança

Defina o que está em movimento e quem controla o cutover

Uma migração WordPress move uma aplicação existente e seus dados. Decida se você está mudando apenas o servidor de hospedagem, ou também o domínio, caminho URL ou esquema HTTPS. Anote as configurações atuais do WordPress e do Endereço do Site, conexão ao banco de dados, local de upload e qualquer roteamento personalizado. Um movimento de servidor e uma alteração de domínio requerem verificações diferentes.

Atribua uma pessoa para aprovar a cópia final e alteração DNS. Confirme que você pode acessar os arquivos antigos, exportar o banco de dados, configurar o destino e editar os registros DNS relevantes. Grave os registros existentes antes de alterá-los. A escolha de um plano de hospedagem não transfere o seu site; organiza a migração com a pessoa responsável pela sua aplicação.

Criar um backup de arquivos e bases de dados

Salve os arquivos WordPress e uma exportação de banco de dados como um conjunto de backup identificável. Incluir uploads, temas, plugins e a configuração necessária para reconectar o aplicativo. O download do diretório WordPress sozinho não captura um banco de dados armazenado em MySQL ou MariaDB. Grave quando a exportação foi tirada e mantenha uma cópia longe do servidor sendo substituído.

Verifique a versão PHP de destino, extensões necessárias, compatibilidade de banco de dados e espaço para o aplicativo restaurado e arquivos temporários. Confirme que seu backup pode ser aberto e restaurado em um banco de dados separado. Trate credenciais em arquivos de configuração como segredos e remova arquivos de exportação temporária de diretórios acessíveis ao público quando seu propósito estiver completo.

Planeje e teste uma restauração completa de hospedagem

Separar um movimento de hospedagem de uma alteração de URL

Quando o domínio público e os caminhos permanecem os mesmos, os URLs de aplicativos existentes geralmente permanecem válidos. Atualize a conexão do banco de dados de destino se seu host, nome do banco de dados ou credenciais diferirem. Teste usando um método que preserva o nome de máquina pretendido, como um sobreposição de arquivos de hosts locais, onde seu operador o suporta; isso muda apenas o dispositivo de teste, não o público DNS.

Role a tabela horizontalmente, se necessário.

Lidar com URLs alteradas sem quebrar dados serializados

Temas e plugins podem armazenar valores estruturados contendo tanto o texto quanto seu comprimento. Uma simples substituição de texto SQL pode danificar os dados serializados quando uma URL antiga e nova URL têm comprimentos diferentes. Use uma ferramenta de migração consciente de WordPress ou WP-CLI search-place se WP-CLI estiver disponível, e reveja seu escopo antes de aplicar uma alteração.

Em uma cópia restaurada, execute uma execução em seco primeiro, inspecione as tabelas relatadas e preserve uma exportação de rollback. WP-CLI fornece --dry-run e --skip-columns=guid; WordPress post GUIDs identificar conteúdo e não deve ser reescrito como links comuns. Um comando Multisite precisa de escopo de rede deliberado. Verifique as tabelas e configurações de plugins separadamente em vez de substituir cada string correspondente em cada banco de dados.

Teste o destino sem desencadear efeitos secundários vivos

Abra a página inicial, um post, pesquisa, mídia, login e a área de administração no destino. Verifique permalinks, ativos em falta, redirecionamentos HTTPS e erros de aplicação. Formas de teste e fluxos de armazenamento utilizando um ambiente de teste adequado. Mantenha uma cópia isolada do envio de mensagens de clientes reais, cobrança de pagamentos ou disparo webhooks produção durante o ensaio.

Para WooCommerce, verifique variações de produto, atualizações de cesta, o comportamento de checkout e a tela de administração de pedidos. Uma carga de página bem sucedida é apenas um teste. Compare o destino com uma lista curta de funções de negócios que você usa e resolva diferenças antes da cópia final. Grave qualquer configuração de aplicação alterada para testes para que possa ser revisada antes do lançamento.

Revisão WooCommerce hospedagem e configuração de loja

Proteger ordens e outras escritas durante o corte DNS

Uma loja pode receber novos pedidos após o ensaio de backup. Planeje uma pausa controlada em escrita ou uma sincronização final específica para aplicação, e então crie a cópia final consistente. Compare os últimos registros de pedidos e eventos de pagamento-fornecedor com o ponto de corte aprovado. Restabelecer um banco de dados mais antigo sobre os dados da loja ao vivo pode descartar transações que aconteceram depois.

Os caches DNS podem enviar visitantes para diferentes destinos durante a transição. Decida qual aplicação é autoritária para pedidos e como as escritas tardias serão tratadas antes de mudar de registros. Mantenha o ambiente anterior disponível para investigação sem reabrir casualmente duas lojas de escrita. O guia DNS cobre as alterações de registro; a decisão de migração também precisa de um proprietário claro para os dados da aplicação.

Verifique registros DNS antes de conectar o destino

Verificar o lançamento e definir um rollback utilizável

Repita as verificações funcionais através do público DNS, inspecione erros de aplicação e reveja novas ordens ou submissões sobre o destino pretendido. Se URLs mudaram, teste endereços antigos importantes e seus redirecionamentos. Verifique as configurações de indexação, URLs canônicas e o mapa do site para que uma restrição de estadiamento ou nome de host temporário não seja levado para a produção.

Definir as condições que justificariam o retrocesso. Para uma loja ao vivo, reverter DNS sozinho não move ordens recém-criadas de volta para o banco de dados antigo. Reconcile novos dados antes de retornar o tráfego e mantenha um registro da decisão final de migração. Aposentar a antiga instalação apenas após o destino, cópia de recuperação e registros de negócios foram verificados.

• O conjunto de backup final e o banco de dados de destino correspondem ao cutover aprovado.
• URLs públicas, HTTPS, formulários e funções de armazenamento funcionam no destino.
• As novas encomendas e os pedidos são registados no pedido previsto.
• Arquivos temporários e configurações somente de teste foram revisados.

Compare os planos de destino do WordPress