Here’s a conversation I’ve had more times than I’d like.
Someone from a membership organisation gets in touch. Their website has gone down, or their domain has expired, or they want to move to a new supplier. And somewhere in the first ten minutes I ask a question that sounds simple:
“Can you log in to your domain registrar?”
And there’s a pause.
Sometimes it’s because they don’t know what a domain registrar is, which is entirely reasonable — it’s not their job to know. But more often it’s because they’ve just realised that they can’t. The account is in somebody else’s name. Possibly a former agency. Possibly a volunteer who moved on three years ago. Possibly the founder’s son-in-law, who set it all up as a favour in 2011.
This is not a rare situation. In small and mid-sized organisations, it’s close to the norm.
Why this is uncomfortable to write about
I’m a web developer. I run a business that looks after other people’s websites. Writing a blog post encouraging you to make sure you can leave your web supplier at any time is, on the face of it, a slightly odd commercial decision.
But I’ve been doing this for thirty years, and I’ve picked up enough websites from other people to know what the alternative looks like. It looks like an organisation paying for a rebuild they don’t need because nobody can get into the old site. It looks like a charity losing an email address they’ve had for fifteen years. It looks like a week of my life spent on hold to a registrar in another country trying to prove that a nurse-led association in Bedfordshire is entitled to its own domain name.
Lock-in isn’t a business model. It’s just a mess that somebody eventually has to clean up, and the organisation pays for it either way.
So: the questions.
The ownership checklist
Work through these one at a time. For each one, you want a name — an actual person at your organisation who could log in today — and ideally a note of where the credentials are stored.
1. Your domain name
Who is the registrant? Not who manages it. Who is legally recorded as owning it.
This should be your organisation, using an organisational email address that will still exist when individuals move on. If the registrant is an agency, a freelancer, or a personal Gmail account, that needs fixing, and it’s usually a straightforward transfer.
Where is it registered, and can you log in? You want the registrar name, the account login, and a diary note of the renewal date. Domains expire. Organisations that have gone quiet over the summer have lost domains over the summer.
Is auto-renew on, and is the card on file still valid? This catches people out constantly, because the card belonged to a finance officer who left.
2. DNS
DNS is the layer that decides where your domain actually points — your website here, your email there, your event platform somewhere else.
It’s the least visible thing on this list and the most disruptive when it goes wrong, because a DNS mistake takes down your website and your email at the same time. Know where it’s managed and who has access.
3. Hosting
Who is the account holder? Same principle as the domain: it should be the organisation.
Is the hosting paid for directly by you, or bundled into a supplier’s invoice? Bundled isn’t wrong, but you should know, because it changes what happens if that relationship ends.
Do you have, or can you get, the login? You don’t need to use it. You need to be able to get it.
4. Your CMS
Someone at your organisation should hold a full administrator account on your own website. Not an editor account. Administrator.
I’d add a caveat here that I mean genuinely — I’ve seen organisations given an “admin” account with half the functions hidden. Check that whoever holds it can actually reach the plugins, users and settings screens.
5. Email
Email and website are separate things that people routinely assume are the same thing.
Who runs your email — Microsoft 365, Google Workspace, your host? Who is the tenant administrator? Can that person create and delete accounts?
This one has the sharpest consequences, because losing control of email means losing the ability to reset the passwords for everything else on this list.
6. SSL certificates
The padlock in the address bar. These expire, usually annually, and when they do, every visitor gets a full-page browser warning telling them your site isn’t safe.
Know whether yours renews automatically and who gets the reminder email. If the reminder goes to somebody who’s left, you’ll find out the hard way.
7. Backups
Where are they, who can restore them, and — the question almost nobody asks — could you take a copy of your own site with you tomorrow if you needed to?
A backup you can’t access independently isn’t really yours.
8. Licences and subscriptions
Membership plugins, LMS platforms, form builders, event tools, premium themes, stock image subscriptions, analytics.
These are usually the messiest part, because they accumulate over years and often sit on a supplier’s account for convenience. That convenience is fine, right up until it isn’t. Ask for a list of every paid component your site depends on, who holds each licence, what it costs and when it renews.
9. The invoices
Look at what you’re actually paying for. Renewal invoices are the fastest way to discover services you’d forgotten existed, and occasionally services you’re paying for twice.
10. Your content and your data
Can you export your member list, your content and your media library in a format that isn’t locked to one platform?
For membership organisations this is also a data protection question, not just a practical one. Your member data is your responsibility regardless of whose server it sits on.
“Our agency handles all that”
This is the answer I hear most, and it’s usually said with complete confidence.
It’s not a bad answer. It’s just not an answer to the question. A good supplier absolutely should handle all of it — that’s the job. The question is whether you could take it back if you had to.
The test is simple, and you can apply it without any awkwardness at all. Send an email that says:
“We’re updating our internal records. Could you send us a list of the accounts and services our website depends on, confirm who the registered account holder is for each, and let us know where the domain is registered?”
A good supplier will send it back the same week, possibly with a note saying they’ve been meaning to do this for ages. It’s an entirely normal request.
If the response is defensive, vague, or somehow never arrives — that is your answer, and it’s worth knowing now rather than in the middle of a crisis.
What a proper handover pack looks like
Whether you’re starting with a new supplier, ending with an old one, or just tidying up, this is what should exist as a document somewhere your organisation controls:
- Domain registrar, account details, registrant name, renewal date
- Where DNS is managed, and access details
- Hosting provider, account holder, plan, renewal date
- CMS administrator account details
- Email platform and tenant administrator
- SSL provider and renewal arrangement
- Backup location, frequency, retention period, and how to restore
- Every paid plugin, licence and subscription with cost and renewal date
- Any third-party integrations — payment provider, CRM, email marketing, event platform
- A named contact at each supplier
Keep it in your organisation’s own document storage, not in an individual’s inbox. Review it once a year — the August audit afternoon is as good a time as any. Update it whenever someone leaves.
It’s a two-page document. It takes an afternoon to assemble the first time and twenty minutes a year after that, and it is the difference between a supplier change being an administrative task and being a six-week crisis.
The uncomfortable bit
If you’ve read this far and quietly realised you can’t answer several of these questions, you’re in the majority. It’s not a sign that anyone’s done anything wrong. It’s what happens when websites get built by whoever was available, maintained by whoever had time, and handed over informally between people who all meant well.
But it does need sorting, and it’s much easier to sort while everything is working than after something has broken.
Start with the domain. If you get nothing else off this list, get the domain in your organisation’s name with a renewal date in your calendar. Everything else can be rebuilt. That can’t.
If you’d like a hand working through this, or you’d simply like someone to tell you honestly what state your site is in, that’s what our Website Check-Up is for — a full review, a plain-English report within 48 hours, and a plan any competent developer could work from, whether that’s us or not. Which is rather the point of this whole post.
And if you’d like the handover checklist above as a document you can circulate to your board, book a call or send me a message and I’ll send it over.
