Handover is a deliverable, not an event

The handover meeting is usually the same everywhere. Ninety minutes, a deck of twenty slides, three people from the receiving side who have not seen the system before, and one who has and is on leave the following week. Everyone nods. The plan says handover is complete. Four months later a question arrives that the deck cannot answer, and it arrives at somebody who has since moved to a different account.

Treating handover as a meeting is the root of it. A handover is a deliverable. It has contents, acceptance criteria and a date on which it is proven, and it belongs in the plan with the same weight as a release. If it appears on a schedule as a single afternoon in the final week, it has already failed and the failure is simply not visible yet.

What is actually in it

The contents are unglamorous and mostly consist of things the outgoing team stopped noticing years ago.

• Access, proven by the receiving team logging in themselves. Every environment, the repository, the pipeline, the monitoring, the cloud accounts, the vendor portals nobody remembers subscribing to.
• The runbook, written during the build and used at least once in anger, covering restart, failover, restore and the three failures that actually occur.
• A build and release path executed from a clean machine by somebody who has never done it, with the instructions corrected as they go.
• The dependency and licence inventory, including renewal dates and who inside the client organisation owns each contract.
• The escalation path with names, hours and what each contact is actually able to do at three in the morning.
• The known-defect list, including the defects we chose not to fix and the reasoning at the time.
• The decision record, so the receiving team learns which obvious improvements were already considered and rejected, and why.

The known-defect list is the one clients find surprising and the one that saves the most time. A list of things deliberately left broken, with reasons, prevents a new team spending its first quarter fixing something that was a considered trade rather than an oversight.

How to test it

A handover is tested the way anything else is tested: the receiving team performs real operations while the outgoing team sits behind them and does not touch the keyboard. That last clause is the entire method. The instinct to lean over and type is very strong, and giving in to it converts a test back into a demonstration.

Four exercises cover most of the risk. Deploy a trivial but real change to production. Restore the most recent backup into a test environment and confirm the data is usable rather than merely present. Work a simulated incident from alert through to resolution using only the runbook. Onboard one person who was not in any of the earlier sessions, using only what has been written down, and time it. Whatever those exercises expose gets fixed, and then they are run again.

The date of the handover is the date the receiving team completed those unaided. Not the date of the meeting, and not the date the documents were delivered.

The failure mode we have to watch in ourselves

We stay on most of what we build, often for years, so the pressure to run a real handover is weaker for us than for a firm that leaves at go-live. That produces its own failure: we hand the system over to ourselves, informally, one conversation at a time, and nothing gets written down because everyone involved already knows. Then a rotation happens, and the new engineer discovers that the operational knowledge lives in a chat history from a Tuesday two years ago.

We have made that mistake, more than once, and the correction was to run the same handover exercise internally at rotation points regardless of whether the client is receiving anything. It is unpopular for about a day. It is also the cheapest way to find out which parts of a system only function because one person remembers something, which is a question worth answering while that person still works here.