Transferir um cliente entre agências WordPress: o que verificar e como fazer a transição

Receber um novo cliente que vem de outra agência é, na maioria dos casos, receber um site WordPress cujo estado técnico real desconheces completamente. Pode estar em excelente estado — ou pode ter vulnerabilidades, backups inexistentes, plugins abandonados e credenciais partilhadas com a agência anterior. A transferência técnica bem feita protege-te e protege o cliente.

O que acontece frequentemente numa transição entre agências

O cenário mais comum: o cliente fica insatisfeito com a agência anterior por razões comerciais ou de comunicação, não por razões técnicas. O site "funciona", na perspectiva do cliente. A nova agência aceita o cliente, e os problemas técnicos aparecem semanas ou meses depois — atribuídos ao trabalho da nova agência.

Fazer uma auditoria técnica antes de aceitar a responsabilidade pelo site não é falta de confiança no cliente — é profissionalismo e protecção da tua própria reputação.

O que pedir antes de aceitar a transferência

Acessos completos

• Acesso de administrador ao WordPress (wp-admin)
• Acesso ao painel de alojamento (cPanel, Plesk, painel do hosting)
• Acesso FTP/SFTP ao servidor
• Acesso à base de dados (phpMyAdmin ou credenciais directas)
• Acesso ao registador do domínio (ou confirmação de quem é o titular do domínio)
• Acesso às ferramentas de analytics (Google Analytics, Search Console)

Atenção importante: se a agência anterior criou o domínio ou o alojamento em nome próprio (e não do cliente), há um problema de titularidade que precisa de ser resolvido antes da transição técnica. O domínio e o alojamento devem pertencer ao cliente — não à agência anterior.

Documentação existente

• Que serviços externos estão integrados (CRM, email marketing, gateways de pagamento)?
• Há personalizações de código (funções custom no functions.php, child theme, plugins custom)?
• Existem backups? Onde? Com que frequência?
• Há contratos activos com fornecedores de serviços?

Auditoria técnica de recepção: checklist

Estado do WordPress

• Versão do WordPress core (actualizada?)
• Versão do PHP do servidor (suportada? Recomendado 8.1+)
• Plugins instalados: quantos, quais, versões actualizadas?
• Plugins desactivados mas não removidos (potencial risco de segurança)
• Temas instalados mas não usados (mesmo risco)

Segurança

• Utilizadores WordPress: quantos admins? Há utilizadores da agência anterior com acesso admin que devem ser removidos?
• Certificado SSL válido e com quanto tempo até expirar?
• Ficheiro wp-config.php com chaves de segurança actualizadas?
• Scan de malware: site limpo?
• Há logs de tentativas de acesso ou actividade suspeita?

Backups e recuperação

• Existia sistema de backup? Funciona?
• Fazer backup completo imediatamente após transferência — ponto de partida limpo documentado

Performance

• Core Web Vitals via PageSpeed Insights
• Tempo de carregamento baseline (para comparar depois)
• Verificar se há cache configurado

Após a auditoria: definir a linha de partida

Documentar o estado técnico do site no momento de recepção é fundamental. Se o site tem vulnerabilidades ou problemas que já existiam antes de a tua agência assumir, esta documentação prova que não foram criados por ti.

Partilhar um relatório de estado inicial com o cliente (simplificado, sem jargão) cria transparência e estabelece expectativas correctas: "Este é o estado do site que recebemos. Estas são as melhorias que vamos implementar nas próximas semanas."

Alterar credenciais imediatamente após transferência

Após transferência, alterar:

• Password do wp-admin (todas as contas de administrador)
• Chaves secretas do wp-config.php (invalida sessões activas da agência anterior)
• Passwords de FTP/SFTP e base de dados
• Chaves de API que a agência anterior possa ter acesso

Remover utilizadores WordPress da agência anterior — mantê-los activos é um risco de segurança e de conflito de acesso desnecessário.

O que fazer se o site estiver em mau estado técnico

Se a auditoria revelar problemas graves (site hackeado, backups inexistentes, stack muito desactualizada), tens duas opções:

• Proposta de remediação antes de assumir manutenção: apresentar ao cliente o que precisa de ser corrigido, com custo e timeline. Só depois de aprovado e executado é que assumis a responsabilidade técnica.
• Assumir com estado documentado e plano de correcção: assumir o site no estado actual com documentação do estado inicial e plano de correcção progressivo incluído no contrato.

O que não fazer: assumir a responsabilidade pelo site sem documentar o estado inicial e sem um plano claro de remediação.