A while ago I wrote about the handover that came with zero logins: a shop that came to me with no admin access, no hosting details and nobody who knew who controlled the domain. Getting that site back under control took longer than the work the owner actually wanted done.
That kind of handover isn’t rare. It’s one reason I care about the other end of the job: what I leave behind when a project finishes, or when a client moves on to someone else.
My view is simple. The shop belongs to the owner, not to me. If I’m the only person who knows how it fits together, I’ve built a bottleneck, not a website. So when I hand a site back, I leave a pack that lets the next developer, or the owner, pick it up without having to ring me.
Here’s what goes in it.
1. Access, owned by the owner
The first section is about who can get in, and who owns each account. That covers:
- WordPress admin, with the owner as an Administrator on their own account, not borrowing mine.
- Hosting control panel and SFTP or SSH.
- Domain registrar and DNS, which aren’t always the same company.
- Email sending (SMTP or a transactional service), payment gateways, and any shipping or stock integrations.
I don’t put passwords in the document. They go into the owner’s password manager, or they get reset and set up by the owner. The pack says where each login lives and whose name is on the account. If an account is in my name, I move it to the owner before I leave. Nothing should depend on my email address once I’m gone.
2. Where the site actually lives
Next is a plain description of the setup. Which host, which plan, where the server is, which PHP version, where the backups go and how often they run, and how to restore one. If there’s a staging site, I note where it is and whether it’s current. A staging site nobody has touched in a year is worse than none, because someone will trust it.
I also write down anything unusual: a CDN in front of the site, a firewall rule that blocks certain user agents, a cron job running on the server instead of WordPress’s own scheduler. These are the things that waste a new developer’s first afternoon.
3. The plugin list, with reasons
A list of active plugins is easy to export. What’s useful is the reason each one is there.
For each plugin that matters, I add a line: what it does for this shop, whether it’s a paid licence and who holds it, and whether it’s safe to update on autopilot. Something like “Handles trade customer pricing. Licence on the owner’s account. Test checkout after updates.” That one line can save someone from switching off the plugin that makes wholesale orders work.
If I’ve written custom code, I say where it is. A small custom plugin is far easier to find than snippets scattered across a theme’s functions file, so that’s where I put mine, and the pack points to it.
4. The “don’t touch this” notes
Every shop I’ve worked on has a few things that look odd but are there for a reason. A shipping zone that seems redundant. A setting that looks wrong but works around a gateway quirk. An old product that can’t be deleted because historic orders and reports still rely on it.
These go into a short section of their own, in plain English. “Don’t touch” doesn’t mean “never change”. It means “check why before you do”. I’d rather a future developer questioned one of my choices with the context in front of them than undid it by accident on a busy Friday.
5. What’s unfinished
No site is ever finished, so I’m honest about the loose ends. Known bugs that weren’t worth fixing yet, a plugin that’s due to be replaced, an update I held back and why. Writing these down is a bit uncomfortable, because it’s a list of things I didn’t get to. But it’s much better than the next person finding them the hard way, and the owner deserves to know.
6. Who to contact for what
Finally, a short list of the outside people and companies involved: the host’s support route, the payment provider, the theme or plugin vendors with paid support, and anyone else who’s worked on the site. Not personal phone numbers, just where to go when something breaks.
Why I bother
Partly it’s about doing the job properly. But it’s also good for me. A clear handover means clients leave on good terms, and quite a few come back later for new work because they know nothing is being held hostage.
It also keeps me honest while I’m working. If I know I’ll have to explain a decision in writing, I’m less likely to take a shortcut I can’t justify.
If you’re on the other side of this
If you own a WooCommerce shop and you’re not sure you could hand it to someone else tomorrow, start with the first section. Make a list of every account the shop depends on, and check that your name is on each one. That alone puts you in a far stronger position.
And if you’ve inherited a site with no notes, or you’d like a pack like this for the shop you’ve got, book a free consultation call with me. We’ll talk through where things stand and what to sort first.
If you’d like to see the kind of work I do, have a look at how I work with WooCommerce shop owners.
Written by Connie, an AI, from Neil Matthews’ notes, archive, and direction. Neil directed and edited this piece. He did not write these words. Augmented publishing by Neil Matthews.