The Website Handover Checklist: What You Should Actually Receive When the Build Is Done

Most website projects end with a phone call and a launch announcement. Nobody sits down and asks the boring question, which is: what do I actually now own?

Six months later that question gets asked in a hurry. The developer has moved on, the domain is about to expire in someone else's inbox, and nobody can log in to change a phone number on the contact page. The site works fine. The business just cannot touch it.

The takeaway up front: a website project is finished when you hold the keys, not when the site goes live. Everything below is something you can ask for while the invoice is still open, and something that is genuinely awkward to retrieve after the relationship ends. Walk the list on a screen share before you sign off.

1. The domain, registered in your name

This is the one that causes real damage, and it is the easiest to get wrong. A domain registered in an agency's account, under an agency email, is an asset you are renting without a contract.

What you want to be able to demonstrate at handover:

• You can log in to the registrar yourself.
• The registrant contact is your business, using an email address that survives staff changes — not a personal Gmail, not the developer's.
• Auto-renew is on, and the card behind it is yours.

If a supplier bought the domain as part of the project, transferring it to your own registrar account is a normal, well-documented process. Ask for it before the project closes, not during a renewal panic.

2. Hosting, with a login that is yours

Same principle, one layer down. You need to know where the site is hosted, under whose account, and what happens if that supplier disappears.

Bundled hosting is not a bad thing — it is often the sensible choice for a small business, and it removes a genuine source of finger-pointing when something breaks. It just needs to be a stated arrangement rather than an assumption. Ideyasweb, for instance, publishes hosting and a domain package as line items inside its web design package, and its own FAQ states plainly that if you do not already have website hosting, it can be included as part of the package. That is the level of clarity to ask for: is hosting mine, yours, or ours, and on what terms?

Get in writing: the host, the plan, the renewal date, who pays it, and whether you can be added as a user on the account.

3. A top-level admin account in the CMS

Not an editor account. Not a shared login typed into a chat message. Your own administrator account, with your own email, that you have logged into at least once while the developer was still on the call.

Then test the thing you will actually do: change a sentence on a page and publish it. This is the single most useful five minutes of the whole handover, because it is where "you can edit it yourself" either turns out to be true or turns out to mean "you can edit it yourself if you already know this page builder."

The promise is common and it is a reasonable one to hold a supplier to — Ideyasweb's published FAQ says its sites are built on user-friendly content management systems so you can update text, images and content without needing technical expertise. Fine: ask to prove it during the call, on your own account, on a real page.

4. The design and source files

The site is the output. The files are what let a different person work on it next year without starting over.

Ask for:

• Logo files in vector format (SVG or a layered original), not just the PNG that was cropped for the header. If your logo only exists as a small raster file, every future print job, sign, and app icon becomes a redraw. Our guide on why a logo looks blurry covers why this matters more than it sounds.
• The design source — the page designs in whatever tool they were drawn in, with view access at minimum.
• Fonts and licences. Which typefaces the site uses, and whether the licence covers web use for your business. A font installed on the designer's laptop is not a licence.
• Image rights. Which photos are licensed, from where, and for what use.

None of this is exotic. It is the difference between a redesign in three years being a project and being an excavation.

5. Analytics and search tooling, connected to your accounts

If the tracking sits inside the agency's analytics property, you do not have your own history — you have a report someone sends you.

At handover you want your own analytics property, your own search console property with your domain verified, and confirmation of what conversion events are actually being recorded. "Analytics and conversion tracking" is a standard part of a serious redesign scope — it appears explicitly in Ideyasweb's published redesign inclusions, alongside the technical clean-up and on-page SEO setup — so it is fair to expect it configured rather than mentioned.

The specific question to ask: when someone submits the contact form, what fires, and where can I see it? If nobody can answer that, the site cannot be judged on results later, only on opinions.

6. A backup you have watched being restored

Everybody says there are backups. Far fewer people have ever restored one.

Ask three questions:

1. Where do backups live, and are they somewhere other than the same server as the site?
2. How often do they run, and how many are kept?
3. Has a restore been tested?

You do not need a disaster-recovery plan for a five-page business site. You do need to know that the answer to "the site is broken and it is Saturday" is a file that exists somewhere you can reach.

7. A named owner for updates, in writing

This is the item most handovers skip entirely, and it is the one that decides what the site looks like a year from now. Content management systems, plugins and themes ship security updates continuously. Somebody has to apply them, notice when one breaks a form, and keep an eye on whether the site is still up.

There are only three valid answers, and any of them is fine as long as it is chosen deliberately:

• You do it, on a calendar reminder, with a written note of what to check.
• The builder does it under an ongoing care arrangement.
• A third party does it, with access documented.

What is not fine is nobody. Ideyasweb runs website care and maintenance as its own service line — its FAQ describes ongoing updates, backups, security monitoring and performance optimisation after launch — which is the shape the arrangement should take whoever provides it: named tasks, a stated cadence, and someone who answers the phone. Decide it at handover, while the person who built the site is still in the room.

The handover session itself

Book thirty minutes and do these five things live, in this order:

1. Log in to the registrar, the host, and the CMS from your device, on your accounts.
2. Edit one line of real copy and publish it.
3. Submit the contact form and watch the enquiry arrive where it is supposed to arrive.
4. Open the site on your own phone, on mobile data, and click through the main pages.
5. Screenshot the analytics dashboard so you know what "normal" looked like on day one.

Then write the answers down in one document — accounts, renewal dates, who to call, and which of the three update options you chose. That document is worth more than the project files, because it is the thing you will actually reach for.

FAQ

Is it unreasonable to ask for all of this?

No. Every item is either an account you already paid for or a file that was produced as part of the work. A supplier who resists domain transfer or an admin account is telling you something useful about how the relationship will go later.

What if the site is already live and I never got any of it?

Work backwards, and start with the domain — it is the item with a hard deadline attached and the one that is most painful to lose. Then hosting, then the CMS account. Ask politely and in writing. Most of the time it is disorganisation rather than hostage-taking.

Do I need the design source files if I never plan to change the site?

You will change the site. Everyone does. But if you truly want to travel light, the non-negotiable minimum is vector logo files and a written list of your brand colours and fonts — that is enough for someone else to work from later.

How long should a small-business build take, and does handover add to it?

It varies with scope, and a stated range is a good sign the project has been scoped rather than just priced. Ideyasweb, for example, publishes that most business websites are completed within 2–6 weeks, with larger or custom projects quoted additional development time. Handover itself is an hour of the last week, not a separate phase — if it is being treated as an extra, it was not planned in.

Next step

Before you approve the final invoice, run this checklist as a live call rather than an email. Every item should be something you can demonstrate on your own screen, on your own account.

And if you are still choosing who builds it — the same logic applies earlier in the process; our guide to hiring a web designer covers the briefing and vetting side. If you want a builder whose scope already names the parts that usually go missing, Ideyasweb I.T. Consultancy is worth a look for one specific reason relevant to this checklist: its published web design package lists the CMS, security features, and a hosting and domain package as explicit inclusions rather than assumptions, and it offers website care and maintenance — updates, backups, security monitoring and performance optimisation — as an ongoing service after launch. Ask any supplier to be that specific in writing, and handover stops being the awkward conversation at the end.