Website handover to a client: access, videos and a handover pack

Launch day is not the end of a website project. The handover is: the moment the client can own, edit and recover their site without calling you for every small change.

By the VeoRec team · Oct 3, 2026 · 11 min read

A website handover is the step where a finished site stops being your project and becomes the client's asset. Done well, the client owns every account the site depends on, knows how to make the changes they will need every month, and knows what to do (and who to call) when something breaks. Done badly, you get an email in six months asking why the domain expired, or a request to "quickly" change a phone number that turns into a support contract nobody agreed to.

The handover below is the one for a typical agency-built marketing site: accounts to transfer, access levels, a short video for each everyday task, a single handover pack, and a written close. The examples lean on WordPress because it is common, but a Webflow, Shopify or headless build needs the same jobs done under different menu names.

Decide what the client should be able to do after the handover

Start from the end. Before you collect a single password, write down what the client's team should be able to do on their own after the handover. That list decides what you document, what you record and what you deliberately leave out.

• Own it: control the domain, hosting, analytics and every paid service in their own name, with their own billing.
• Run it: edit pages, publish posts, swap images, change menus, read form submissions.
• Grow it: add a user, add a page from an existing template, update SEO titles.
• Recover it: know where backups are, what happens when something breaks, and who to call.

Just as important is what they should not need to do: edit theme code, change server settings, update plugins on a live site without a backup. Say that out loud in the handover. It protects the client from breaking something and protects you from fixing it for free.

Transfer ownership, not just logins

Handing over a list of usernames and passwords is not a handover. If the domain is registered in your agency's name and the hosting is billed to your card, the client is renting their own website from you. Many painful handover stories start here.

Move each account into the client's name, with their billing, and then reduce your own access to what your support agreement needs. Some systems have traps that are worth knowing before you start.

Domains. The registrant is the person or organisation that registered the name and holds the contract with the registrar, as ICANN's registrant guide explains. That should be the client. Be aware that ICANN's transfer policy overview, written for the 2017 version of the policy, says that after a change to the contact information you generally cannot move the domain to a new registrar for 60 days, and registrars do not have to offer an opt-out. Transfer rules do get revised, so check your registrar's current terms, and plan the change early, not on launch week.

The lock catches people like this. An agency registers a client's new domain under its own name in March to get the build going, then changes the registrant to the client on launch day, 1 June. In July the client's IT provider wants to move all their domains to the registrar they already use. If that registrar applies the 60-day lock, the transfer cannot happen until the last day of July at the earliest, and the client hears "you can't" from a company they pay, for reasons they never chose. Register the domain in the client's name from day one, or change the registrant at kickoff, and the lock has expired long before anyone wants to move it.

Search Console. Google distinguishes verified owners, who proved ownership with a token such as a DNS record or HTML file, from delegated owners added by another owner. Its help page on owners and permissions warns that removing a verified owner from the user list does not delete their token, so they can re-verify unless the token is removed too. Make sure the client verifies with a token they control (a DNS record on their own domain is ideal), then remove your user and your token.

Analytics. In Google Analytics, users are added at the account or property level and managing users requires the Administrator role, per Google's user management help. Add the client as an Administrator first, then decide what role your agency keeps.

Give each person the right level of access

The fastest way to get a broken site is to give everyone full administrator rights. An administrator can install plugins, switch themes and delete users; the marketing assistant who updates the blog needs none of that.

Most CMSs have editing roles for this. WordPress, for example, ships with Administrator, Editor, Author, Contributor and Subscriber roles, described in its roles and capabilities documentation: an Editor can publish and manage everyone's posts and pages without touching plugins or settings. Give one or two named people on the client side an administrator account, everyone else an editing role, and write down who has which.

Use one account per person, never a shared "marketing@" login. When someone leaves the client's company, they can remove one user without changing a password that five other people rely on.

Decide what access your agency keeps

If you are providing support after launch, you will need some access. Keep it in the open: your own named user on each system, with the lowest role that lets you do the agreed work, listed in the handover pack like every other user. Never keep a copy of the client's administrator password "just in case".

Agree what happens to that access when support ends. The cleanest answer is that the client removes your users on that date, and you send a short reminder a week before. It is a small gesture, and it tells the client that their site really is theirs, which is the feeling a good handover should leave behind.

Record one short video for each everyday task

A 40 page PDF manual for a five page website will not be read. A set of short videos, each showing one task on the client's own site, gets watched at the moment it is needed: the first time someone has to change the opening hours, and again six months later when a new hire has to do it.

List the tasks from the goals you wrote at the start, and record one video per task. For a typical marketing site:

Record on the real site, not a generic tutorial. The client's menus, page names and custom blocks are what they will see, and a video showing a different theme creates more questions than it answers. Use a test page or a draft post so you do not publish anything by accident while recording. The guide on making tutorial videos covers the one-task-per-video approach in more depth.

How to record handover videos clients can follow

These viewers are not designers or developers. They will watch on a laptop, often in a small window, while trying to do the task in another tab. Record for that.

