Migrando sites com all-in-one WP migration sem

O plugin All-in-One WP Migration acelera migrações, mas quando usado sem preparação técnica de infraestrutura pode gerar erros de upload, timeouts, links quebrados, mídias invisíveis e loops de login. Este é o procedimento operacional que utilizo para migrar ambientes WordPress com total previsibilidade.

1. Pré-requisitos e verificação de compatibilidade#

Antes de gerar ou importar pacotes de migração, é vital auditar se o ambiente de origem e o de destino são compatíveis para evitar conflitos de banco de dados e bugs de execução PHP.

Verificar versões do WordPress core e banco de dados#

A origem e o destino devem estar preferencialmente na mesma versão do WordPress major:

# Consultar a versão atual do WordPress no destino
wp core version

# Consultar a versão no diretório de origem (se acessível no mesmo servidor)
wp core version --path=/var/www/origem

# Verificar a versão da estrutura do banco de dados registrada
wp option get db_version

# Verificar se há atualizações pendentes
wp core check-update

2. Protocolo de backup mandatório pré-import#

Nunca inicie um processo de importação de arquivo .wpress no WordPress de destino sem antes criar pontos de restauração física e lógica locais. O processo de importação sobrescreve completamente o banco de dados e arquivos existentes.

1. Backup lógico (SQL) e de arquivos do destino#

# Exportar banco de dados atual do destino antes da importação
wp db export /root/destino-pre-import-$(date +%Y%m%d).sql

# Backup completo compactado dos arquivos do WordPress do destino
tar czf /root/wp-backup-$(date +%Y%m%d).tar.gz /var/www/html/

2. Snapshots do hipervisor (se em máquina virtual)#

Se o servidor for hospedado em uma estrutura de virtualização dedicada:

# Exemplo Proxmox VE (por CLI)
vmsnapshot 100 "Pre-migration-$(date +%Y%m%d)"

# Exemplo VMware ESXi (por CLI vmsvc)
vmware-vim-cmd vmsvc/snapshot.create 100 "Pre-migration" "Snapshot antes do import"

3. O motor de importação e limites do PHP#

Se o arquivo .wpress exportado da origem for maior do que os limites de upload configurados por padrão no servidor, configure o arquivo php.ini ou .user.ini do destino:

upload_max_filesize = 2048M
post_max_size = 2048M
max_execution_time = 600
max_input_time = 600
memory_limit = 512M

Após editar estes valores no servidor, recarregue o serviço do PHP-FPM (systemctl reload php-fpm ou similar) para que as diretivas entrem em vigor.

4. Verificação de URLs e permalinks pós-migração#

A migração de dados acarreta na importação de URLs e caminhos da estrutura de arquivos da antiga origem. Se o domínio do site mudou, ou se as referências de uploads eram diferentes, é mandatório rodar o wp search-replace via WP-CLI para atualizar todas as referências no banco de dados.

1. Verificar as URLs definidas atualmente#

# Consultar URLs base nas configurações do WordPress
wp option get siteurl
wp option get home

# Verificar as configurações lendo diretamente a tabela do banco
wp db query "SELECT option_value FROM wp_options WHERE option_name IN ('siteurl', 'home')"

2. Localizar referências ao domínio antigo#

Descubra se ainda existem links para a URL antiga salvos no conteúdo de posts:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%url-antiga.com%'"

3. Executar o search-replace seguro#

Sempre execute com a flag --dry-run primeiro para verificar a quantidade de alterações que seriam aplicadas:

# Simulação segura (sem gravar no banco de dados)
wp search-replace 'https://url-antiga.com' 'https://url-nova.com' --all-tables --dry-run

# Executar a alteração real em todas as tabelas
wp search-replace 'https://url-antiga.com' 'https://url-nova.com' --all-tables

Após atualizar as URLs, é mandatório regenerar a estrutura de links permanentes (Permalinks) para reconstruir o arquivo .htaccess ou regras do Nginx:

# Atualizar a estrutura de permalinks via CLI
wp rewrite flush --hard

5. Auditoria de permissões de arquivos e diretórios#

Após a importação e descompactação feita pelo plugin, o ownership dos arquivos e as permissões de acesso podem sofrer alterações drásticas. Restabeleça as diretivas seguras de permissão (hardening):

