For agencies and freelancers

Taking over a site without inheriting someone else's problems

The day you say yes, you become responsible for a setup you did not build, whose passwords nobody has, and whose domain may still belong to someone else. Here is the list to fill in before you agree.

What you leave with: a printable checklist in six groups, and the email template to send the outgoing provider.

The real risk is not technical

Taking over a site almost never creates a code problem. Code, you eventually read. What costs money is the things you do not own: a domain registered in the old agency's name, hosting paid on somebody's personal card, a DNS zone managed by a provider who stopped answering.

These discoveries always arrive at the same moment: three weeks in, on a Tuesday, when something breaks and you need an account nobody has. By then you are the responsible party in the client's eyes, and you are the one managing the crisis.

The list below gets filled in before you sign, or during the first week at the latest. It does not need to be green everywhere — it needs to be filled in. A known red box is a negotiating point; an ignored red box is an outage on a timer.

The six discoveries that change the quote

Each one turns a takeover into a project. Found early, they get priced. Found late, they get absorbed.

The domain is not in the client's name

You are not inheriting a site, you are inheriting a negotiation with a third party. Deal with it before anything else, and price it separately.

Nobody has access to the registrar account

Everything works, right up to expiry day. Recovering a lost account takes weeks and requires paperwork only the registrant can provide.

Backups do not exist, or do not restore

A backup that has never been restored is not a backup. Test one before committing to anything.

The client's email lives on the same server as the site

Any hosting migration becomes an email migration — a project in its own right, with its own risk and its own quote.

The site runs on abandoned versions

The takeover becomes an upgrade. Say so now, price it separately, and do not swallow it inside the handover fee.

There are other domains nobody mentioned

The old campaign, the misspelling bought as insurance, the defensive extension. They expire too, and you are the one who will get the call.

The email to the outgoing provider

Short, factual, no reproach. They are under no obligation to answer quickly, and an unpleasant tone only lengthens the delay. Copy the client in: they are the client on both sides.

Subject: Handover of access — [client name]

Hello, [Client name] has asked me to take over their website from [date]. They are copied on this message. So the transition happens without downtime, I'd need the following: — access to the hosting, including the control panel; — an administrator account on the site; — the name of the domain registrar, and access to the account if it is in your name; — an export of the DNS zone, or access to the interface where it is edited; — a full backup of files and database; — the list of third-party services and licenses the site relies on, with their renewal dates; — the code repository, if one exists. If any of these are in your name rather than [client name]'s, do tell me: we'll work out how to put it right properly, without anyone losing out. Happy to do this by phone if that's easier. Thanks in advance. [signature]

When the outgoing provider does not answer

It happens, and not always out of bad faith: a freelancer who closed shop, an agency that was acquired, an inbox nobody reads. Do not burn three weeks chasing.

Rebuild first what can be rebuilt without them. For many extensions, a domain's public registration data is freely available: it gives you the registrar, the name servers and the expiry date. The DNS zone can be read back record by record. The host can often be deduced from the server address.

For account access, it is the client who has to write, not you. A host or a registrar will only talk to the account holder, and a request coming from you will be refused — rightly so. Draft the text for them, they send it from their own address.

And set a deadline. After two weeks of silence, write to the client: what you did not obtain, what that means in practice, and what you propose — rebuild the access, or move everything that can be moved to accounts in their name.

What this checklist does not do

It does not tell you whether the site is well built. It is an inventory of what you own and what you are exposed to, not a quality audit.

It does not replace writing to the client. The boxes you leave empty have to be communicated, along with what you conclude from them. That email is what protects you the day one of them goes off — and it is also what justifies the quote.

The inventory is done once, then it keeps itself

The boxes marked “expiry date”, “certificate”, “name servers” and “the site responds” do not stay ticked: they quietly stop being true three months later. DomainVigil reads them continuously across every domain you manage and warns you before your client notices.

Run the inventory on a site you inherited

No card required. Add a domain and the full reading arrives in seconds.