The worst handovers are not dramatic. The site works, the client is happy, and everyone moves on. Then, eight months later, the domain is about to expire and nobody knows whose card it renews on. Or a new developer asks for the SFTP details and the only person who had them has left the agency. Or a premium plugin stops updating because its licence was on the agency’s account all along.
A handoff is the moment when responsibility for a site moves from one party to another. It may move from your agency to the client, from your agency to a maintenance partner, or from one partner to another. In every case the same thing goes wrong when it is rushed: knowledge that lived in someone’s head never makes it onto paper. This checklist is built to stop that.
First, be clear who is receiving the site
The content of a handoff depends on who is on the other end.
- Handing to the client means they become responsible for the site, or for choosing who looks after it. They need ownership, access and plain-language guidance. They do not need your build notes.
- Handing to a technical partner who will maintain or extend the site means they need the technical detail: how it was built, what was customised, what is fragile. They may never speak to the client.
- Handing to the client and a partner at once is common when the client takes ownership but you arrange for someone to maintain it. Split the pack in two so each side gets what is useful to them.
Decide this before you start gathering. It saves you writing a thirty-page document the client will never open.
The checklist
1. Ownership of accounts
This is the section that causes the most trouble years later, so start here.
- Domain registrar: whose account holds the domain, the renewal date, and whether auto-renew is on.
- Hosting: whose account, which plan, who is billed, and the renewal date.
- DNS: where it is managed. This is not always the registrar or the host.
- Email: where the client’s mailboxes are hosted, and whether they depend on DNS records that someone might change by mistake.
- Third-party services: analytics, tag manager, search console, form services, payment gateways, newsletter tools, maps API keys. Note who owns each one.
If any of these sit in your agency’s accounts, decide now whether they move to the client or stay with you under a written arrangement. Our post on agency-held versus client-held hosting and domains sets out the trade-offs.
2. Access
- A WordPress administrator account in the recipient’s own name, not a shared login.
- Hosting control panel access, or instructions for the client to grant it.
- SFTP or SSH details, if the recipient will need them.
- Database access route, usually through the hosting panel.
- A list of every user account on the site, with a note on which ones should be removed once the handoff is complete.
Send credentials through a password manager’s sharing feature or another secure route, never in the same email as the rest of the pack. More on that in our guide to handling client credentials.
3. Licences and paid components
- Every premium plugin and theme, the account its licence is registered to, and its renewal date.
- Whether each licence transfers to the client, stays with you, or needs a new licence bought in the client’s name.
- Any paid fonts, stock images or icon sets, and the licence terms that apply to the client’s use.
This item gets missed constantly, because licences are invisible while they work. A site whose licences lapse keeps running, but stops getting updates, and that is how sites quietly fall behind on security fixes.
4. Code and customisations
For a technical recipient, this is the heart of the pack.
- The theme in use, and whether it is a parent theme with a child theme, a custom theme, or a page builder theme.
- Where custom code lives: a child theme, a custom plugin, a code snippets plugin, or (please, no) the parent theme’s files.
- The repository, if there is one, and who has access.
- Any custom post types, fields or templates, and what they are for.
- Anything deliberately left out of updates, and why. If a plugin is pinned to an older version because a newer one breaks a layout, say so, with the detail.
- Known issues and workarounds. Be honest. The recipient will find them anyway, and it is better they hear it from you.
5. Backups
- Where backups are stored, how often they run, how long they are kept, and who can reach them.
- When a restore was last tested.
- A fresh full backup taken on handoff day, stored somewhere the recipient can reach.
If you have never tested a restore for this site, do it before handoff, ideally on a staging copy. A backup that has never been restored is a hope rather than a plan. The basics are covered in our walkthrough of backing up WordPress.
6. Content and training
For a client recipient:
- A short guide to the tasks they will actually do: editing a page, adding a blog post, changing an image, updating opening hours.
- A note on what not to touch: theme settings, plugin settings, anything that could break layouts.
- A recorded walkthrough, if you offer one. A screen recording of you editing their own site is more useful than any written manual.
7. Support terms after the handoff
- How long you will fix launch-related bugs, and what counts as one.
- What happens after that: an optional care plan, ad-hoc paid support, or nothing.
- Who the client should contact, and how.
If the client has not chosen ongoing care, say clearly in writing that the site is now their responsibility. It is not a pleasant sentence to write, but it protects both sides.
A handoff email for the client
Here is a starting point you can adapt. Keep it short; the detail belongs in the attached pack.
“Hi [name], your site is now fully handed over. Attached is a short document with everything you need: where your domain and hosting are, who owns what, and how to make everyday edits. Login details will follow separately through [secure method], not by email.
A few things to note: your domain renews on [date] and your hosting on [date]. Two plugins use paid licences, and these renew on [dates]. We took a full backup today and stored a copy at [location].
We will fix any launch-related issues reported before [date]. After that, [ongoing arrangement]. If you have questions about any of this, reply here and I’ll help.”
A handoff note for a technical partner
For a partner, structure matters more than tone. A one-page summary on top, with the detail underneath, works well:
- Site: URL, staging URL if any, hosting provider.
- Stack: theme, page builder if used, key plugins and why each is there.
- Custom code: where it lives and what it does.
- Fragile areas: anything that breaks easily, and how you have handled it before.
- Update notes: plugins held back and why.
- Client context: what the client cares about most, such as the booking form or the shop, and anything sensitive about the relationship that affects how work should be done.
Keep this note alive after the handoff rather than writing it once. A living document per site is one of the best habits an agency can have; see keeping a runbook for every client site.
Common gaps worth checking twice
- Admin email address in WordPress settings still set to a developer who has left.
- Form notifications sending to a test inbox.
- Search engine visibility setting left on “discourage” from the staging period.
- Staging site left publicly accessible and indexable.
- SMTP or transactional email configured with your agency’s credentials.
- Uptime monitoring alerts still going to your team when the client has taken over.
- Old user accounts from the build still active.
Each one is a five-minute fix on handoff day and a confusing support request months later.
Start gathering on the first day of the build
Most of this information is easy to collect while the project is running and hard to reconstruct afterwards. The registrar login is fresh when the client first shares it. The reason a plugin was chosen is obvious the week it is installed and forgotten by launch.
So open the handoff document at kickoff and add to it as you go. Each time someone creates an account, buys a licence or writes a piece of custom code, they add one line. By launch week, the pack is mostly written, and the handoff becomes an hour of tidying rather than a day of detective work. It also means that if someone on your team leaves mid-project, the knowledge does not leave with them.
Close the loop
A handoff is finished when the recipient confirms they have what they need, not when you send the email. Ask them to log in, check one or two items, and reply. If something is missing, you find out while the project is still fresh in everyone’s memory.
If the site is moving to a maintenance arrangement rather than to the client alone, this checklist is the same one a good partner will ask you for. The overview of how agencies outsource WordPress work explains where that fits. And if you would like the receiving end handled for you, with care delivered in your agency’s name after the handoff, our page on behind-the-scenes maintenance for agency sites describes what we take on.
Next in this series: How Agencies Can Share Client Logins Safely