1. Auditoria e validação das permissões atuais#

# Verificar permissões gerais no diretório base do WordPress
find /var/www/html/ -maxdepth 1 -exec stat -c "%a %U:%G %n" {} \;

# Verificar especificamente as permissões e donos do wp-config.php (segurança crítica)
stat -c "%a %U:%G %n" /var/www/html/wp-config.php

# Verificar permissões no diretório de uploads
find /var/www/html/wp-content/uploads -type d -exec stat -c "%a %n" {} \; | head -10

2. Aplicar hardening e permissões seguras#

Diretórios devem ter permissão 755, arquivos normais 644, o arquivo de credenciais wp-config.php deve ser restrito a 600 ou 640, e o dono do diretório deve ser o usuário do servidor web (ex: www-data ou nginx):

# Definir proprietário do diretório de forma recursiva
chown -R www-data:www-data /var/www/html/

# Ajustar permissões para diretórios
find /var/www/html/ -type d -exec chmod 755 {} \;

# Ajustar permissões para arquivos
find /var/www/html/ -type f -exec chmod 644 {} \;

# Proteger o arquivo de configuração
chmod 600 /var/www/html/wp-config.php

6. Configuração e validação de SSL/TLS pós-migração#

A migração muitas vezes aponta o site para HTTPS sem garantir que o novo servidor tenha um certificado SSL/TLS ativo e encadeado de forma íntegra.

1. Auditar certificado SSL via CLI#

Valide o certificado ativo do novo domínio consultando o servidor web de destino:

# Testar a resposta de cabeçalhos HTTPS do site
curl -I https://dominio.com/

# Inspecionar detalhes e validade das datas do certificado SSL
echo | openssl s_client -connect dominio.com:443 2>/dev/null | openssl x509 -noout -subject -dates

# Verificar a quantidade de certificados na cadeia (verificar integridade da chain)
echo | openssl s_client -connect dominio.com:443 -showcerts 2>/dev/null | grep -c "BEGIN CERTIFICATE"

Valide a integridade do arquivo local gerado para o domínio no servidor:

openssl verify /etc/letsencrypt/live/dominio.com/fullchain.pem

2. Configurar novo certificado via let's encrypt#

Caso utilize Certbot nativo em servidor Apache ou Nginx:

# Emitir e aplicar o certificado SSL/TLS automaticamente no Nginx
certbot --nginx -d dominio.com -d www.dominio.com

7. Verificação de DNS e propagação#

Para garantir a virada do tráfego (cutover) sem quedas, verifique as configurações de TTL e propagação de DNS.

# Verificar o tempo de cache (TTL) atual nas zonas DNS do domínio
dig dominio.com | grep -A1 "ANSWER SECTION"

# Consultar se a propagação do IP do novo servidor já atingiu os resolvers públicos primários
for dns in 8.8.8.8 1.1.1.1; do
    echo "Servidor DNS $dns aponta para: $(dig @$dns +short dominio.com)"
done

# Confirmar se o IP final corresponde ao novo servidor
dig dominio.com +short

8. Verificação e limpeza de CDN e cache de borda#

Se o domínio estiver rodando sob serviços de CDN (como Cloudflare), limpe o cache para que o conteúdo dinâmico e estático seja puxado do novo host.

# Verificar se os cabeçalhos de borda da CDN (ex: cf-ray) já respondem a requisição
curl -I https://dominio.com/ | grep -i -E "cf-ray|server"

# Disparar a limpeza (purge) total do cache da Cloudflare via API
curl -X DELETE "https://api.cloudflare.com/client/v4/zones/<ZONE_ID>/purge_cache" \
  -H "X-Auth-Email: <EMAIL>" \
  -H "X-Auth-Key: <KEY>" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

9. Verificação de cron jobs e e-mails#

Muitas instalações WordPress param de enviar notificações e processar agendamentos após a migração porque as configurações internas de disparo foram corrompidas ou o wp-cron foi desabilitado.

1. Auditoria e execução de cron jobs#

Verifique se a fila de eventos programados do WordPress está em execução regular:

# Listar eventos de cron ativos no WordPress
wp cron event list

