How to Write a Handover Document at the End of a Project

Every other client document is read within days of being sent. A handover document is read in March, by somebody who has never met you, after something has broken.

That single fact should determine everything about how it is written, and it usually does not, because handovers get written on the last day of a project when you have the least patience and the most confidence that all of this is obvious.

Write it for a stranger, not for the client you have

The characteristic failure is documenting the thing as you understand it rather than as a newcomer has to operate it. You know why the staging site has a different password. You know which of the two spreadsheets is the real one. You know that the plugin has to be updated in a particular order. None of that is written down, because none of it feels like information to you.

The test for any sentence in a handover: could somebody who joined the client’s team last week act on this without asking a question? If not, it is a reminder rather than documentation.

The eight sections

What this covers, and what it does not. First, so that a reader in a panic can tell in ten seconds whether they are in the right document.

Where everything lives. Every system, account, repository and file store, with its address and what it is for. One list, no prose.

How to run it. The routine operations, step by step: how to publish a change, how to add a user, how to take a backup, what to do at the annual renewal.

Credentials and ownership. Transferred, not shared. See the checklist below.

Decisions and why. The section that actually saves them. See below — it is the one part of a handover that cannot be reconstructed from the work itself.

Known issues and workarounds. Every rough edge you have been living with. Writing them down is not an admission; concealing them is what turns a rough edge into a betrayal in March.

What will need doing in three, six and twelve months. Certificate renewals, licence expiries, seasonal content, the version that will fall out of support. This is the section clients remember you for.

Who to call, and until when. Your support window, in dates, and what happens after it. An unbounded “just email me” is a commitment you will resent in a year.

The “why” section is the one that cannot be reconstructed

A competent newcomer can read your code, your designs, your spreadsheets. What they cannot recover is the reasoning: the obvious approach you rejected, and what happened when you tried it.

Three or four entries is plenty. Each one is three lines:

We host images on a separate service rather than in the CMS. The CMS was fine until the catalogue passed about 2,000 items, at which point the media library became unusable for the team. Moving back is possible but would reintroduce that.

Without that paragraph, the next person spends a week undoing your decision and a second week discovering why you made it. With it, you have bought the client a fortnight and yourself a reputation.

Ownership transfer: the checklist people get wrong

Sharing a password is not a handover. The client should own the accounts, so that removing you changes nothing. Work through this list explicitly, and record the date each item transferred:

The domain registration and the DNS, which are often at two different providers.

Hosting, and any account that bills — cards on file are the usual thing everybody forgets.

Repositories, and the ownership of the organisation that holds them, not just access to them.

Analytics, tag managers, ad accounts and search console properties.

Design source files, in an editable format, plus the fonts — and here is the classic omission: font and stock licences are frequently in your name and not transferable. Say so now rather than letting them discover it during a rebrand.

Any third-party service with an API key issued to you personally.

For each item, the document should say who owns it now, where the billing goes, and what happens when it renews.

What to cut

A narrative of the project. Nobody reading a handover cares how it went.

Screenshots of interfaces that will change. Describe the path in words; a stale screenshot is worse than none.

Thanks and pleasantries in the body. Put them in the covering email.

Anything you are only including so it looks thorough. Length is the enemy here — a handover is a reference document, and every unnecessary section makes the necessary ones harder to find.

This one is worth confirming landed

A handover has a real cost attached to not being read, and the cost lands on you: if the person who will operate the thing never opens it, you will be answering questions for free for a year.

So this is a document where the fact of an opening is genuinely actionable. If it has not been opened at all a fortnight after you sent it, do not conclude the client is disengaged — conclude that it went to the wrong person or arrived in the wrong week. What an unopened document actually means applies directly: the usual fix is to send it again, to a different named person, with a different first line.

And unlike almost every other client document, a handover should be findable later. Sending it as a durable link rather than an attachment means the version they find in March is the version you would want them to find, and Quixli can bundle a set of related documents into one collection with a table of contents so the operations guide and the credentials list are not two lost emails. Every share can also be ended at any time, which matters when your support window closes — the sharing controls are listed on the features page.