Handover and training at the end of a build

Handover is the point at which control of the finished site actually transfers from the website development project to the client — not a symbolic final meeting, but working, tested access to every account and system the site depends on, plus training appropriate to how much the client intends to manage themselves going forward.

What a proper website handover actually includes

Item	Why it matters
Domain registrar access	Confirms who legally controls the domain licence, not just who manages the site day to day
Hosting account access	Needed to move the site to a different host in future, if that decision is ever made
Content management system admin login, under the client’s own account	Prevents the client being locked out if the relationship with the supplier ever ends
A copy of, or access to, a recent backup	The client’s own insurance against data loss, independent of the supplier
FTP or file access, and any custom source code	Needed only where the build includes custom-coded functionality beyond the CMS itself, so a different developer can pick up support work
Documentation of any custom functionality and its software dependencies	So a different supplier could pick up support work later without starting from nothing
Training on routine tasks the client will actually perform	Editing text, updating images, adding a blog post — whatever is relevant to that specific site

The pattern across every row is the same: handover is complete when the business could, if it needed to, walk away from the current supplier entirely and still retain full control of its own website. A handover that leaves any of these items sitting only in the supplier’s own accounts is not a completed handover, whatever else has happened.

Why access and ownership, specifically, are the items most often left incomplete

It is common, and not necessarily malicious, for a domain or hosting account to end up registered under the supplier’s own details during the build, simply because it was faster to set up that way at the time. The problem surfaces later, sometimes years later, when the relationship changes and the business discovers it does not actually control its own domain or hosting. Confirming at handover — not assuming — that the registrant on the domain, and the account holder on the hosting, are the business itself is worth doing explicitly, in writing, rather than trusting that it was set up correctly along the way. The wider legal picture of who ends up owning what in a website project, beyond just these accounts, is a related but separate question worth understanding fully rather than assuming favourably.

What training should actually cover

Training should match how the client intends to use the site, not a generic walkthrough of the whole content management system. A business that will only occasionally update an opening-hours notice needs a short, focused session on exactly that task. A business planning to publish its own blog posts regularly needs a genuinely thorough walkthrough of the editor, image handling and publishing workflow, plus a written reference to return to later, because a single training session is rarely enough to retain every detail. Training pitched at the wrong level — too basic for a business that wants to manage content actively, or too thorough and technical for one that just wants the phone number updated occasionally — wastes the session either way.

Whether training is included as standard, or offered as a separate paid session, varies by supplier and is worth confirming during scoping rather than assuming. See small business website design for what is typically bundled into a small-business engagement, including handover provisions, and where training commonly sits inside or outside that package.

What a candid handover looks like versus a rushed one

A rushed handover looks like a single email with a login and no further explanation, sent once the invoice is settled and the supplier has mentally moved on to the next project. A proper one is scheduled as its own session, with a checklist both sides work through together, confirming each item above is genuinely in place and tested — not just promised. The difference in effort between the two is real but modest; the difference in outcome, months later if something goes wrong or the relationship changes, is substantial.

What happens when handover is skipped or left incomplete

The most common consequence of an incomplete handover only becomes visible later, often when the business wants to make a change, switch suppliers, or the original point of contact at the supplier moves on. A business that does not hold its own domain and hosting credentials can find itself unable to act quickly — needing to request access from a supplier who may be slow to respond, has changed staff, or in the least common but most serious case, is no longer contactable at all. None of this is likely to matter in the weeks immediately after launch, which is exactly why it is easy to defer. It is worth treating as a task to finish before the project is considered closed, rather than something to sort out “at some point,” because the point at which it becomes urgent is also the point at which it becomes hardest to resolve.

A simple way to confirm handover is actually complete

A useful, concrete test: could someone at the business, without contacting the supplier, currently log in to the domain registrar, the hosting account, and the content management system, using credentials the business itself controls rather than ones borrowed from the supplier for a single session. If the honest answer to any part of that is no, handover is not yet finished, regardless of how much work has otherwise been delivered.

Where the handover process sits in the sequence

Handover typically overlaps with the tail end of the post-launch warranty period, rather than waiting until it fully closes — there is no reason a client should be locked out of their own site’s accounts while warranty fixes are still being applied. This is the final stage in the fourteen described across this cluster; from here, the site moves into the ordinary, ongoing life of ownership, maintenance and eventual redesign, which this outer section’s sibling guides on maintenance and lifecycle cover in their own right.