At the end of an engagement there is an appointment in the calendar, and it is called the handover. There is a presentation, a document, maybe a recording, and after that the thing counts as handed over. Six weeks later somebody calls because a nightly job is stuck and nobody knows where it starts.
The mistake sits in the form. A handover is not an appointment, it is a state, and that state can be tested. Skip the test and you find out whether the handover worked at the point where it is too late to repeat it.
This article describes the test that counts, the order that comes before it, and the place where it almost always gets stuck, which has nothing to do with knowledge.
The only test that counts
There is exactly one check that says anything, and it is uncomfortable because it cannot be passed by being well prepared.
The team takes a real, small change to production without the external person in the room. Not in a test environment, not with somebody on the phone, not with a script written together beforehand. From ticket to running production, alone.
Everything else is preparation for that check. A hundred-page document says nothing about whether it will be passed, and a presentation only says that somebody listened.
The timing matters as much as the check itself: not on the last day. It belongs four to six weeks before the end, because its actual purpose is to show the gaps while there is still time to close them. A handover checked on the last day is not checked, it is confirmed.
The place it gets stuck is not the knowledge
Handovers get discussed in terms of documentation, and the problem sits elsewhere. In most cases a personal account is in the way somewhere, and it only surfaces when it is needed.
The list is always similar and longer than expected. The domain is registered in the external person's name. The certificate renews through their account. The two-factor sign-in for the payment provider lives on their phone. The credentials for the package registry publishing the internal libraries belong to them. Monitoring alerts go to their address. The key for the deployment server is in their password manager, and the account with the error reporting provider runs on their private address because that was quicker three years ago.
Every single one of those is an afternoon's work now and a week of support tickets after the engagement ends. Which is why this inventory does not sit at the end of the handover but at the beginning: access first, knowledge after.
The way to test it is simple and rarely done: the external person disables their own access for a day. Whatever gets stuck is the list, and it is more honest than any account from memory.
Why the knowledge sits in one person at all, and what that costs, is covered in Knowledge in one person is an architecture problem.
What gets handed over, in what order
After access comes the rest, and the order follows the question of what gets needed first when something happens.
The path from a change to production. How does a line of code get onto the server, how do you see whether it worked, and how do you take it back? That comes first, because it is the only thing actually needed in the first days.
The three things that happen at night. Every system has two to four recurring faults. The import hangs, the queue fills up, the partner does not answer. One page of runbook for each: how you recognize it, what you do, when you escalate. That is the most valuable page of documentation in the whole engagement.
The decisions. Not the architecture, that is in the code. Rather why things are as they are: why there are two tables for almost the same thing, why billing behaves differently on Mondays, why this library was not upgraded. That is the knowledge written down nowhere else, and it belongs in short dated notes, not in a manual.
The rest. Anything that can be read out of the code does not get transcribed. A diagram of the class structure is out of date the day after it is drawn and replaces no half hour of reading code together.
The weeks before: swap the roles
The transition does not succeed through explaining more at the end. It succeeds through doing less beforehand.
So the last four to six weeks belong to an inverted arrangement: the team writes the code, the external person reads it. Every change still outstanding gets implemented by somebody who is staying, and the external person sits next to them and answers the questions that come up.
That is uncomfortable because it is slower, and it is the only route that reliably works. Questions arising from reading documentation are harmless. Questions arising from changing real code are the right ones, and they only come when somebody changes real code.
A side effect of those weeks is the most honest progress report available: if the questions have not thinned out by the third week, the handover is not on track, and you still know it in time.
The day itself
If the preceding is right, the handover day is unspectacular, and that is the goal. It consists of three things.
A list that gets ticked off. Access transferred, personal accounts removed, alerts redirected, keys rotated, invoices moved to the company. Point by point, together, not by email.
A named owner. From today one person on the team is responsible for this system, by name. Without that, responsibility spreads across everybody, which means nobody.
A deadline instead of an open door. "Just call if anything comes up" sounds generous and is the worst part of many handovers: it keeps the dependency alive without settling it. Better is a clear arrangement: reachable for questions for four weeks, after that on request and billed. That is not a withdrawal, it is the difference between a run-off and a permanent state.
The things that happen at night almost always include a restore: Backups nobody has ever restored.
When it is not enough
Finally the case that rarely gets said out loud: sometimes the handover cannot be achieved by the agreed date. The team is too small, the knowledge too concentrated, or something came up.
The only useful response then is to say so early, with a concrete proposal: what is reachable by the date, what stays open after it, and which two or three things would have to be closed first. A handover that took place on paper costs more than one postponed by six weeks, and the difference shows up at the first incident.
The measure for it is the same as for any other work on a grown system: not how much was explained, but what the team can do alone afterwards. How I work on systems like these is described on its own page.
This article belongs to a series about systems that already exist. The retrospective orders every article in it by situation.
