The website handover checklist for agencies
A website handover checklist for agencies: accounts, access, ownership and the five things to check on the day, so launch week doesn't become support month.
Launch week has a particular sound. The site is live, the invoice is out, and the messages start: who has the domain login, why the contact form goes to someone who left, how do I change the photo on the About page. None of it is hard. All of it is unbilled, and it can run for a month.
We've written before about how to write the handover document itself: restrict first, write tasks rather than a tour, say who owns what. This post is the other half. It's the website handover checklist you tick through on the project, so that the document has something true to describe. Copy it, cut what doesn't apply, and add what your clients always ask about.
Accounts and ownership
The domain registrar account is in the client's name, or there's a written date when it moves to them.
The registrar renewal date, the card on file and who gets the renewal email are recorded.
DNS: who controls it, where it's hosted, and a copy of the current records saved with the project.
Hosting: who pays, on which account, and what happens if the card fails.
Email: confirmed as the client's provider and the client's responsibility, in writing. It's the one most often assumed to be yours.
Any third-party service the site uses (maps, booking, newsletter, analytics) is on an account the client owns, not one of yours.
Every login that the site depends on is listed in the client's own password manager, not in a spreadsheet you sent.
Access
Every person who will edit the site has their own named login. No shared "office@" account for editing.
Each person has the narrowest role that covers what they actually do. Someone who writes news posts doesn't need to publish pages. Someone who publishes doesn't need to change the structure.
Nobody at the client holds the owner or admin role unless there's a specific reason, written down.
Your own team's access is reviewed: people who worked on the build but won't support it are removed.
There's a named person at the client who requests new logins, so you're not adding accounts on the word of whoever emails first.
The roles question deserves its own thinking, and CMS user roles and permissions goes through how to split them.
Content
It's written down that the content belongs to the client.
They know how to get it out: an export, an API, or a clear statement of what you'll provide if they leave.
Placeholder text, test pages and sample entries are gone. Search the site for "lorem" and "test" before you assume.
Every form's notifications go to an address the client checks, ideally a role address rather than a person.
The client knows where form submissions are stored, not only that they arrive by email.
Version history or backups exist, and the client knows that a mistake can be undone.
The live walkthrough and the video
Booked for twenty to thirty minutes, with the people who will actually edit, not only the person who signed the contract.
The client drives. You watch.
They complete at least three real tasks: add an item, edit a page, publish a change.
You note every moment of hesitation, and fix the site or the document afterwards.
The walkthrough is recorded, or a separate short video is made per common task.
The videos live somewhere the client controls, linked from the handover document.
Each one is short enough that a new staff member will actually watch it.
The change-request route
One address or form for change requests, written in the document.
What's included in support and what's quoted work, in a sentence each.
How quickly you reply, even if the answer is "within two working days".
What counts as urgent, and what urgent costs.
The one-month check-in
A date in your calendar, set on launch day, four weeks out.
A short message: anything you've wanted to change and couldn't work out?
Any answers become fixes to the site or the document, not just replies.
The five things to check on the day
Most of the list above is done during the build. These five are done on handover day itself, with the client in the room or on the call.
The client signs in with their own login, on their own device, and it works.
They can reach the content they'll edit, and can't reach the settings they shouldn't.
A real test form submission arrives in their inbox, not yours.
They know where the handover document and the videos live, and can open both.
They know the one address for change requests, and who will answer it.
The platform items
Three things on this list depend on what your platform can do, so they're worth checking separately.
Invite the client to their own workspace or site only, never to an account where they can see your other clients.
Give editors an Editor or Author role, not Owner. Editors can publish; Authors can draft but not publish. Keep structural changes with your own team.
Agree who promotes changes from staging to the live site, if your platform has a staging step, and write their name in the handover.
In Contentive each of those is direct: a client is invited to their own workspace only, the built-in Editor, Author and Viewer roles separate publishing from drafting from reading, structure is a separate permission from content, and going live is a deliberate promote step, so there is one clear moment to put a name against. Seats are unlimited on the Agency plan, so naming every editor costs nothing.
What tighter roles cost you
There's a trade-off here, and it's worth being honest with yourself about it. The narrower the access you hand over, the more requests come back to you. A client who can't add a new kind of section will ask you to add one.
That's the point. Those requests are design and structure changes, and they're billable. The requests that tighter roles prevent are the ones that weren't: the font that changed itself, the page someone deleted, the layout that broke when a ninth item was added. If you're unsure which kind your clients send, what to do when a client breaks their own website describes the second kind in detail.
Do this today
Run the accounts and access sections during the build, not after go-live, when the domain is already pointing and nobody wants to touch anything. The pre-launch checklist covers the technical side of launch week.
Open your project template, wherever it lives, and paste this list into it as a section. Then cut the items that don't fit how you work. A checklist that exists in every project, even a shorter one, beats a perfect one that lives in a blog post you read once.