30 June 20267 min read
Every engagement ends. Some end because the work is finished, some because the capability is being brought in-house, some because it stopped working, and a few because the person you liked took a different job. The reason varies. The ending does not.
Despite that, handover is almost always improvised in the final fortnight, by people who have already mentally left, under a deadline, with no budget attached to it. The result is a folder of documents that answer questions nobody was going to ask and omit the three things that actually mattered.
Handover starts on day one
The teams that hand over well do not have a better final fortnight. They have a different first month. They set up the engagement so that the knowledge was never solely in anyone's head, which means the handover consists mostly of pointing at things that already exist.
The practical version: decisions are written where the work lives, architecture notes sit next to the code they describe, and no service, account or deployment path has exactly one person who understands it. None of that is handover work. It is ordinary practice that happens to make handover nearly free.
This is also the argument for insisting from the start that the repository, the cloud accounts, the domain and the CI configuration are yours, with the partner working inside them. It sounds like a trust question. It is not. It is the difference between a handover and a migration.
What actually has to transfer
Not the code. The code transfers itself; it is in the repository and it says what it does. What does not transfer is everything that explains it.
- Why the system is shaped the way it is, including the constraints that no longer exist but still explain the design.
- The failure modes: what breaks, how you can tell, and what the fix usually is.
- The operational knowledge: how to deploy, how to roll back, what to do when the nightly job fails, which alert can be ignored and which cannot.
- The relationships and dependencies outside the code: which third party is unreliable, whose approval is needed for a schema change, which client cannot tolerate downtime on a Monday.
- The unfinished business: what was deliberately left, what was left because of time, and what is known to be wrong but not yet worth fixing.
That last category is the one that gets omitted, because writing it down feels like an admission. It is the most valuable page in the whole handover.
Documentation written by the wrong person is useless
The person who built a system cannot see what is confusing about it. Ask them to document it and you will get an accurate description that answers none of the questions a newcomer has, because those questions never occurred to them.
A better mechanism: have the receiving person write the documentation, by working through the system and asking, with the departing person correcting rather than authoring. It is slower, it feels inefficient, and it produces documentation that is aimed at the right reader, plus a receiver who has actually engaged rather than filed a document away.
The overlap period is the whole thing
Handover by document does not work on its own. What works is a period, two to four weeks for a system of ordinary size, where both people are being paid and the incoming person is doing the work while the outgoing person is available to answer.
The sequencing that works: the receiver takes real tickets, not exercises, starting with something small and ending with something that touches the frightening part of the system. The departing person is on call for questions and reviews the work, but does not do it. If a production incident happens during the period, the receiver handles it with the other person watching. Nothing else produces the same confidence.
This period costs real money, since you are paying twice for the same coverage. It is cheaper than the alternative by a wide margin, and it is the line most often cut from a transition budget by someone who has never run a bad handover.
The boring parts, done early
Access, ownership and paperwork are not interesting and they are where handovers actually get stuck. Confirm that IP assignment covers everything delivered including work by any subcontractor, that the data processing agreement is closed out properly and personal data is deleted where it should be, and that no production account, certificate, domain or third party integration is registered to an individual who is leaving.
The account registered to someone's personal email address is the classic one. It is discovered eleven months later, when the certificate expires on a Sunday and the only person who can renew it has not worked with you since spring.
Handover as a habit, not an event
The most reliable protection is to make small handovers routine while nothing is ending. Rotate who owns which area every few months. Have someone other than the author walk through a system in a team session occasionally. Treat any component with exactly one person who understands it as a risk on a list, not as a fact of life.
A team that does this has already run the transfer a dozen times before it matters. A team that does not is relying on a fortnight at the end, arranged by people who are already thinking about something else, which is the arrangement it is worth spending a paragraph in the statement of work to avoid.