Como migrar sites WordPress sem downtime para clientes de agência

Migrar um site WordPress de produção sem downtime é um dos processos mais exigentes que uma agência pode executar. A pressão é dupla: tecnicamente, há múltiplos pontos de falha possíveis; do ponto de vista do cliente, qualquer minuto de indisponibilidade é inaceitável. Com o processo certo, é possível fazer migrações complexas com zero downtime percebido — ou, na pior das hipóteses, com uma janela de manutenção de minutos em vez de horas.

O que significa "migração sem downtime" — realidade prática

Antes de entrar no processo, é importante estabelecer expectativas realistas. Existem duas abordagens distintas:

Zero downtime absoluto

Tecnicamente possível em infraestruturas com load balancing e capacidade de servir tráfego de dois servidores em simultâneo durante a migração. Para a maioria dos sites WordPress de clientes de agência, esta abordagem requer infraestrutura que o custo não justifica.

Downtime mínimo — a abordagem prática

O que é realista na esmagadora maioria das migrações: o site está completamente funcional no novo hosting antes de qualquer visitante ser redirecionado. A "mudança" acontece ao nível do DNS e dura entre 0 e alguns minutos (dependendo do TTL configurado). Para um visitante, pode não existir qualquer interrupção — especialmente se a migração for feita a uma hora de tráfego baixo.

A distinção crítica: o downtime não acontece durante a migração — acontece, potencialmente, durante a propagação de DNS. E mesmo esse pode ser eliminado com preparação adequada.

Preparação: o trabalho que determina o sucesso

80% do sucesso de uma migração sem downtime é determinado pela preparação. Apressar esta fase é a causa mais comum de problemas.

Inventário completo do site

Antes de mover um único ficheiro, documentar:

• Versão do WordPress, PHP, MySQL/MariaDB no hosting atual.
• Lista de todos os plugins ativos e versões.
• Tema ativo e temas instalados.
• Configurações especiais em .htaccess (redirects personalizados, regras de segurança, configurações de cache).
• Endereços de email configurados no domínio — serão afetados pela migração de DNS?
• Integrações externas que usam o domínio (webhooks, APIs, CDNs, serviços de email transacional).
• Tamanho total do site — ficheiros e base de dados.

Backup verificado antes de começar

Regra absoluta: nunca iniciar uma migração sem um backup completo e verificado do site de origem. Verificado significa testado — não apenas criado. Um backup corrupto descoberto a meio de uma migração falhada é um cenário a evitar a todo o custo. Ver práticas de backup em porque a maioria das agências não testa restores de backup.

Escolha da ferramenta de migração

Três abordagens principais, ordenadas da mais automatizada à mais manual:

• Duplicator Pro — cria um pacote completo do site (ficheiros + base de dados) e um instalador PHP que reconstrói o site no destino. Excelente para sites até ~5GB. A versão Pro lida melhor com sites grandes e tem funcionalidades de migração incremental.
• WP Migrate DB Pro — especializado na migração da base de dados com substituição automática de URLs (resolve o problema de URLs hardcoded em conteúdo serializado). Requer migração separada de ficheiros via FTP/rsync.
• Migração manual via SSH/rsync — máximo controlo, máxima fiabilidade para sites grandes. Usar rsync -avz --progress /source/ user@destino:/destino/ para sincronizar ficheiros, e mysqldump para exportar a base de dados. Mais lento, mas sem limitações de tamanho ou complexidade.

Preparar o novo hosting

Antes de migrar, o novo hosting deve estar completamente configurado:

• PHP na versão correta (ou superior, se compatível).
• Base de dados criada com utilizador e permissões corretas.
• Certificado SSL pré-instalado (muitos providers permitem instalar SSL antes de apontar o DNS).
• Limites de PHP adequados: memory_limit, max_execution_time, upload_max_filesize.

Processo de migração passo a passo

Passo 1: Reduzir o TTL do DNS com antecedência

Pelo menos 24-48 horas antes da migração, reduzir o TTL dos registos DNS do domínio para 300 segundos (5 minutos). Isto garante que, quando a mudança de DNS for feita, propague rapidamente em vez de levar horas. Este passo é frequentemente esquecido e é o que transforma uma "migração sem downtime" numa migração com horas de propagação.

Passo 2: Clonar o site para o novo hosting

Copiar todos os ficheiros e a base de dados para o novo servidor. Após a cópia, ajustar wp-config.php com as novas credenciais de base de dados:

