Website handover checklist
Every website rests on five layers, and each one is usually looked after by someone different. A handover is complete when you know, for each layer, who holds it, where the login lives and who pays. This is the list.
Last changed 26 October 2026, about 7 minutes to read
Most handovers cover the website itself: the admin login, maybe the hosting. Then the domain lapses eight months later because the renewal was on the old developer’s card, or the DNS turns out to live in an account nobody can reach. The layers below the site are the ones that take it down, and they are the ones a handover forgets.
Work through the five layers in order. For each, get three answers: who holds the account, where the login is kept, and who pays. Write them down with the date and the name of the person who told you. An answer without a source goes stale silently.
1. The registrar: the domain name itself
- Whose name is the domain registered in? The registrant should be your client’s company, not the developer and not the agency. If it is not, start the transfer now; it is the one thing on this list that can take weeks.
- Which registrar holds it, and who has the account login? Where that login is kept, not the password itself.
- When does it expire, and does it renew itself? Check the date with the domain expiry checker. Auto-renew is only as good as the card on the account.
- Who pays, and with what? The card or account the renewal is charged to, and whether that person still works there.
- Is the transfer lock on? Without it, anyone with the authorisation code can move the domain.
2. DNS: where the name points
- Who serves the DNS? Often the registrar, often Cloudflare, sometimes the host. The who-hosts check reads it from the nameservers.
- Who can edit the records? This is the login a migration needs and an outage needs. If it is a Cloudflare account, is it the client’s or the developer’s personal one?
- Email records. MX, SPF, DKIM and DMARC live here. A DNS move that forgets them breaks the client’s email, which is the most common collateral damage of a website migration. Check them with the SPF and DMARC checkers before and after any change.
3. Hosting: where the site runs
- Which host, which plan, which account? And the login to its control panel, SSH or SFTP, kept where.
- Who pays, and when does it renew? Hosting on a developer’s reseller account is hosting you do not control.
- The certificate. Does it renew itself, and from where? The certificate checker shows the issuer and the date.
- Anything in front of it. Cloudflare, a firewall, a CDN: another account, another login.
4. Backups: the layer nobody can see from outside
- Where are the backups, and how often do they run? The host’s own service, a plugin, a separate provider. “The host does it” is not an answer until you have seen the setting.
- When was a restore last tested? A backup that has never been restored is a hope. If the answer is never, do one now, on a staging copy.
- Who pays for it, and who holds that login?
5. The application: the site itself
- Admin logins. Make your own, then remove the old developer’s and any shared account such as “admin”. Turn on two-factor where the platform offers it.
- What it is built with, and what is out of date. On WordPress, every plugin and the theme. Note which are paid, and whose licence they are on; a plugin licensed to the old agency stops updating when they cancel it.
- The code. Is there a repository, and whose? A site whose only copy is on the server has no history.
- Services the site depends on. Analytics, tag manager, email sending, forms, payments, maps: each has an account, and each account has a holder. The page source lists most of them.
- What it shows the world. The WordPress version check and the headers check show what an attacker sees first.
Then write it down somewhere it stays true
A handover document is accurate on the day it is written. Six months on, the hosting has moved, a plugin has been added and the person who held the DNS login has left. The record has to be checked against the world, and it has to say when each answer was last confirmed.
That is what Stackbrace is for: it fills in the layers it can see from outside, asks you for the ones no scan can see, dates every answer, re-asks after six months, and tells you when the world and the record disagree. Check a site now to see what it finds without an account.