What a website handover pack should include, and what to refuse to sign off without

The day a build goes live is often treated as the end of the project. It shouldn’t be. Going live means the site works. Website handover means you have credentials in your name, the source code, written IP transfer, every premium licence, documentation a new developer could pick up cold, and a tested backup. Those are two different milestones, and most agencies invoice as if they were the same.

A handover pack that looks complete on the day usually isn’t. We’ve seen too many clients, six months later, locked out of their own domain registrar because the agency’s office manager set it up on a personal account in 2019 and has since left. So before signing off on the final invoice, here is what a real handover contains, and what you should refuse to accept the build as finished without.

What a real website handover actually means

There are two definitions of handover. The first is ‘the site is live, you can log in, here are the basics.’ The second is ‘you have everything required to operate, maintain, debug, migrate, and replace this site, in your name, on your accounts, with documentation a new agency could pick up cold.’

Sign-off should mean the second. If it means the first, you are renting your own website from the people who built it.

This piece is about getting the second.

Credentials, in your name, on your accounts

The most common handover failure has nothing to do with the build. It is administrative. Credentials are transferred verbally, on a shared Notion page, or (worse) left as the agency’s accounts with the client added as a secondary user. That is not a handover. It is an access loan.

Every credential below should be on accounts owned by your organisation, registered to a corporate email that survives staff turnover (not someone’s personal Gmail), and confirmed in writing as transferred:

• Domain registrar. Not transfer access, the actual registrar account. If the domain sits in the agency’s GoDaddy or Namecheap, push it. You should own and control the domain.
• DNS management. Often Cloudflare. Your account, your billing.
• Hosting account. Root or owner-level hosting access, not a sub-user invitation that the agency can revoke.
• CMS admin. Super-admin role, not editor or admin-with-restrictions. Confirm by logging in yourself before sign-off.
• Source code repository. GitHub, GitLab, Bitbucket: whichever, the org should own the repo, not a personal account.
• All third-party services integrated into the build: CRM, email marketing, payment gateway, analytics, search console, tag manager, monitoring tools, error tracking, transactional email.
• Premium plugin and theme licences (more on these below).

A useful test: if the agency disappeared overnight, you should be able to log in to every service the site depends on, today, without contacting them. If you can’t, sign-off isn’t ready.

Who owns the source code after the agency builds it?

Custom code built for you should be owned by you. That sentence sounds obvious. It isn’t always what the contract says, and it almost never matches what the handover delivers by default.

Two things to confirm in writing before sign-off.

First, the IP transfer. Custom code, custom themes, custom plugins, custom integrations: confirmed assigned to your organisation in a written deliverable. Standard agency contracts usually cover this in a clause, but the handover should reference that clause and confirm the deliverables it applies to. We have seen disputes turn on whether a custom plugin counted as ‘deliverable code’ or ‘the agency’s reusable internal tooling.’ Get the list explicit.

Second, the repository. You should receive admin access to a Git repository containing the full, current, deployable codebase, with the deployment history intact. A zip of the codebase doesn’t count. Neither does a Dropbox folder. The deliverable is a working repository. If the agency claims their internal monorepo prevents this, ask for a clean export. They can do it; some prefer not to.

Licensed code (WordPress core, off-the-shelf plugins, frameworks) is a separate category. You are not buying ownership of those. You are buying the right to use them, which is what the licences below cover.

Who pays for the premium plugin licences after the build?

Every paid licence the site depends on should be registered to an account your organisation owns, not the agency’s. This is where slow leaks start. A site shipped in 2024 with ACF Pro, Gravity Forms, WPML, Yoast Premium may be running on five separate licences, every one of them registered to the agency’s account. The site works fine. 18 months later the agency renews, or doesn’t. The licences lapse. Updates stop. The first you hear of it is when a plugin breaks after a WordPress core update and you can no longer access the support portal.

For every paid licence:

• Registered to an account your organisation owns.
• Documented in the handover with the licence key, the renewal date, and the cost.
• Confirmed working from your account before sign-off.

If the agency built on tooling that doesn’t allow licence transfer (some bespoke commercial themes work this way), that is a flag worth raising before the build, not after. A handover pack that lists three unlisted licences sitting on the agency’s account isn’t a handover.

The same logic applies to managed services: CDN account, transactional email (Postmark, Mailgun, SendGrid), error tracking (Sentry), uptime monitoring. If the agency’s account is in front of any of these, you are paying a service fee through them or losing access when the relationship ends.

Handover documentation a new developer could pick up cold

The test: a developer who has never seen the site sits down with the handover pack and can deploy, debug, and extend the site without contacting the previous agency. That is the bar.

In practice, that means:

A README in the repository describing the local development setup, environment variables, build commands, and deployment process. The level of detail a competent developer would expect when joining a new project, not a list of links.

A list of every integration the site relies on, with the purpose, the endpoint, the rate limits where relevant, and how authentication works. CRM, payment gateway, mailer, analytics, anything that talks to anything.

A list of scheduled tasks (cron jobs, queue workers, scheduled actions in WordPress, whatever the platform calls them) with what each one does and how often. We have seen sites where a critical nightly export was running on the developer’s personal server because nobody asked where it lived.

An environments document: where staging is, what credentials, what the deployment flow is, what the rollback procedure is. If there is no staging environment, that should be flagged, not omitted.

An open issues list. A real one. Not ‘no known issues’ when there are three open tickets. The handover should be honest about what’s left, what’s been deferred, and what the technical debt looks like.

A backup and restore procedure, with evidence (recently) that a restore has actually been tested. An untested backup is a hope, not a backup.

The operational details that quietly fail later

A handover pack covering credentials, code, and documentation but skipping operational details will look complete and still cause problems in month four.

Email deliverability is the most common one. SPF, DKIM and DMARC records configured for any domain that sends mail from the site, with documentation of what’s been set up and where. If the contact form started working two weeks ago and stops working a month from now because a record drifted, that should be diagnosable from the handover.

Recent performance benchmarks. Page load times, Core Web Vitals, server response times. Not for vanity. Without a baseline, you cannot tell a year from now whether the site has degraded or always ran that way.

The security posture. Last scan, last update, what’s been patched, what hasn’t. If the build was made on a CMS with a public vulnerability disclosure history, your handover should tell you what version everything is on.

Any monitoring or alerting the agency had configured. If they were getting alerts when the site went down, that channel needs to redirect to you, or you need an equivalent set up before they walk away. Otherwise, you will find out the site went down by a customer calling you about it.

What to refuse to sign off without

If a single item below is missing on the day, the handover documentation isn’t finished. Final invoice waits.

1. Every credential in your organisation’s name, on your accounts, tested by you. Including the domain registrar and DNS, not only the CMS.
2. A working Git repository under your organisation’s account, containing the deployable codebase.
3. Written confirmation of IP transfer for all custom-built work, referencing the relevant clause in the contract and the specific deliverables it covers.
4. Every premium licence the site depends on, transferred to an account you own, documented with renewal dates.
5. Technical documentation that a competent new developer could deploy and extend from, without contacting the previous agency.
6. A tested backup. Tested recently. With a written restore procedure.
7. An honest open-issues list. No site is perfect at handover; pretending otherwise is the problem.
8. Email deliverability records, with documentation.
9. A handover document confirming the items above are delivered.

The good handover packs get built alongside the work, because the work is the documentation. When an agency tells you the handover will take a fortnight, what they mean is that the documentation didn’t exist while the site was being built. Note that for next time.