A WordPress website handover is complete when the business can operate the site and knows who will fix a problem. A password and a link to the homepage are not enough.
Use a handover meeting to perform real tasks, collect the supporting records and resolve unclear responsibilities before the project closes.
Handover sign-off table
| Item | Owner | Evidence | Pass looks like | Unresolved item |
|---|---|---|---|---|
| Domain and hosting ownership | Business owner | Registrar and host account screenshots or emails | Accounts are in the business’s name with recovery going to an authorised person | |
| User accounts | Supplier and business | User list | Individual accounts; no shared admin password; the supplier’s access is removed or agreed | |
| Plugins, themes and licences | Business owner | Inventory with renewal dates and who pays | Every paid item has a named payer and a renewal date | |
| Backups and restore | Supplier | Backup location and a test restore | A test restore produced a usable site | |
| Editing training | Staff member | Short recording of the tasks they will do | The staff member completed a real edit unaided | |
| Forms and journeys | Supplier | Test enquiry from a phone | It reached the right inbox and the acknowledgement made sense | |
| Support boundary | Both | Written agreement | Who fixes what, hours and what needs a quote are written down |
Confirm ownership and access
List the domain registrar, hosting account, WordPress users, email delivery service and analytics accounts. Establish which are owned by the business and which are supplied under a service agreement.
Use individual accounts with appropriate access rather than distributing one shared administrator password. Check that account recovery reaches an authorised person.
Ask what access a departing supplier retains and how it will be removed when no longer needed. Store credentials in the business’s approved password manager, not in a public handover document.
Collect the operating information
Request an inventory of themes, plugins, paid licences and renewal dates. For each recurring cost, record who pays and what happens if it expires.
Collect approved copy, original images, usage permissions and design files that form part of the agreement. Ask for a short recording showing the editing tasks staff will actually perform.
For a hypothetical consultancy, this might mean changing a team biography, adding a case study and updating a service page. The demonstration should use the actual editing setup.
Demonstrate recovery and customer journeys
Ask the supplier to show where backups are held, what they include and how restoration is tested. A successful backup notification does not by itself show that someone can restore a usable site.
Submit a test enquiry from a phone. Confirm it reaches the correct inbox or system and that the acknowledgement makes sense. Test downloads, booking links and any payment journey in an appropriate test mode.
Review the questions website visitors need answered while checking navigation. Staff training should cover content clarity as well as button locations.
Agree the support boundary
Record who handles updates, uptime alerts, broken forms and content edits. Clarify support hours, reporting channels and which requests require a separate quote.
Keep a small unresolved-items list with an owner and due date for each item. Distinguish a launch defect from a new feature request so neither disappears into a vague support conversation.
DonutLabs’ WordPress development service can help with handover and maintenance planning. The useful test is whether another authorised person could pick up the records and understand how the website is run.
For the wider planning context, read What affects the cost of a small-business website redesign?.