define('DB_NAME', 'nova_base_de_dados');
define('DB_USER', 'novo_utilizador');
define('DB_PASSWORD', 'nova_password');
define('DB_HOST', 'localhost');

Se o URL do site vai manter-se igual (o caso normal), não é necessário alterar WP_HOME ou WP_SITEURL em wp-config.php. Se o URL vai mudar, usar WP-CLI ou uma ferramenta de search-replace na base de dados para atualizar todas as ocorrências do URL antigo.

Passo 3: Testar via ficheiro hosts ANTES de mudar DNS

Este passo é o que separa as migrações profissionais das amadoras. Editar o ficheiro hosts do computador para apontar o domínio para o IP do novo servidor, sem alterar o DNS público:

• Windows: C:\Windows\System32\drivers\etc\hosts
• Mac/Linux: /etc/hosts

Adicionar a linha: NOVO_IP_SERVIDOR dominio.pt www.dominio.pt

Com esta configuração, o computador da agência acede ao novo servidor enquanto todos os outros visitantes continuam a ver o servidor antigo. Testar exaustivamente:

• Homepage e páginas internas carregam corretamente.
• SSL funciona sem avisos.
• Login no wp-admin funciona.
• Formulários de contacto funcionam e enviam email.
• Se WooCommerce: testar todo o fluxo de checkout com um pedido de teste.
• Verificar que as imagens carregam todas (nenhuma com URL hardcoded para o servidor antigo).
• Verificar velocidade — o novo hosting deve ser pelo menos igual ao antigo.

Apenas após aprovação completa nesta fase se deve prosseguir para a mudança de DNS.

A mudança de DNS — o momento crítico

Timing

Escolher o momento de menor tráfego — tipicamente madrugada de terça para quarta-feira, ou o horário com menos atividade visível no Google Analytics. Para sites de e-commerce, evitar sextas-feiras e fins de semana.

Sincronizar a base de dados antes de fazer o switch

Entre o momento em que o site foi copiado e o momento da mudança de DNS, o site de produção continuou a receber conteúdo novo (encomendas, comentários, novos posts). Fazer um último dump da base de dados do servidor antigo e importar no novo servidor imediatamente antes de mudar o DNS, para minimizar a perda de dados durante a transição.

Alterar os registos DNS

Atualizar o registo A (e AAAA se aplicável) do domínio para o IP do novo servidor. Com TTL de 300 segundos configurado com antecedência, a propagação completa em poucos minutos na maioria dos resolvers.

O que fazer se algo falha após a mudança

Ter o IP do servidor antigo registado. Se for necessário reverter, basta apontar o DNS de volta para o IP antigo. Com TTL de 300 segundos, o rollback é quase tão rápido quanto a mudança. O suporte urgente da Vuvo está disponível exatamente para estes momentos de stress em migrações críticas.

Checklist de verificação pós-migração

Após a propagação de DNS estar completa (verificar com dig dominio.pt ou uma ferramenta de DNS lookup para confirmar que o IP correto está a ser devolvido), percorrer esta lista:

1. SSL ativo e sem avisos — verificar o cadeado no browser e que não há conteúdo misto (mixed content).
2. Emails do domínio a funcionar — enviar um email de teste para e a partir de um endereço do domínio. A migração de DNS pode afetar registos MX se não tiverem sido preservados corretamente.
3. Formulários de contacto a enviar — testar todos os formulários do site.
4. E-commerce funcional — se aplicável, completar um pedido de teste do início ao fim, incluindo confirmação de email.
5. Caches limpos — limpar cache do plugin de cache WordPress, cache do servidor (Varnish, OPcache, Redis), e se existe CDN, purgar o CDN.
6. Redirects a funcionar — verificar os redirects mais importantes do site (especialmente 301s de SEO críticos).
7. Search Console atualizado — verificar se a propriedade do Google Search Console continua verificada. Se o método de verificação era via ficheiro no servidor, confirmar que o ficheiro foi migrado.
8. Google Analytics / tracking a funcionar — verificar em tempo real que está a registar sessões.
9. Backups configurados no novo hosting — o site está no novo servidor mas os backups do servidor antigo não seguem automaticamente. Configurar backups no novo ambiente antes de tudo o resto.
10. Monitorização a apontar para o novo servidor — atualizar qualquer ferramenta de monitorização de uptime para confirmar que está a verificar o novo endpoint e que os alertas estão ativos.