Here is a question worth answering before you need the answer: if your development agency stopped replying to email tomorrow, could you still reach the servers your business runs on?
For a lot of companies the honest answer is no, and they find out at the worst possible moment. Not because anybody set out to trap them — usually it happened by convenience. Somebody needed a server quickly, used the account they already had, and nobody revisited it.
Four accounts, and how to check each one
You can do all of this in an afternoon without any technical help.
The domain registrar
The most important one, and the most commonly misplaced. Whoever controls the domain controls your email and your website, and can move both.
How to check: log in to the registrar yourself. Not “we have the login somewhere” — actually log in. Confirm the registrant contact is a company address that will outlive any individual, and that auto-renew is on. A lapsed domain is recoverable for a while and then it is not.
DNS
Often somewhere other than the registrar — Cloudflare, Route 53, the host’s own panel. DNS is what decides where your traffic and your mail actually go, and it can be changed in seconds by whoever holds it.
How to check: find out which service answers for your domain and confirm you have an account on it with administrator rights, not a login somebody shares with you.
The cloud account
AWS, Google Cloud, Azure, or a managed host. This is where the servers, the database and — critically — the backups live.
How to check: two questions. Whose payment method is on the account, and whose email is the root or owner identity? If the answer to either is your agency, the account is theirs and your software is a tenant in it. Being able to log in as an invited user is not the same as owning it.
The app store listings
Apple and Google developer accounts, if you ship mobile software. These carry an extra sting: the listing carries your reviews, your ratings and your install base, and none of that transfers if the app has to be republished under a different account.
How to check: the account should be an organisation account in your company’s name, with your agency added as a user. If your product is published under the agency’s developer account, that is the one to fix first, because it is the one that cannot be undone cleanly.
The two people forget
Transactional email. Password resets, receipts, notifications. It usually runs through a service nobody thinks about until it stops, and its sending reputation is tied to a domain you own but an account you may not. If that account goes, your users stop receiving password resets, and you will spend a day working out why.
The payment gateway. Almost always in the client’s name, because money forces the issue — but check who holds the API keys and who can change the payout account. That is the one place where the consequence of getting it wrong is not an outage.
What “owning it” actually means
There is a distinction worth being precise about, because contracts and reality often disagree. You can own the intellectual property in the code and still be unable to run it, if the accounts it depends on belong to somebody else. Ownership of the software and control of the infrastructure are two separate things, and only the second one is any use at 3am.
The test we would apply: could you, today, without anybody’s cooperation, take a backup of your production database and stand the system up somewhere else? If the answer is no, you have a licence to your own product rather than possession of it — whatever the contract says.
If the answers are not what you hoped
Do not panic and do not open with an accusation. In our experience this is almost always drift rather than strategy, and most firms will help you fix it if you ask plainly.
- Ask for a transfer in writing, one account at a time, starting with the domain.
- Create your own accounts first, then have resources moved into them. Do not accept a shared password as a resolution — that is the same dependency with extra steps.
- Get billing onto your own payment method. Whoever pays tends to end up owning.
- Once transferred, remove access that is no longer needed, and write down where everything now lives.
If a vendor refuses outright, you have learned something important, and it is better to learn it now than during an outage.
Why we do it the other way
Every cloud account we operate is in the client’s name. We are an administrator on it; we are not the owner, and the bill goes to them rather than through us. That means we do not mark up infrastructure, and it means a client can hand the keys to somebody else without asking our permission or waiting for a reply.
It costs us leverage, and that is the point. A vendor whose main retention mechanism is that leaving is difficult has stopped competing on the work. We would rather be kept because the software runs well — which is the whole argument of running the infrastructure we build on.
If you are reading this because you already cannot get in somewhere, the audit we run on inherited projects starts with exactly this list. And if you would rather just do it yourself, that is genuinely a good outcome — this post is the whole method.
