01
Related
Where to read next on the same subject.
02
Short answer
A production handover transfers three bundles: the decisions and records that explain why the system is shaped as it is, the operating equipment a team needs to run it, and the open items the builders chose not to finish. Ownership moves item by item, with a named receiver for each row. The transfer is complete when the receiving team resolves one real incident without calling the builders.
I inherited a platform once where the handover had been a two-hour call and a link to a wiki. The call was pleasant. The wiki was thorough about what the system did and silent about why. Three weeks later a queue backed up on a Friday evening, and the fix was obvious to nobody, because the reason a particular retry threshold sat at seven minutes lived in the head of an engineer who had already left. We spent the weekend reverse-engineering a decision that would have been one paragraph in a proper handover.
That weekend is my template for what a handover must prevent. The goal is a team that can answer "why is it this way" without a seance.
03
The three bundles
Decisions and records come first, because they are the part that decays fastest and re-slowest. The architecture decisions carry their reasons, including the options that were rejected and why, because the receiving team will revisit them and deserves the original argument. The accepted limits and known defects carry their evidence, so nobody rediscovers them as fresh bugs. Exception rules carry their owner, scope, and expiry, because a permanent exception is a requirement in hiding. The acceptance results and sign-offs carry the data they were measured against. The change history for data definitions carries dates, so a March report can be explained in March terms.
Operating equipment comes second, and it is the bundle teams usually mean when they say handover. Runbooks for the top five failures, written the way the on-call person will read them at 3 a.m., with the symptom first and the theory later. Monitoring with thresholds, paging routes, and the response each alert expects. Access in the most literal sense: secrets, service accounts, rotation schedules, and who holds the administrative keys after the builders stop. The test suite, with the command that runs it and the meaning of a failure in each suite. The release and rollback procedure, rehearsed once with the receiving team driving.
Open items come third, and omitting them is the move that turns a handover into a trap. The risks the builders know about, with likelihood and named watchers. The backlog they chose to defer, with the reasoning, so the receiving team can re-judge those calls with fresh eyes. The dependencies outside the team: the upstream feed that slips, the vendor endpoint that rate-limits, the one person on the customer side who understands the legacy contract. The platform cost baseline, so the first bill that looks strange can be compared against something.
04
Move ownership row by row
A handover without a receiver per item is a shipment without an address. Every row in the three bundles gets a named person on the receiving side, and the transfer session walks the list until each name is confirmed. Where nobody wants an item, that is information: either the item is unnecessary and can be retired in the open, or the team is at capacity and the gap needs a decision above the handover.
The sessions have a shape. Before: artifacts staged, owners drafted, two walkthroughs booked, one on call and release and one on the data definitions. During: access switched with dates, the receiving team leading the on-call shadow while builders sit behind, every page a named face and a spoken reasoning. After: a thirty-day window where the builders answer questions but take no actions, and the first solo incident gets written back into the runbook as the closing entry.
05
The test that ends it
Handover finishes on an event, not a date. The receiving team resolves one real production incident alone: they page themselves, they read the runbook, they find the decision record, they fix or fail over, and they write the postmortem. The builders may read the postmortem. They may not touch the system.
If the incident surfaces a missing bundle, the handover reopens for that item and the clock restarts. That sounds strict, and it is cheaper than the alternative, which is discovering the gap during the next real incident with the builders already gone.
Teams sometimes ask whether the test is unfair to small systems. It scales down honestly: for a modest pipeline, the incident might be a failed load, the runbook half a page, the whole transfer a day of sessions. The standard is not the size. The standard is that nobody needed to call the builder.
06
What the record looks like afterward
A year later, the handover should be findable. The decision records let a new engineer trace any threshold to the meeting that set it. The runbooks carry the postmortems of the incidents that have happened since. The open-items list shows its own aging, with risks that were retired and ones that grew. That document is the difference between a team that owns a system and a team that hosts one.
07
Preparing the receiving team
The bundles mean nothing without people ready to hold them, and readiness is built during the engagement rather than announced at the end. The strongest pattern I have worked with pairs one senior and one junior receiver from the start: the senior joins the design reviews from the first month and learns the decisions as they are made, and the junior runs the test suite and the staging environment so the operating equipment is familiar by touch, not by description.
Practice incidents come before real ones. Once the monitoring is live, the builders run a game day with the receiving team: break a feed in staging, page the on-call, and walk the runbook as if it were 3 a.m. The first rehearsal always finds something, usually a runbook that says "restart the service" without saying which environment holds the credentials, or an alert with no documented response. Finding those in a rehearsal costs an afternoon. Finding them in production costs a night.
Documentation written by builders for receivers needs a different editor than documentation written for builders. Have the receiving team write the first draft of one runbook from a working session, then correct it. The corrections show exactly where the builders' knowledge is tacit, and those gaps become the walkthrough agenda. A handover document nobody on the receiving side has edited is a document written in the wrong language.
Finally, plan the fade-out. The thirty-day questions window works when it is scheduled in the receiving team's calendar from the start, with the builders' availability stated plainly. The alternative, an open-ended "just ask us," decays in both directions: the receiving team stops asking too soon, and the builders stop answering too politely, and the questions that mattered go unasked.
08
Related
The forward-deployed model explains who builds and who receives. The shared-ownership guide describes the record both teams keep during the engagement. The PeopleStrong migration shows the transfer at platform scale.