Changing WordPress Developers in the UK: A Website Handover Checklist
A preparation guide for UK businesses transferring an existing WordPress site to a new developer without leaving accounts, licences or operational tasks unclear.
In this article
Illustrative workspace. Screens show concepts, not a delivered client system.
A website handover can happen when an agency relationship ends, a developer moves on or your business needs a different support arrangement. Before approving changes, the new team needs to understand the current site and the accounts it depends on. Changing the person who maintains WordPress does not automatically require moving hosting or redesigning the website.
I provide WordPress maintenance and takeover assessments remotely from India for UK businesses and agency partners. This guide helps prepare the existing implementation for review, with ownership and operational responsibilities made explicit.
Separate account ownership from day-to-day access
List the domain, hosting, WordPress administration, email delivery, licences and connected services. Record who owns each account and who has been managing it. The business should be able to identify the authorised owner even when an agency performs the ordinary work.
Ask the outgoing team for an inventory and the agreed handover material. Arrange access through the responsible account holders. A developer should not treat an unknown login or permission gap as a reason to make unreviewed changes to production.
- System and business purpose.
- Authorised owner and administrative contact.
- Access needed by the incoming team.
- Renewal, recovery and ongoing responsibility.
Document the features that are easy to miss
Walk through more than the public pages. Include forms, scheduled tasks, redirects, search, product behaviour and custom administrative screens. A small plugin or external job can support an important function while leaving little visible evidence on the homepage.
| Dependency | Handover material to request |
|---|---|
| Custom plugin or theme feature | Source, purpose and relevant configuration |
| Enquiry form | Saved-record, notification and destination behaviour |
| Paid integration | Account owner, licence and required operation |
| Scheduled task | Trigger, expected result and exception handling |
| Redirect or URL rule | Current mapping and reason it exists |
Keep the description practical. The incoming developer needs to reproduce the behaviour and understand its owner, rather than receive an unexplained folder of code.
Check the recovery material before the first change
The official WordPress backup guidance explains that a typical restore needs both files and the database. Confirm what is backed up, when the copies were created and who can carry out recovery. A download labelled “website backup” should be assessed rather than accepted on its filename.
WordPress’s Tools Export documentation describes a content export. That is useful for its intended purpose, but it is different from a full recovery set that includes the site’s files and configuration. Ask the handover to distinguish those materials.
If orders, enquiries or member activity continue during the transition, record how newer data is protected when recovery or migration is considered.
Agree whether hosting or the platform should change
Take over the existing site first where that is practical, then assess whether a move or rebuild is needed. Hosting, design and support are separate decisions. Combining them into one unexamined transition can make it harder to identify the cause of a new problem.
If a hosting move is part of the scope, identify the domain, database, files, email-related dependencies and the release owner. Agree a representative test and a recovery method. If the design is changing as well, record which parts are approved and what the editors need to retain.
Use the WordPress redesign checklist for a separate design discussion. It should not be used to assume every developer handover requires a new website.
Make the first review a baseline, not an update spree
The incoming developer should record the current implementation and test the business journeys before making broad changes. Existing versions, custom work and integration behaviour can affect what is safe to update. A baseline gives the team a point of comparison.
- Important pages, forms and account journeys are recorded.
- Known failures and business impact are identified.
- Custom code and paid dependencies have named owners.
- Staging, release and recovery arrangements are agreed.
- Changes and review outcomes are kept in a project record.
Prioritise urgent failures separately from routine care. A compatibility investigation and a monthly update task can require different access, time and acceptance checks.
Define the new support arrangement
Agree the tasks included, the request route, review cadence and ownership of production releases. If an email provider, host or separate application supplier controls a dependency, identify how issues are handed to that party. Avoid a support promise that assumes one developer controls every system.
Do we need to change every password immediately? Review access with the authorised account owners and use the relevant service’s process. Credential changes are an account-management task, not a substitute for a dependency inventory.
Will all paid plugins transfer automatically? Check the actual licence owner and terms through the responsible account. Include required replacements or renewals in the proposal.
Can we start with an assessment? Yes. An inherited site review can identify what ongoing support or repair scope is realistic before a wider commitment.
Request a takeover assessment with an account inventory
Share the public website, reason for the handover, known issues and the systems you own or can authorise. Include the outgoing team’s feature list and the recovery material available. Send a high-level inventory first; arrange credentials and private records through the approved project setup.
I can review that information and scope a WordPress takeover assessment or ongoing care arrangement for your UK business. Discuss your website handover to define the first checks and the responsibilities that need to transfer.
Written by
Jagjeet Singh
Full stack development, WordPress engineering and practical web products. I work with businesses, teams and agencies in India and worldwide.
Explore my work
