Tem acesso ao WordPress, mas conseguiria entregar a manutenção do site a outra empresa amanhã?
Antes de terminar o serviço atual, prepare uma passagem com três resultados: a nova equipa consegue intervir, o seu negócio mantém o controlo das contas e há uma data clara para a mudança de responsabilidade. Uma palavra-passe enviada por email não deve servir como prova de entrega.
A nossa recomendação é separar a receção do site das melhorias que pretende fazer. Primeiro, perceber o que existe e quem controla cada peça. Depois, corrigir o que impede uma manutenção segura. A renovação visual ou a mudança de alojamento podem ser decisões posteriores.
Comece por separar mudança de equipa e mudança de alojamento
Na proposta, trate a troca de prestador como uma passagem de responsabilidade. Não inclua automaticamente uma migração, um novo tema ou uma reconstrução do website.
O WordPress permite mudar uma instalação de servidor sem a reinstalar. Ainda assim, uma migração envolve ficheiros, base de dados e configuração própria; não é apenas entregar um utilizador à nova equipa. A documentação oficial distingue também uma mudança de servidor de uma alteração do domínio ou dos endereços das páginas. (developer.wordpress.org)
Para organizar a contratação, escolha um destes percursos:
- Passagem simples: manter o alojamento e os componentes atuais, transferindo acessos e responsabilidades.
- Passagem com regularização: resolver primeiro contas inacessíveis, licenças por esclarecer ou alterações sem documentação.
- Passagem com migração: incluir a mudança de infraestrutura, com testes e aprovação separados.
Não transforme o percurso mais completo na opção automática. Se a nova empresa propõe mudar tudo, peça que distinga o que é indispensável para assumir a manutenção do que é uma melhoria recomendada.
A ficha de entrega: quem controla cada peça?
Use a tabela seguinte como ficha de trabalho. Para cada linha, registe o responsável atual, o acesso recebido, quem o verificou e o que falta resolver. Não coloque palavras-passe nesta ficha; use o mecanismo seguro de partilha acordado entre as partes.
Esta é uma proposta de organização da passagem, não uma lista universal de contas obrigatórias. Elimine o que não se aplica e acrescente as dependências do seu negócio.
| Elemento | O que reunir | Critério de aceitação proposto |
|---|---|---|
| Domínio | Entidade gestora, titular identificado, contacto de recuperação e renovação | A empresa consegue confirmar quem controla a conta e como recuperar o acesso |
| DNS | Local onde são geridos os registos e responsável por alterações | A equipa sabe onde intervir e quais os serviços que não deve alterar |
| Alojamento | Prestador, conta, suporte, acessos técnicos e serviços incluídos | A nova equipa confirma que consegue trabalhar dentro do âmbito contratado |
| WordPress | Contas individuais e funções atribuídas | Os acessos necessários foram testados sem depender da conta pessoal de quem sai |
| Temas e plugins | Inventário, origem, licenças, renovações e suporte | Cada componente pago tem uma decisão: manter, contratar de novo ou substituir |
| Código personalizado | Ficheiros, repositório quando exista e notas de funcionamento | As alterações próprias estão localizadas e têm um responsável |
| Serviços externos | Ligações a reservas, pagamentos, envio de emails ou outros sistemas | As contas e os contactos de suporte estão identificados |
| Recuperação e incidentes | Local das cópias, procedimento existente e contactos de emergência | A nova equipa aceita expressamente o que passa a assegurar |
Não marque um elemento como entregue só porque recebeu um ficheiro. Marque-o quando a pessoa que vai utilizá-lo confirmar que a informação serve para trabalhar.
Se o domínio ou o alojamento estiverem numa conta partilhada do prestador anterior, registe essa dependência e combine uma solução antes de encerrar a relação. Não pressuponha que a entrega da conta inteira é possível ou necessária.
O diagnóstico inicial deve identificar o que está por esclarecer
A primeira avaliação deve produzir uma lista de factos, limitações e intervenções propostas. Evite aprovar um documento que diga apenas «site analisado» ou «manutenção iniciada».
O ecrã Saúde do site, no painel do WordPress, ajuda neste levantamento: apresenta verificações de configuração e informação sobre versões, temas, plugins, servidor e base de dados. Permite também copiar informação técnica para partilha. É um ponto de partida, não um certificado de que todas as funções do negócio estão operacionais. (wordpress.org)
Para a receção do site, proponha que o diagnóstico responda a estas perguntas:
- Que componentes e serviços são necessários para manter as funções atuais?
- Que alterações foram feitas à medida e onde estão documentadas?
- Que acessos ou informações continuam em falta?
- Que problemas já existiam antes da passagem?
- Que trabalhos ficam fora da mensalidade proposta?
A documentação de segurança do WordPress recomenda manter o sistema, os plugins e os temas atualizados, privilegiando componentes que continuem a receber atualizações. Por isso, o levantamento deve distinguir componentes mantidos de dependências cujo suporte precisa de ser esclarecido. (developer.wordpress.org)
Uma licença tem de ter destino, não apenas uma data
Para cada componente pago, registe quem o contratou, qual a conta associada, quando renova e que solução está prevista após a saída do prestador. Confirme as condições diretamente com o fornecedor do componente; não assuma que todas as licenças podem ser transferidas.
Exemplo hipotético: uma empresa de formação usa um calendário de sessões num WordPress mantido por outra agência. Antes da passagem, deve ficar escrito quem passa a assegurar a licença do calendário e quem conhece a ligação às inscrições. A decisão não é trocar o calendário por princípio. É não deixar essa dependência sem responsável.
Distribua os acessos antes de retirar os antigos
O WordPress utiliza funções e permissões para controlar o que cada utilizador pode fazer. Publicar conteúdos, gerir plugins e administrar utilizadores são capacidades distintas; não é necessário atribuir a mesma função a toda a gente. (wordpress.org)
Na passagem, proponha contas individuais para a nova equipa e reserve os acessos administrativos para quem realmente precisa deles. A orientação oficial de segurança recomenda palavras-passe fortes e limitar os privilégios ao necessário. (developer.wordpress.org)
Organize a troca por esta ordem:
1. Identificar as pessoas autorizadas a aprovar alterações pela empresa.
2. Criar e testar os acessos da nova equipa.
3. Confirmar os mecanismos de recuperação das contas relevantes.
4. Acordar a data e a hora em que termina a intervenção do prestador anterior.
5. Retirar os acessos antigos e rever os segredos partilhados, coordenando as mudanças com os serviços que os utilizam.
Não confunda retirar acesso com apagar utilizadores sem análise. Ao eliminar um utilizador, o WordPress permite decidir o destino dos conteúdos que lhe estão associados. Essa escolha deve ser revista antes da eliminação. (wordpress.org)
Para o decisor, o resultado a aprovar é simples: uma relação de acessos mantidos, criados e removidos, com as exceções justificadas. Não precisa de receber uma pasta cheia de credenciais para ter controlo sobre o processo.
Valide as funções que justificam manter o site
Antes de começar a alterar componentes, acorde uma pequena lista de funções essenciais e registe o estado em que foram recebidas. Esta será a referência para distinguir defeitos anteriores de problemas surgidos durante a transição.
No exemplo hipotético da empresa de formação, a lista poderia incluir:
- Encontrar uma sessão disponível através do calendário.
- Abrir a página com programa, local e horário.
- Aceder à área reservada com uma conta de teste.
- Descarregar o documento previsto para essa conta.
- Alterar uma data no painel e confirmar a informação apresentada ao visitante.
Escolha testes ligados ao uso real do site, não apenas uma visita à página inicial. Para cada teste, registe o resultado esperado, o resultado observado e quem o validou.
Se houver uma loja WooCommerce, prepare os testes com cuidados adicionais. A documentação oficial alerta que encomendas de teste podem gerar emails, entrar nas estatísticas e ser tratadas por integrações como encomendas reais. Recomenda testar pagamentos num ambiente separado e rever o comportamento de cada integração. (woocommerce.com)
Não use a passagem de manutenção como autorização implícita para experimentar em produção. O plano deve indicar onde são feitos os testes e quais precisam de aprovação do negócio.
Contrate a receção do site separadamente da rotina
Uma proposta clara deve permitir perceber o custo e a entrega de cada fase, mesmo que o prestador apresente um preço conjunto.
Receção inicial: proponha incluir o levantamento, a verificação de acessos, o registo de dependências e a lista de problemas encontrados. O resultado deve ser um documento utilizável por ambas as partes.
Regularização: coloque aqui as intervenções identificadas durante a receção e que precisam de aprovação própria. Para cada uma, peça motivo, âmbito, dependências e critério de conclusão. Evite uma autorização aberta para «corrigir tudo o que for necessário».
Manutenção recorrente: faça começar esta fase numa data expressa, com os serviços aceites e as exclusões registadas. Uma pendência pode continuar em aberto, desde que fique claro quem a resolve e quem responde se afetar o site entretanto.
Para avaliar a proposta, use quatro perguntas:
- O que recebo no fim da receção inicial?
- Que descoberta pode alterar o orçamento e como será aprovada?
- A partir de quando existe responsabilidade operacional da nova equipa?
- O que será entregue se um dia voltar a mudar de prestador?
Não compare apenas mensalidades. Compare também o trabalho necessário para chegar a uma situação que a nova equipa consiga manter.
Quando pode encerrar o serviço anterior?
A nossa recomendação é encerrar a passagem com uma aceitação escrita, curta e objetiva. Deve identificar a data de transferência, os acessos validados, os testes concluídos e as pendências aceites.
Use esta regra de decisão:
- Avançar: os acessos necessários estão confirmados, as funções acordadas foram verificadas e existe um responsável por cada pendência.
- Avançar com reservas: há limitações conhecidas, mas a empresa e a nova equipa aceitam por escrito as consequências e o plano de resolução.
- Adiar o encerramento: a nova equipa ainda não consegue intervir nos elementos abrangidos pelo serviço ou não está claro quem responde a uma falha durante a passagem.
Não aceite a mensalidade como prova de que a transferência terminou. Antes de mudar de empresa de manutenção WordPress, reúna a ficha de entrega e peça uma proposta de receção do site existente. Isso permite contratar sobre uma situação conhecida — e deixar de depender de informações que só a equipa anterior possui.