Why Website Handover Documentation Matters (and What Should Be In It)

The most expensive moment in a website's life is usually eighteen months after launch, when the one person who understood it leaves. Nobody knows which registrar holds the domain, the CMS admin account belongs to a former contractor, and the only person who could edit the homepage template has moved to another authority. The site is fine. The organization's ability to operate it is gone.

Handover documentation is the cheapest insurance against that, and it is routinely treated as an afterthought — a folder of screenshots emailed on the final day. It should be a named deliverable in the contract, scoped and reviewed like any other.

Why this matters more in the public and nonprofit sectors

Staff turnover is higher, institutional memory is thinner, and the people who commissioned the project frequently are not the people maintaining it two years later. A city communications officer moves on. A nonprofit's part-time coordinator is replaced by a volunteer. An administration changes.

There is also a procurement dimension. If your documentation is inadequate, your next competitive tender is unfair to every vendor except the incumbent, because only they know how the thing works. Good handover documentation is what makes your next procurement genuinely competitive — which is a reason to specify it in this one.

What handover documentation should contain

Accounts and access

Every account the site depends on, who controls it, and how to recover it: domain registrar, DNS, hosting, CMS admin, SSL, analytics, search console, email or form delivery service, payment processor, CDN, any third-party integrations.

The critical detail is ownership. Accounts should be registered to organizational addresses, not to an individual's work email and certainly not to the vendor's. A domain registered to a former employee's personal account is one of the most common and most damaging failures we encounter.

Architecture

What the site is built on, where the code lives, where it deploys from, and how a change gets to production. It does not need to be long. It needs to be enough that a competent developer who has never seen the project can orient themselves in an hour rather than a week.

Include the things that are not obvious from the code: why the redirect map exists, which integrations are fragile, what breaks if a particular API key expires.

Content model

Which content types exist, what fields they have, and where facts live. If the opening hours are set in one place and referenced everywhere, write that down — otherwise the next editor will start pasting hours into individual pages and the single-source discipline erodes within months.

Editing instructions

Written for the person who will actually do it, covering the tasks they will actually perform: publish a news item, add a document, update a staff member, change hours, post an emergency notice. Task-based, not feature-based. Nobody needs a tour of the CMS; they need to know how to do the six things their job requires.

Accessibility guidance

The build can be accessible on launch day and non-conformant within a year if editors do not know the rules. Document the ones that matter to editors: write meaningful alt text, do not skip heading levels, do not paste styled text from Word, use real lists, caption video, avoid publishing scanned PDFs as the only copy of important content.

This is the part most handovers omit, and it is why sites that passed an audit at launch fail one two years later. Our accessibility audits regularly find that the underlying build is sound and the content added since is not.

Maintenance and dependencies

What needs updating and how often, what the backup arrangement is and how to restore from it, what monitoring exists and who receives the alerts. If maintenance is contracted out, name what is covered and what is not — the gap between what an organization assumes is covered and what actually is tends only to surface during an incident. See maintenance and support.

Known issues and deferred work

The honest list: what was descoped, what is a known limitation, what will need attention within two years. A vendor who hands over a clean bill of health on a project of any size is not being straight with you, and the next team will find these things anyway — better they find them in a document than in production.

Specify it in the contract

Write handover documentation into the RFP as a deliverable with a defined scope, and make final payment contingent on accepting it. Ask for it in a format you can edit and store, not a PDF you cannot update, and ask for it a fortnight before launch rather than after, so there is time to read it while the team is still engaged.

Then ask for a training session against it, with the recording kept. The recording outlives the trainer.

Test it before you sign it off

The only real test is whether someone who was not on the project can use it. Give the documentation to a colleague and ask them to perform three tasks from it without help: publish a news item, add a document, and find out who controls the domain.

Whatever they get stuck on is the gap. That exercise takes half an hour and is the difference between documentation that exists and documentation that works.

A short specification you can paste into an RFP

"The vendor shall deliver written handover documentation no later than two weeks before launch, covering: all accounts and access with confirmation that each is registered to the organization; system architecture and deployment process; content model and where canonical facts are maintained; task-based editing instructions for named routine tasks; accessibility guidance for content editors; maintenance schedule, backup and restore procedure, and monitoring arrangements; and a written list of known issues and deferred work. Documentation shall be provided in an editable format. Final acceptance is contingent on the organization successfully performing three nominated tasks using the documentation alone."

That paragraph costs you nothing and changes what you receive. If you are drafting a solicitation now, our checklists for government and nonprofit website RFPs cover the surrounding sections, and the public sector pillar explains how we treat handover as a deliverable rather than a courtesy.