Website handover checklist: what the client must own
A website handover puts everything the client needs to run the site in the client’s own name: the domain, DNS, hosting, the CMS or store, the code, analytics, Search Console, tags, email and payments — each with two of the client’s people as admins, and the agency’s access removed or kept to a named date. Below are the checklist, a template with an example, the order that avoids lock-outs, what each platform leaves behind, and how to set a project up so there is nothing to transfer.
We see this all the time through our registrars and unfortunately there is nothing we can do when contacted by the company that hired the design firm. Legally they do not own the domain and any request to give them access to it must be denied.
— one commenter writing for domain registrars, on Domain Name Wire (2008)
What a website handover includes
- Every account in the client’s name: domain, DNS, hosting, the CMS or store, the code repository, analytics, Search Console, Tag Manager, the business profile, email and forms, payments.
- Access the client controls: two of the client’s people as admins on each account, the recovery email on the client’s side, and the agency’s access removed or kept to a named date.
- What was agreed, and what was delivered: the pages and features in the signed scope, the change requests, and the acceptance.
- How to run it: how to edit content, how to deploy, what renews when, whose licences the paid themes and plugins use.
- Backups: where they are, and a restore that has been tested.
- Open items and support: each open item a warranty fix or a change request, with a date; the warranty; who answers questions, and until when.
For an application rather than a website, the software handover document goes deeper into the build, the documents and who owns the code.
Website handover checklist
Domain and DNS
- The domain registered to the client’s company, in a registrar account the client owns and pays for.
- Auto-renew on, the renewal date written down, and a payment card still valid on that date.
- DNS in an account the client owns, with the records exported before anything moves.
- The client’s own email address on the registration and as each account’s recovery email.
Hosting, CMS and store
- The hosting or platform account in the client’s name, on the client’s card or invoice.
- Two of the client’s people as administrators of the CMS or store — in WordPress, Administrator, not Editor or Shop Manager.
- Paid themes, plugins and apps licensed to the client, or a list of those on the agency’s licences and when they end.
- Backups: where, how often, how long they are kept, and the date of a tested restore.
- Who renews the SSL certificate, or a note that the host renews it.
Code
- The theme and custom code, with its history, in a repository the client owns.
- Deploy instructions followed by someone other than their author.
- Passwords, API keys and deploy keys the agency knew, changed.
Analytics, search and marketing
- The Google Analytics property in the client’s account, with two of the client’s people as administrators.
- Search Console: the client a verified owner, and the agency’s verification tokens removed.
- The Tag Manager container in the client’s account, with two of the client’s administrators.
- The Google Business Profile with the client as primary owner.
- Ad accounts and social media pages under the client’s business, with two of the client’s admins.
Email and other services
- Email on the domain, form and newsletter services, maps and other API keys, CDN and uptime monitoring: each in the client’s name, and listed in one place.
Payments
- The payment account opened by the client’s company, paying out to the client’s bank account.
Agreed, delivered and open
- The scope as agreed — pages, features, the site map version — and the change requests delivered, declined or moved.
- The acceptance: the UAT sign-off and its date.
- Open items, each a warranty fix or a change request, with a date.
- The warranty, the support terms, and who answers questions until when.
- The client signed in as owner to every account, and said so in writing.
Website handover template
Copy it into Word, Google Docs or Confluence. Square brackets are yours to fill in; section 2 repeats for every account.
WEBSITE HANDOVER
Site: [domain]
Contract: [statement of work], [date]
From: [agency], [contact]
To: [client], [who receives it]
Date: [handover date]
1. WHAT WAS DELIVERED
Scope: [pages, features];
[document], version [x]
Changes: [CR ids] delivered;
[CR ids] moved to
[phase]
Accepted: [UAT sign-off, date]
2. ACCOUNTS
[service] Owner: [client]
Admins: [two people]
Billing: [client]
Renews: [date]
Agency: [removed /
until date]
3. CODE, LICENCES, BACKUPS
Repository: [URL], owned by
[client]
Licences: [themes, plugins,
apps]: [whose]
Backups: [where, how often,
how long]; restore
tested [date]
4. HOW TO
Edit content: [guide]
Deploy: [guide]
Renewals: [list]
5. OPEN ITEMS
[id] [what]
[warranty fix / change
request] by [date]
6. SUPPORT
Warranty: [from] to [to]
Questions: [who], until [date]
7. RECEIVED
Name, role: [ ]
Signed in as owner to every
account: [yes / which not]
Date: [ ]
Website handover example
A company website — 24 pages, a quote form and a blog — rebuilt on WordPress by an agency, at launch:
WEBSITE HANDOVER
Site: the client's company site
Contract: Statement of work, 10 March
From: Agency, project lead
To: Client, marketing lead
and IT lead
Date: 12 June
1. WHAT WAS DELIVERED
Scope: 24 pages, quote form,
blog; site map
version 2, 2 April
Changes: CR-2, CR-3 delivered;
CR-4 moved to phase 2
Accepted: UAT sign-off, 9 June
2. ACCOUNTS
Domain Owner: client, in the
company name
Renews: 14 February
DNS Owner: client
Hosting Owner: client
Agency: user until
11 August
WordPress Admins: marketing
lead, IT lead
Agency: admin until
11 August
Analytics Owner: client
Agency: removed
Search Owners: marketing
Console lead, IT lead
Agency: user and
token removed
Tags Admins: marketing
lead, IT lead
Forms Email service in the
client's name
3. CODE, LICENCES, BACKUPS
Repository: the client's GitHub
organization, tag
launch-1
Licences: theme and two paid
plugins: client's
Backups: host, daily, kept 30
days; restore tested
5 June
4. HOW TO
Edit content: editor guide
Deploy: DEPLOY.md
Renewals: RENEWALS.md
5. OPEN ITEMS
DEF-12 Quote form slow on phones
warranty fix, by 19 June
CR-4 Online booking
change request, phase 2
6. SUPPORT
Warranty: 12 June to 11 August
Questions: project lead, until
11 August
7. RECEIVED
Name, role: IT lead (client)
Signed in as owner to every
account: yes
Date: 12 June
Two lines carry most of the weight. “Agency: admin until 11 August” keeps the agency’s access through the warranty, but as a user of the client’s accounts and with an end date. “Signed in as owner to every account: yes” means the client checked rather than took the list on trust — the check that catches each of the problems further down this page.
The order that avoids lock-outs
A lock-out can come from the right steps done in the wrong order. One commenter describes an agency employee who, at the end of a contract, “removed himself as an admin on the page in order to “hand over the keys.” Except he hadn’t made anyone else an admin yet”; the client could not get back in for four months (Hacker News, 2021).
- Add the client first. Make two of the client’s people owners or administrators on every account, and have each of them sign in.
- Move the domain’s registrar before changing its owner details. ICANN: “Request the transfer to another registrar before changing the registrant’s information (to avoid the 60-day lock)” (ICANN).
- Move what has to move, and watch the deadlines. A GitHub repository transfer has to be accepted: “If the new owner doesn’t accept the transfer within one day, the invitation will expire” (GitHub). A new owner of a Google Business Profile has “to wait 7 days before you can manage some profile features” (Google).
- Then remove the agency. GitHub’s order for an organization: “add a new owner, ensure that the billing information is updated, and then remove yourself from the account” (GitHub). Some platforms enforce it: in Google Analytics, “if you are the last user who has the Administrator role, you cannot delete yourself” (Google), and on a Business Profile, “If you’re the primary owner, you can’t remove yourself until after you transfer primary ownership to someone else.”
- Change what the agency knew. Passwords, API keys and deploy keys. A transferred GitHub repository keeps its “webhooks, services, secrets, or deploy keys”, and “The original owner of the repository is added as a collaborator on the transferred repository.” One commenter, advising an agency taking over a client from another: “Make sure you gain access to their accounts and stop the old agency from accessing their accounts. Most people don’t bother deleting the accounts of the previous agency” (r/agency, 2023).
- Check from the client’s side. The client signs in as owner to every account, and every renewal is billed to the client.
What moves, and what stays behind
Each platform documents its own transfer. These are the parts that catch people out, from each platform’s help pages as they read in October 2026. They change; read the linked page on the day.
Domain names
A registrar must give the registrant the transfer code: “Your registrar must provide you with the AuthInfo code within five (5) calendar days of your request.” It may refuse a transfer “if the domain name is within 60 days of initial registration” (ICANN). Moving a domain between two Cloudflare accounts locks it again — “After successful move, the registration will be transfer-locked for 30 days” (Cloudflare) — and “You must reissue SSL/TLS certificates and recreate and validate DNS records” (Cloudflare).
ICANN’s board adopted a revised transfer policy on 7 June 2026 without setting a date for it to take effect, and country domains such as .uk or .de follow their own registry’s rules. Check the registrar’s current terms before starting.
WordPress
On WordPress.com, “it is possible that a site, its plan, and its domain name each belong to different accounts” (WordPress.com), so each of the three has to move. On a self-hosted site, ownership is the hosting account, the database and the domain; a WordPress login is access, not ownership. And any administrator left behind can do anything: “In the case of single site WordPress installation, Administrators are, in effect, Super Admins” (WordPress.org).
Shopify
Shopify separates two set-ups. In a collaboration, the agency works in a store the client already owns: “You work in their live store, but you don’t own the store and it’s not transferred to you.” A client transfer store is built under the agency’s organization; “After the transfer, the merchant owns the store and it leaves your organization.” It cannot be transferred while Shopify Payments is active, “including Shopify Payments in test mode”, and dev stores “can’t be transferred to a client” (Shopify). “Each store has only one store owner”, and “Email messages from Shopify are sent to the store owner’s email address” (Shopify).
Google Analytics
A property can move between accounts. “To move a property, you need the Administrator and Editor roles for both the source and destination accounts.” The data goes with it: “All reporting data associated with a property is moved (not copied) to the destination account”, and “The Tracking ID (for example, G-123ABC) does not change, so there’s no need to retag anything.” The change history stays behind with the old account (Google). Without an administrator on the old account, nothing can be moved, and a new property starts with no history.
Search Console
Removing the agency’s user is not enough. “A property must have at least one verified owner”, and the verification token the agency added — a file, a meta tag or a DNS record — has to go too: “If you do not delete these tokens, the removed owner will be able to re-verify ownership if they choose to” (Google).
Google Tag Manager
Google’s advice is to “ensure that there are at least two active administrator accounts”, and to “make sure your account is managed by someone in your organization, not an external agency” (Google).
Code repositories
On GitHub, the agency stays on as a collaborator after a transfer, and the repository’s secrets and deploy keys stay attached (above). On Bitbucket, “The original owner of the repository will still have administrative access to the repository at its new owner/location” (Bitbucket). Either way, removing the agency is a separate step.
Hosting platforms
On Vercel, a transferred project’s integrations “must be added again after the transfer is complete”, and “Monitoring data is not transferred” (Vercel). On Netlify, “Project members who are not members of the destination team will lose access to the Netlify dashboard for the project” (Netlify).
Payments
Stripe separates the person from the business. “The current owner of a Stripe account can transfer ownership to another user” (Stripe), but moving an account to a different business starts with Stripe Support, and then the payout bank account, the statement descriptor, and the legal business name and tax ID all change (Stripe). A payment account the agency opened for itself is not the client’s.
Mobile apps
Apple’s Account Holder role goes to “another employee on the team who has the legal authority to bind your organization to legal agreements” (Apple) — so not to someone at the agency. Apple and Google Play transfers each have their own conditions; the software handover document lists the main ones.
Set it up in the client’s name from day one
The cheapest transfer is the one that never happens. If the client opens the accounts and adds the agency as a user, the handover is removing a user. One developer describes their practice: “All domains and hosting are billed to clients without my involvement” (r/freelance, 2024). Another, a full-stack developer, offers clients: “Your code lives in a repo you own from the first commit, with handover notes” (Hacker News, 2026).
Keep section 2 of the template from the first week, as an access register: one entry per account, with the owner, the admins, the billing and the renewal date — and where the password is kept, not the password. One lead developer who planned for their own replacement put it this way: “the documentation repo has references to every credential (what it is, where it’s used, who owns it) but zero actual values” (Hacker News, 2026).
Then write it into the statement of work: the accounts are opened in the client’s name, the code is the client’s, and what will be handed over at the end.
When the previous agency still holds the keys
Taking over a website from another developer usually starts with finding out what the client does not own. One WordPress agency describes its first agency switch: “the outgoing agency had registered the client’s domain on a reseller account they refused to release until a disputed invoice was paid, the GA4 property was owned by an ex-employee’s personal Gmail, and the client had been logging into WordPress as a “Shop Manager” for three years without realizing they had never been promoted to administrator. That switch took fourteen working days and a small legal letter” (WitsCode, 2025).
The domain. Look up who the registrant is. A developer called in by a client: “I’ve also checked the WHOIS records, that tell me that my client is not the owner of this domain/hosting service. The first company didn’t register the service with the client’s name” (Stack Exchange, 2014). If the client is the registrant, the registrar must hand over the transfer code. If the agency is, the registrar cannot help, as the commenter at the top of this page says, and getting the domain back is a matter for the contract — this is general information, not legal advice. Keep it renewed meanwhile: one commenter who lost their business domain to a web design company that “refused to transfer control” writes that “they let it expire and today its listed in the domain aftermarket” (Domain Name Wire, 2013).
Search Console. Anyone who controls the site or its DNS can verify again: “If the only verified owner of your site leaves your team, you should verify ownership to maintain (or regain) access to the property” (Google).
Analytics and tags. These need someone with admin rights on the old account. One company found that “A former employee had Google Analytics for multiple websites setup under his personal gmail account” (Stack Exchange, 2012). Without that person, the client starts a new property and loses the history.
Website handover email
Subject: Website handover: [domain]
Hi [name],
[domain] is now yours. The handover is
attached, with:
- what was delivered against [scope
document], version [x]
- every account, each owned by you,
with two of your people as admins
- the backups and the last restore test
- [n] open items, each with a date
Please sign in as owner to each account
and reply "Received", or tell me which
one you can't open.
Our access ends on [date]. Until then
I'll answer questions.
Thanks,
[name]
Where Specroot fits
This is the problem Specroot works on: the part of a handover that is not an account — what was agreed for the site, each approved change, and who accepted it — kept as one record, instead of reassembled from email at the end. Specroot for agencies and consultancies.
Read next
- Software handover document: template, checklist and example — A software handover document template and checklist, with an example: what was delivered, who owns the code, accounts, documents, open items and support.
- UAT sign-off template — A free UAT sign-off template and email to copy: what the document includes, the sign-off criteria, and how to tie acceptance to the version that was approved.
- Statement of work template for software development — A free statement of work template for software projects, what a SOW should include, SOW vs scope of work vs MSA, and clauses for acceptance and changes.