Most website problems we get asked about aren't really technical. They're handover problems wearing a technical costume.
Across the communities we follow, the same story keeps coming back in different clothes. A volunteer takes over the site for a small professional club from someone who ran it for many years, and asks how to set things up so the club owns it, not whoever happens to hold the passwords. An agency owner asks who is supposed to own updates once a project is "done". A client finds out the domain is registered to a freelancer who stopped answering email. A developer who has built client sites for years shares the contract clauses they added one painful lesson at a time. Someone else explains how they monitor a pile of sites without drowning in alerts.
None of these people were asking for a plugin or a framework. They were asking the same question: how do you hand a site to someone else so they aren't stuck?
We've done a lot of handovers, in both directions. Here's the checklist we wish every project started with, and the mistakes we see most often.
The idea: plan the handover on day one
The best time to prepare for a handover is before anyone needs one. If the site is set up as if a stranger will take it over next year, the actual handover becomes a short meeting instead of a rescue mission.
That mindset works whether you're an agency, a solo freelancer, or the one volunteer at a nonprofit or club who "knows computers".
The checklist
1. The organisation owns the accounts, people get access
The domain registrar, hosting, DNS, email sending and any paid plugins or services should sit under an account the organisation controls: a shared role address like web@ or admin@ your domain, paid with the organisation's card.
Individuals, including you, get their own logins with the right permissions. Not a shared password that lives in one person's head or browser.
Test: can someone at the organisation name, in under a minute, whose card pays for hosting and whose email owns the domain? If the answer includes "I think", that's your risk list.
2. At least two humans can get in everywhere
One admin is a single point of failure. Give a second person, usually a board member, owner or office manager, their own admin login on the site, at the registrar and at the host. Check where password resets go and who holds the second factor. A recovery email pointing at an inbox nobody reads is the quietest way to lose a site.
3. Write the one-page "where everything lives" doc
This is the part nobody does, and it's the most useful page you'll ever write for a client. Keep it short:
- Where the domain is registered and when it renews
- Where the site is hosted and what plan it's on
- Where backups go, how often, and how to restore one
- Which paid licences exist and when they renew
- Who to call for what (you, the host, a plugin vendor)
One page, stored somewhere the organisation can find without you. The next handover then takes minutes.
4. Decide who owns updates, in writing
"Who updates the site after launch?" is one of the most common arguments we see between agencies and clients, mostly because nobody answered it at the start. Pick one:
- The client owns updates and accepts the risk
- You own them under a care plan with a clear scope
- Nobody does, and everyone agrees that's a decision, not an accident
Any of these can work. Leaving it unspoken is what causes the angry email two years later.
5. Updates are more than the "Update all" button
A point we keep seeing from people who maintain sites: clicking update on every plugin and theme does not touch the version of PHP the server runs. Plenty of sites look perfectly maintained in the dashboard while the runtime underneath is years behind. On managed hosting this is often handled for you. On cheaper shared hosting, it's usually left to the site owner.
Add "check the server's PHP version" to the handover doc and to every maintenance routine.
6. Backups that someone has actually restored
A backup nobody has tested is a hope, not a backup. During handover, restore one to a staging copy together. It takes an hour and it tells the new owner more about the setup than any document.
And one lesson people keep relearning: if a site gets hacked, restoring an older backup can bring the backdoor right back. Finding out how the attacker got in comes before the restore, not after.
7. Set support hours and boundaries
Freelancers regularly ask what to charge when a client messages at seven in the morning on a weekend. The cleanest answer we've seen: put normal support hours in the agreement and price anything outside them clearly. Then the client decides whether it really can't wait, and nobody has to feel guilty.
The same applies to volunteers. "I'll help when I can" is fine, as long as everyone knows that's the deal.
8. Keep the plugin list lean and documented
For each plugin or extension, note in one line why it's there. When the next person inherits the site, "contact form", "event calendar" and "nobody knows, don't touch" are very different entries. Remove the third kind before you hand over.
9. Do a real walkthrough
Sit down with the person taking over (or a call with screen sharing) and have them drive: log in, publish a post, change a menu item, find the backup, renew something. Whatever they can't do on their own is what's missing from the doc.
Mistakes we see over and over
- Domain in the developer's name. Usually done with good intentions to "make it easy". It becomes a hostage situation the day the relationship ends.
- One shared admin password. Nobody knows who changed what, and removing access means changing it for everyone.
- "The site is done." Websites aren't done. They're either maintained or slowly decaying.
- Handover as an afterthought. Scrambling to find logins in the final days of a contract is how things get missed.
- No exit plan for the volunteer. In clubs and small nonprofits, the person who built the site often stays the only one who can change it. That works right up until they move on.
Where to start if you've just inherited a site
If you're the new volunteer or the new agency and the previous person is already gone, work in this order: secure the domain first, then hosting, then the site's admin access, then backups, then everything else. Make a list of every account that costs money, whose card pays for it, and who can actually log in. Anything marked "the old developer" or "not sure" goes to the top.
Your turn
- What's the one item you now insist on in every handover, and what taught you to add it?
- For small clients, who owns updates after launch in your projects: you, them, or nobody?
- Volunteer webmasters: how did your organisation make sure the site didn't depend on just you?
- Have you inherited a site with no handover at all? What did you do first?
We'd love to build this list out with your experience, especially the items that only show up after something goes wrong.
Top comments (0)