1. Prepare the screen Log in as an editor, not as your super-admin account, so the client sees the menus they will see. Close other tabs, hide the bookmarks bar, mute notifications, and zoom the browser so text is readable at a small size.
2. Say the goal first "In this video you will change the opening hours on the contact page." One sentence, so they know they are in the right video.
3. Narrate every click "Top left, Pages. Find Contact, click Edit." Move the mouse slowly and pause where they have to look for something.
4. Show the result Save, open the live page and show the change. People need to see that it worked.
5. Mention the one mistake to avoid "If you see a Theme or Plugins menu, you do not need it for this. Leave it alone."
6. End there No recap of everything else. The next task is the next video.

Add captions and a two line written summary for each video. Nielsen Norman Group's guidelines for instructional videos recommend captions for people watching without sound and short segments or chapters instead of one long video, and its research found people dislike it when video is the only option. The text matters. With VeoRec every recording gets an automatic transcript and captions, and you can press M to drop chapter markers in a longer walkthrough.

Check every recording for secrets before sending. A dashboard can show an API key, a customer's email in a form submission, or a password manager pop-up. In VeoRec you can draw blur boxes over anything sensitive in the editor and render the video to apply them. Try it on this mock settings screen:

The guide on keeping secrets out of screen recordings covers prevention before you hit record, which beats blurring afterwards.

Test and document forms, emails and integrations

Forms are where handovers fail quietly. The contact form sends to the developer's test inbox, the newsletter signup is connected to the agency's mailing account, and nobody notices until a client asks why they have had no leads for a month.

For every form and integration, write down four things in the handover pack: where submissions go, who receives the notification email, which service sends it (and whose account that is), and what spam protection is in place. Then test each one with the client on the handover call: submit the form, and have them confirm the email arrived in their inbox, not yours.

A filled-in entry is short. "Contact form (Contact page): submissions stored in the CMS under Forms. Notification to hello@ and the office manager. Sent through the client's own email-sending account, set up on launch day. Spam protection: a hidden honeypot field plus the CMS's built-in filter. Tested on the handover call: arrived in both inboxes within a minute." When a lead goes missing in month four, that paragraph tells the client exactly where to look first.

Do the same for anything that depends on a key or account: maps, payment, booking widgets, chat, analytics tags. If a key belongs to your agency, replace it with one on the client's account before handover. Otherwise it will stop working the day you tidy up your own accounts, and nobody will remember why.

Backups, updates and what happens when something breaks

The most valuable page in the handover pack is the one the client reads on their worst day. Write it for that day.

• Backups: what is backed up, how often, where the copies are stored, how long they are kept, and who can restore one. Test a restore before handover, not after a disaster.
• Updates: who updates the CMS, plugins and theme, how often, and whether updates are tested first. If it is the client, record a video; if it is you, it belongs in a support agreement.
• If the site is down: a numbered list. Check whether it is down for everyone, check the hosting status page, contact the host (with the support link and account number), then contact you (with the hours you cover).
• Renewals: domain, hosting, SSL if separate, paid plugins and licences, with dates and who pays.
• Support terms: what is included after launch (for example, two weeks of fixes), what counts as a fix and what counts as new work.

Be explicit about the end of free support. "Bugs in what we built are fixed free for 30 days; content changes and new features are quoted" is clear and fair, and it saves a difficult conversation in month three.

Put everything in one handover pack

Everything above needs to live in one place the client can find in a year: a shared document or page with links, plus a folder of videos. Not five emails, not your project tool that the client loses access to when the project closes.

A folder of recordings shared with one link works well for the videos, because new people on the client side can be sent the whole set at once. In VeoRec a folder review link shares a whole folder with one URL, view-only or open for comments; the folder review links guide shows how that works for clients without accounts.

Run a handover session, then confirm it in writing

Videos teach the tasks. A live session of 45 to 60 minutes checks that the handover worked: the client logs in with their own accounts, makes one real change while you watch, submits a form and sees it arrive. Ask them to drive. If they get stuck, you have found a gap in the pack, and it is far cheaper to fix now.

Record the session too, with the client's permission. It catches the questions that only come up live ("what does this orange warning mean?"), and the answers can become new task videos or a line in the pack.

Then close it in writing. Send the confirmation from the templates above and ask the client to reply. It does not need to be a legal document. It needs to say, in plain words, that they have ownership and access, that they received the pack, and when free support ends. That one email is what you point to when a question arrives a year later.

Record the handover videos once, share them with one link Record each task on the client's own site, blur anything sensitive, and share the whole folder with the client. Free plan included. See VeoRec for agencies

What to do before your next launch

The best handovers are planned at kickoff. Put ownership and access in the project plan from the start, so you are not chasing domain logins on launch week, and record task videos as each template is finished rather than all at the end.

If the site will be maintained by another developer rather than the client, the same pack becomes the start of a technical handover; the guide to developer handoff documentation covers what to add for them.