The worst handover I ever inherited arrived with a celebration email.
A project had gone live on time and under budget. There were photos. Six weeks later my team was carrying a system at 2am that none of us had seen before, with an alert that fired every night, no documented response, and a project manager who had already rolled onto something else. The budget code was closed. The people who built it were, organisationally speaking, gone.
Nobody had done anything wrong, exactly. Go-live had a date, and the date was met. What never happened was anyone accepting the service.
The handover is a gate, not a document Most transitions treat handover as paperwork produced near the end: a support model deck, a diagram, a distribution list. It is signed by people who are motivated to sign it, because the alternative is missing the date.
That makes acceptance a ceremony. A control is something that can stop the thing it governs, and if operations cannot delay a go-live, operations is not accepting anything — it is being notified.
So put the gate before the date, and make the criteria concrete enough to fail. Define done first: not “documentation complete”, but the specific list below, agreed while the project still has budget to fix what it is missing. A month before go-live is the last moment anyone has both the knowledge and the funding.
What operations should be allowed to refuse The list I have used, more or less unchanged, across three organisations:
A named owner on each side. A person, not a team mailbox. If the only answer is “platform engineering”, nobody owns it at 2am. Alerts that map to a documented response. Every alert that can page a human needs a runbook entry saying what to do about it. An alert with no response is a training exercise in ignoring alerts. Runbooks somebody has executed. Not reviewed — executed, by a person who had never done the task, while the builder watched and stayed quiet. Every hesitation is a defect, and it is cheap to fix in the room. Known defects and workarounds, written down. Every project has them. The question is whether they transfer as a list or as folklore. Access provisioned for the people who will actually be on call. Not the build team’s credentials. Test it by having on-call do a routine task unaided, before go-live. A support model with hours and an escalation path. Including who gets woken, and who decides to wake them. The capacity assumption, and what breaks first. Whoever built it knows. Ask what happens at three times the volume and write the answer down. None of this is exotic. It is all obtainable in the weeks before a launch and close to unobtainable in the weeks after, which is the whole argument for sequencing it as a gate.
Hypercare needs exit criteria, not an end date The usual compromise is a warranty period: the project team stays close for thirty days. Then day thirty arrives, the calendar invite stops, and whatever was still broken becomes operational debt.
Make the exit a measurement instead. The project team stays on the rota until incident volume for the new service is trending down and the last week produced no incident requiring the builders to be pulled in. If that takes sixty days, it took sixty days — and that number is the honest cost of the transition, which somebody should have to see.
It helps enormously to decide, in advance, whose budget pays for the overrun. Teams optimise for the date when the date is the only thing that costs them anything.
A go-live is an event. A service is a commitment somebody has to keep for years. If the people who will keep it were never given the standing to say “not yet”, you did not transition a service. You transferred a risk.