# Validar se o wp-cron do sistema do site foi desabilitado em wp-config.php
wp config get DISABLE_WP_CRON

# Forçar a execução de todos os eventos de cron pendentes para teste
wp cron event run --all

# Listar os crontabs do sistema operacional
crontab -l
crontab -l -u www-data

2. Validação da fila de e-mails e SMTP#

Valide se o servidor de destino consegue entregar e-mails e se as configurações de SMTP estão corretas:

# Consultar configurações ativas de SMTP
wp option get smtp_host
wp option get smtp_port

# Enviar e-mail de teste via WP-CLI para verificar o pipeline de envio
wp mail [email protected] "Teste de Servidor" "Este é um e-mail de teste pós-migração."

# Monitorar a fila de e-mails do sistema de e-mail local (Postfix/Exim)
tail -50 /var/log/mail.log

Checklist: migração com all-in-one WP migration#

Fase 1: Pré-migração (origem)#

[ ] Atualizar o WordPress Core, temas e plugins ativos.
[ ] Limpar caches do site e remover plugins inativos.
[ ] Gerar exportação do arquivo .wpress.
[ ] Reduzir o TTL do DNS para 300 segundos 24h antes do cutover.

Fase 2: Preparação do destino#

[ ] Instalar o WordPress limpo (mesma versão do Core).
[ ] Ajustar limites no php.ini (upload_max_filesize = 2048M, post_max_size = 2048M).
[ ] Gerar backup preventivo lógico (wp db export) e físico do destino limpo.
[ ] Executar snapshot da VM (Proxmox/VMware).

Fase 3: Importação e ajustes de banco#

[ ] Executar importação do arquivo .wpress.
[ ] Executar o wp search-replace para corrigir caminhos e domínios antigos.
[ ] Regenerar a estrutura de links permanentes com wp rewrite flush --hard.
[ ] Reestabelecer as permissões corretas (755 diretórios, 644 arquivos, 600 wp-config.php).
[ ] Configurar e validar o certificado SSL/TLS.

Fase 4: Cutover e homologação#

[ ] Validar logins em /wp-admin e checar mídias no painel.
[ ] Alterar apontamentos DNS para o IP do novo servidor.
[ ] Atualizar endereços de IP de origem no painel do Cloudflare (CDN) e fazer Purge total do cache.
[ ] Testar jobs de cron e disparos de e-mail SMTP.
[ ] Monitorar logs de erro do Apache/Nginx e PHP por 60 minutos.

Tabela comparativa de problemas e severidade#

Problema Mapeado	Severidade	Categoria	Descrição e Solução
Falta de backup pré-import no destino	Alta	Risco	A importação sobrescreve dados locais de forma irreversível sem backup.
Incompatibilidade de versão do WordPress	Média	Compatibilidade	Versões distantes do Core geram falhas de serialização de tabelas SQL no import.
Permissões inválidas em arquivos pós-import	Média	Segurança	Permissões frouxas ou ownership do `wp-config.php` expõem dados a outros usuários.
SSL/TLS mal configurado ou inválido	Média	Segurança	O site quebra com mensagens de "Conexão Não Segura" ou erros de Mixed Content.
Falhas na propagação e TTL do DNS	Média	Migração	Clientes acessam servidores diferentes de forma alternada devido ao cache de DNS alto.
Cache de CDN (Cloudflare) desatualizado	Baixa	Cache	Visitantes continuam vendo a versão estática hospedada no host antigo.
WP-Cron desativado ou travado	Média	Funcionalidade	Falha em posts agendados e disparo de rotinas automáticas de plugins.
Falha no SMTP e envio de e-mails	Baixa	Configuração	Formulários de contato e notificações de transações param de funcionar.
URLs antigas remanescentes no banco	Média	Integridade	Imagens com link quebrado e menus direcionando o usuário para o site antigo.

Rollback#

Sempre mantenha a infraestrutura antiga de origem ativa e intocada por no mínimo 72 horas pós-migração. Em caso de falha sistêmica insustentável no destino, reverta a zona de DNS para apontar para o IP de origem e restabeleça a operação original sem perda de dados.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Este post está licenciado sob CC BY-NC.

Migrando sites com all-in-one WP migration sem quebrar URL, mídia e login