Website handover process: what you should be holding when the project ends

What 'handover' actually means, and why most guides get the audience backwards

Search for "website handover process" and the guides that come up coach the seller. Elementor's post walks agencies through handing a site to their clients, and Cloudways publishes a near-identical checklist for its own hosting customers, both scoped to what the professional should prepare and present. Even the word "handover" belongs to the person doing the handing over.

That framing is not a claim about the whole search results page, just about the guides audited for this article: Elementor's, Cloudways', and one buyer-side exception from Innovins, covered below. But the pattern holds across all three: they tell the designer what to hand off. None of them tells the client what to check for before agreeing to the project. The question that actually matters to you is not "how should my designer present this," it's "what must I end up holding."

Why the checklist has to be agreed before you sign, not at the end

By the time a handover conversation happens, you have usually already paid. Milestone payment schedules typically put the final instalment due before the completed files transfer to you or the site goes live on your own server, a pattern our web design payment plan guide lays out in detail. If that is how your contract is structured, you have no leverage left at handover: the money has cleared, and whatever the designer agreed to hand over is what you get.

The practical result is that the handover checklist belongs in the contract you sign at the start of the project, not in a conversation you have at the end of it. Negotiate the list of what you'll receive, and when, before any deposit changes hands.

The five things you must end up holding

Group everything you're owed at the end of a build into five categories. For each, there's a question worth asking your designer directly, and an answer that should worry you.

1. The domain

Ask who is listed as the registrant on the domain record, not just who can log in to the registrar account. A designer who can only say "you have access" without naming who the registrant is has not actually answered the question, and the difference matters more than it sounds. More on why below.

2. The hosting

Ask for the hosting account credentials, or for the site to be hosted somewhere you control from day one. Elementor's own handoff checklist lists hosting access as a standard deliverable, alongside domain registrar credentials and a CDN login. If your designer treats hosting access as something to be arranged "later, once everything's stable," that's the answer that should worry you: stable is exactly when handover checklists get quietly forgotten.

3. The source files

Ask for the source code and design files, not just a live URL you can view. Cloudways' offboarding checklist for agencies handing off client sites includes directory outlines, stylesheets, scripts, and databases as standard deliverables, on top of login credentials. If a build was on a closed platform where there is no exportable source file to hand over, that's worth knowing before you sign, not after.

4. The content and assets

Ask for your copy, photos, and logo files in their original, editable form, not screenshots or a PDF of the finished pages. This is the deliverable category least likely to be disputed, but it's also the one most often forgotten because nobody thinks to ask for the raw files until they need to update a page themselves.

5. The accounts around the site

Ask, by name, for every account tied to the site: analytics, search console, email hosting, SSL certificate management. Innovins' buyer-side handover checklist lists Google Analytics and Search Console access alongside domain, hosting, and CMS credentials as one of ten items a client should collect from their web development company. This is the category most likely to be missed, because it's easy to confirm you have CMS access and stop checking.

Credentials are not ownership

A website handover means the designer transfers the domain, hosting, source files, content, and related account access to the client, ideally backed by a written document and a walkthrough session, not just a verbal handoff. But if you're the one receiving the handover, the more useful question is a different one: does having all of that actually mean you own the site?

Look closely at what the two most detailed handover checklists actually contain. Elementor's list covers WordPress admin and editor accounts, hosting access, domain registrar credentials, a CDN login, an offboarding PDF, a project summary, and support plan details. Innovins' ten-item buyer checklist covers domain registrar credentials, hosting and control panel access, CMS admin, source code and backups, the database, email hosting, SSL, Google Analytics and Search Console access, backup and security setup, and maintenance plan clarification.

Between them that's thirteen items. Every single one is either a login or a file. Not one of them is the question that actually determines ownership of a domain: whose name is on the registration.

Ownership of a domain follows the registrar account and the named registrant, not who paid the invoice. You can hold every credential on both of those lists and still not be the registrant of your own domain, because "registrant" is a specific, checkable field on the record, and neither checklist audited here asks for it. This is the credentials-versus-ownership distinction: a login proves you can access something, it doesn't prove you own it. Our do I own my website guide breaks ownership into the same four separate pieces, domain, hosting, code, and content, for the same reason: each one can be withheld independently of the others.

What it costs to fix the registrant late

If you discover at handover that the domain is registered in your designer's name rather than yours, fixing it is not instant. Changing a domain's registrant name, organization, or email address triggers ICANN's 60-day transfer lock, documented by registrar DNSimple. At DNSimple, once that lock is in effect it cannot be bypassed or shortened. Some registrars offer an opt-out, but only if you request it before making the change, not after.

The lock exists to stop domain hijacking, which is a reasonable policy. But it means that correcting a registrant problem at handover, instead of catching it at signing, can freeze the domain at its current registrar for two months. If you were also planning to move the domain to a different registrar as part of taking full control, DNSimple's documented workaround is to transfer the domain first and change the registrant details afterward, since the lock applies to registrant changes, not to transfers on their own. Either way, this is the concrete, dated cost of leaving the registrant question until the project is already finished.

Accounts that can quietly stay under the designer's control

Google Search Console is the clearest example of an account where you can have everything that looks like access and still not have control. Google's own documentation on managing owners, users, and permissions explains that a verified owner has full control over a property, including the ability to add or remove other users. A property needs at least one verified owner at all times, or users lose access after a grace period.

So it's entirely possible for a client to have full day-to-day CMS access to their own website while the designer remains the only verified owner of the Search Console property tied to that site. You can view search performance data, but you cannot add your own staff, your next agency, or a new designer to that property, because that requires a verified owner's token, and removing an existing verified owner requires deleting their verification, per the same Search Console documentation. Until someone does that, the original owner can simply re-verify themselves.

The same pattern applies to analytics accounts, email hosting, and SSL certificate management: any account tied to the site where "verified owner" or "admin" is a distinct role from "user." Ask, by name, who the verified owner or admin is on each one, not just whether you have a login.

The walkthrough and final testing

Once the checklist items above are agreed, two things still need to happen before the project is genuinely finished. Neither one is a document.

The first is a live walkthrough. A packet of credentials and files tells you what you now hold, it doesn't tell you how to use any of it. A session where someone shows you how to make an edit, publish a page, or find your own analytics beats a written manual on its own, because it's the point where you find out what you don't know how to do while the person who built the site can still answer.

The second is a final testing pass, timed to handover day rather than only during the build. Forms, checkout flows, and any integrations should be checked again once the site is on its final domain and hosting, since a page that worked correctly in a staging environment can fail once it moves to a live server with different settings.

Moving the site to another host later

Can you transfer your website from one host to another? Generally yes, if you hold the source files and hosting credentials covered in the checklist above. Whether it's straightforward depends on the platform the site was built on: a site built with an exportable code base moves more easily than one built inside a closed platform's own editor. This is exactly why hosting access and source files are listed separately in the checklist above, rather than assumed to come as a pair.

Where Press fits

Press builds the finished site for you to preview before you pay anything. If you decide to keep it, one payment of $299 makes the finished site and its source code yours outright: ownership of the deliverables transfers to you with no lock-in. Hosting afterward is optional, through a paid care plan if you want us to keep managing it, or you can take the files and host them yourself. Press does not register or transfer domains on a client's behalf, so the domain and registrant questions above still apply to any project, including one built with us.

Questions