Every few months someone emails us a version of the same problem. They've outgrown their previous developer, or the developer has gone quiet, or a freelancer moved on to a full-time job. They want to move the site. And then they discover that the domain is registered to someone else's personal account, the hosting bill goes to an email address nobody controls, and the code exists only on a laptop they can't call.

This is not usually malice. It's what happens when everything gets set up quickly by whoever was doing the work that day. But it's expensive to unwind, and occasionally impossible. So here's the plain-English version of what you should own, why each item matters, and the questions to ask before you sign with anybody — us included.

The one-line version

That's the whole principle. The rest of this post is just the list of places it applies, and what goes wrong when it doesn't.

1. The domain name

Your domain is the single most important asset in this list, and the most commonly mishandled. It's the address customers type, the thing your email runs on, and the identity search engines have spent years associating with your business. Lose it and you're not moving house — you're changing your name.

It should be registered with a mainstream registrar, in your company's name, on a company email address, with the billing card belonging to your company. Not your developer's account. Not a reseller panel bundled into a hosting package you may want to leave one day.

• Ask: which registrar is it on, and can I log in right now as the owner?
• Ask: is auto-renew on, and whose card is it? Expired domains get bought within hours by people who know exactly what they're doing.
• Ask: is the registrar lock on, and is two-factor authentication enabled on the account?

2. DNS — the switchboard

DNS is the setting that says 'this domain points at that server'. It's how the same address can serve your website from one provider, your email from another, and your newsletter tool from a third. It's small, it's boring, and it is the lever that moves everything.

Whoever controls DNS can point your entire brand somewhere else in about ninety seconds. That's why it belongs in an account you own, even when your developer is the one who edits it day to day. Keep a copy of the records somewhere outside that account too — a screenshot in your files is enough to rebuild from a bad day.

3. Hosting and infrastructure

This is where the site actually runs, plus whatever sits behind it: the database, file storage, the email-sending service, background jobs. Modern projects tend to spread across a handful of providers rather than one big server, which makes 'who has the account' harder to answer and more important to write down.

The pattern that works: your organisation creates each account, adds the agency to it as a team member, and pays the bills directly. It also means you see real usage costs instead of a marked-up line item, and you find out about a spike the same week it happens.

4. The code

Your code should live in a repository owned by your organisation from the very first commit — not copied over at the end as a zip file. There's a practical reason beyond ownership: the history matters. Being able to see when a change happened and why is what lets the next developer work confidently instead of guessing.

And check the contract language while you're at it. 'You receive a licence to use the deliverables' is a very different sentence from 'ownership of the work transfers to you on final payment'. Both exist in the wild. Only one lets you hire someone else next year.

5. Analytics and search tools

Analytics properties and search-console verification are usually set up in whichever account was open at the time. Then the agency changes and you lose the history — which is the entire value of analytics. A conversion rate with no prior year to compare it to is just a number.

Create these under your own organisation account and grant access outward. Same for tag managers, ad accounts, and any product-analytics tool. The data is about your customers; it should outlive every vendor relationship you have.

6. App store accounts, if you have an app

This one is worth extra care because the platforms make it genuinely painful to fix later. Apps must be published under your organisation's developer account, not your developer's. Moving an app between accounts is possible, sometimes, with paperwork, and it can put your reviews and ranking at risk.

Also make sure you hold the signing credentials and the store listing assets. An app you can't publish an update to is a liability with a countdown on it — the platforms deprecate old requirements every year.

What a proper handoff includes

When an engagement ends, 'the site is live' is not a handoff. What you should receive, in writing:

1. 01An inventory of every account and service the project touches, with who owns it and what it costs per month.
2. 02Owner-level access to all of them, verified — meaning someone on your side logs in while the other party is still reachable.
3. 03The repository under your organisation, with the history intact and a README that explains how to run and deploy it.
4. 04A short document naming the deploy process, where the environment secrets live, and who to call when something breaks at 2am.
5. 05A list of anything scheduled to expire — domain, certificates, API keys, paid plans — with dates.

The test for whether a handoff is real: could a competent developer who has never met your previous team get the project running and deployed from what you were given? If the honest answer is 'they'd have to ask someone', the handoff isn't finished.

If you're reading this too late

Most of it is recoverable, and it's less dramatic than it feels. Ask politely and specifically — one email listing each account and the transfer you're requesting, rather than a general request to hand things over. Registrars and platforms all have documented transfer processes, and most people cooperate once the request is concrete.

Where you truly can't recover something, rebuild it in your own name and move on: a new analytics property loses history but starts a clean record; a fresh hosting account is an afternoon. The one item worth escalating over is the domain. Everything else has a workaround.

We set up every engagement this way as a matter of course — accounts in your name, repository under your organisation, an inventory at handoff. If you're inheriting a project and want a hand untangling what you actually own, the discovery call is a fine place to start.