Key Takeaways
- Changing developers does not automatically require a new website or a hosting move. Separate the supplier decision from the technical changes.
- WordPress access is only one part of the handover. Check the domain, hosting, DNS, email services, source code, paid licences and recovery contacts.
- Test a backup before depending on it. A download marked complete is not evidence that the website can be restored.
- Give the new team individual accounts, document responsibilities and remove the old access after the agreed handover checks pass.
- Keep enquiries, orders and renewals under observation during the change. A site can look normal while an important connection has stopped working.
You can switch WordPress developers without losing control of your website, provided you organise the handover before ending the old arrangement. The useful starting point is an inventory of accounts and dependencies, not a request for “all the passwords”.
Perhaps your current developer is retiring. Perhaps your business needs support they no longer offer. Sometimes the relationship is simply no longer a good fit. Whatever the reason, the website still needs to receive enquiries, take payments and remain recoverable while responsibility changes.
Treat this as a small operational project. Name who is leaving, who is taking over, what each person must deliver and when the new team becomes responsible. Keep ownership or contractual disputes separate from the technical checklist and obtain appropriate advice where needed. A developer should not resolve a disagreement by making an unauthorised copy or cutting off another party's access.
Decide What Is Actually Changing
There are several different changes hidden inside the phrase “move the website”. You might change the developer while keeping the same host. You might transfer billing for an existing account. You might move hosting but leave the domain registration where it is. Or you might commission an entirely new website.
Write these decisions down separately. If the current website works and the immediate need is dependable support, a rebuild may add unnecessary cost and risk. A sensible WordPress development review should explain which parts can stay and which genuinely need work.
Avoid combining a supplier change, domain move, email migration, plugin overhaul and redesign into one untested afternoon. Each extra change creates another possible explanation if something breaks. Agree the smallest safe first step, then plan improvements after the handover is stable.
Make an Account Map, Not a Password Spreadsheet
List the systems that keep the website running. Record the account owner, the business contact who can recover it, the access the incoming team needs and any transfer action. Store credentials in a suitable password manager, not in the checklist itself.
| System | What to confirm | Evidence to keep |
|---|---|---|
| Domain registration | Business ownership, renewal contact and recovery route | Account access and renewal date |
| Hosting | Correct website, billing owner and backup controls | Successful individual login |
| DNS and CDN | Who can change records and security settings | Current configuration export |
| WordPress | Administrator access and existing users | Named account and role review |
| Code and deployment | Repository, build instructions and deployment owner | Read access and a tested build where relevant |
| Email and forms | Sender service, destination and failure alerts | A controlled delivery test |
| Paid tools | Licence holder, renewal terms and transfer limits | Supplier confirmation or licence record |
The recovery route matters as much as the current login. An account registered to a former employee's private email can become a problem months after an apparently successful handover. Test that an authorised person in the business can manage access without asking the old developer to act as the permanent middleman.
Check WordPress Permissions Properly
The incoming developer usually needs more than an editor account to maintain themes, plugins and configuration. However, they do not automatically need access to every other business system.
The official WordPress roles and capabilities guide explains that roles carry different permissions, and that single-site and multisite arrangements differ. Use that as the reference when checking what an account can actually do. Do not judge its permissions from a label alone if custom roles or security plugins are involved.
Create a named account for each person rather than sharing the owner's login. Confirm the agreed authentication method, recovery contact and access review date. Keep access narrow enough for the task, but sufficient for the new team to do the work you are paying them to do.
Do not remove the outgoing account immediately just because the new login works. First identify scheduled jobs, API connections or publishing processes that depend on it. Transfer those dependencies deliberately, then revoke access at the agreed point.
Prove That the Backup Can Be Restored
A useful handover includes the database and the files needed to rebuild the website. A WordPress content export is not the same thing as a complete site backup. Nor is a copy of the theme enough to recreate orders, settings, uploads or form records.
WordPress's backup documentation distinguishes the database and files as parts of recovery. Ask the new developer to restore the agreed backup into an isolated test environment and check representative pages, media and functions.
Protect that environment. Disable live payment actions and production email sending, use appropriate test data and prevent public access to sensitive information. A staging site must not accidentally contact customers while somebody tests an old order.
Record the backup time and explain what happened afterwards. On a busy shop, restoring yesterday's database can remove today's orders. The recovery plan therefore needs a decision about new transactions, not just a button labelled restore. Your team should know who can approve that decision and what evidence they must check first.
Ask for Source Code and Operating Instructions
If the site contains custom development, request the agreed source files and enough information to maintain them. That may include a Git repository, deployment configuration, dependency versions, build commands and a short explanation of unusual integrations.
Do not assume that everything visible on the live server is the full development source. Some websites deploy compiled assets while keeping their editable source elsewhere. Conversely, a repository may contain code but not the content database or media library.
Where a GitHub repository is being transferred, follow GitHub's repository transfer documentation and review the destination account's permissions and features. Transfer is an administrative action with conditions, not merely a file download.
The important acceptance test is practical: can the authorised incoming team reproduce the site or an agreed change using the supplied material? Ask them to identify missing information before the outgoing supplier closes the project. Documentation does not need to be elaborate, but it must explain the things a competent new developer could not reasonably infer.
Separate Licences from Ownership
Paid plugins, fonts, photographs and theme components may have their own licence arrangements. An agency-wide licence does not necessarily transfer to a client, and an expired support subscription does not always mean the same thing as an expired right to use a product.
Check the actual supplier terms rather than guessing. Record which products require a new business-owned subscription, which can remain under a documented support agreement and which are being replaced. Ask what will happen to updates, premium features and support when the outgoing contract ends.
This is a purchasing and continuity check, not a reason to replace every plugin. Keep functioning tools where their licensing and maintenance arrangements remain suitable. Our guide to website maintenance plans explains the wider support responsibilities to compare when choosing an ongoing arrangement.
Test the Work That Pays the Bills
Checking the homepage is not enough. Make a short list of important customer journeys and run them with controlled test details.
For a service business, submit the contact form, check that the correct inbox receives it and confirm that any CRM record is created as intended. For an online shop, use the payment provider's safe testing method and examine the order, notification and fulfilment handoff. For a booking business, check available slots, confirmation messages and cancellation handling.
Also test what happens when a submission fails. A friendly success message can hide a rejected email or integration error. The incoming developer should show where failures are recorded and who receives an alert.
If URLs or hosting are changing, use the website migration SEO checklist alongside this handover. Supplier access and search migration are related, but they are not the same job. Keeping the URL structure unchanged does not prove that a form still works, and a working form does not prove that redirects are correct.
Agree the Handover Window and Support Boundary
Write down when the old supplier stops making changes, when the new supplier may begin and who handles a problem during the overlap. A short change freeze can prevent two developers editing the same theme or restoring different backups.
Agree a list of open issues. Mark whether each is an existing fault, a handover blocker or an improvement for later. Otherwise, a long-standing problem can become an argument about who caused it.
Ask the incoming team to confirm what their website maintenance and support covers: updates, backups, monitoring, content edits, emergency response and third-party charges. A monthly fee without a clear responsibility boundary leaves both sides guessing.
Finally, set a review after the first normal trading cycle. Check that scheduled tasks ran, enquiries arrived, renewals are correctly assigned and no old account remains essential. Remove obsolete access and rotate relevant credentials through an agreed process, without disrupting integrations that still depend on them.
Use a Clear Go or No-Go Decision
Do not sign off because a folder has arrived. Sign off when the required access works, the backup has been tested, critical journeys pass and named people accept responsibility.
If a key account or licence remains uncertain, record the gap and decide whether to delay the transfer or use a documented temporary arrangement. That is better than pretending the handover is complete and discovering the dependency during an outage.
If you need help assessing what is missing, send us the handover scope, without sending passwords or private customer records. We can start with the system map and agree the access needed for a proper review. The aim is straightforward: your business should be able to choose its next developer without losing the ability to run its own website.
Frequently Asked Questions
Do I need to move hosting when I change WordPress developers?
Not necessarily. If the existing hosting is suitable and your business controls the account, the new developer may be able to maintain the site there. Decide on hosting separately, based on access, support, performance and the work required.
Is a WordPress administrator login enough for a handover?
Usually not. Maintenance may also require hosting, domain, DNS, source code, backup and integration access. Create an account map and give each person the permissions needed for their agreed responsibilities.
What should I do if the old agency holds a plugin licence?
Check the product's terms and ask what happens when the agency agreement ends. You may need your own subscription or a documented ongoing arrangement. Do not assume the licence transfers with the website.
When should the outgoing developer's access be removed?
Remove it at the agreed handover point after checking dependencies and confirming that the incoming team can operate the site. Review API keys, deployment accounts and scheduled tasks as well as WordPress users.
How can I tell whether the handover is complete?
Confirm that authorised business contacts control the required accounts, a backup has been restored safely, critical customer journeys pass and support responsibilities are documented. Missing dependencies should remain visible as open actions rather than being hidden in a general sign-off.
