How do you hand a project over to support?
Handover transfers the running of the system to the team that will own it: run documentation, known errors and workarounds, access and accounts, monitoring and alert routing, the support model with severity definitions and escalation, training and shadowing, and a signed acceptance from the service owner. It is planned during delivery, not arranged in the final week.
Handover is a workstream, not an event
The version that fails is the one where a meeting is booked for the week after go-live, a folder of documents is shared, and the project team leaves. Support then learns the system from incidents, which is the slowest and most expensive way to learn anything.
The version that works starts months earlier. The receiving team is identified during delivery, sees the design, attends the dry runs, and is on shift during the cutover window. By the time formal acceptance happens, the handover is a confirmation of something already true rather than a transfer of the unknown.
Who the handover is to
Naming the receiving party sounds trivial and often is not. Applications support, infrastructure, the service desk, a third-party managed service and the business process owners may each take a share. Each part of the system needs one named owner, and where a supplier holds part of it, the contract has to already say so. Discovering during handover that nobody is contracted to support an interface is a common and awkward finding.
What actually transfers
| Item | What good looks like |
|---|---|
| Run documentation | Scheduled jobs, dependencies, restart procedures, what to do when a nightly run fails |
| Architecture and interfaces | What connects to what, in what direction, with which credentials and which failure modes |
| Known errors and workarounds | Every workaround issued during testing and hypercare, in a searchable form |
| Access and accounts | Permissions provisioned and tested by the people who will use them, not borrowed from the project |
| Monitoring and alerts | Routed to the team that will act on them, with thresholds agreed and a named recipient |
| Support model | Severity definitions, response expectations, hours of cover, escalation path with names |
| Open defects | Transferred list with owners, target dates and the route to closure |
| Contracts and licences | Support contracts live, renewal dates known, licences on the right cost centre |
| Business process documentation | What users were trained on, so support answers match what people were told |
The two items most often missing on the day are access and alert routing. Both are easy to arrange in advance and both are discovered at the worst moment: an alert firing into an unread project mailbox, or a support engineer unable to look at the system they have just been given.
Knowledge transfer that is tested
Documents alone do not transfer knowledge. What works is people doing the work while the project team is still there to correct them: shadowing during testing, support taking triage during hypercare with the project available behind them, and a deliberate reversal partway through where support leads and the project observes.
That reversal is the measurement. The proportion of tickets support resolves without escalating is a better indicator of readiness than any number of handover sessions, and it is one of the standard hypercare exit criteria. Where the number is not moving, the gap is usually specific — one subsystem, one type of incident — and can be addressed while there is still time.
Where handover sits in the timeline
The support model is agreed before go-live, because it is one of the criteria on the Go/No-Go Checklist: a system going live without a defined severity scale and escalation path produces its first incident with no route to resolve it. Documentation and access are ready before the window. Shadowing runs through hypercare. Formal acceptance happens at hypercare exit, and the record of it goes into the closure report.
Acceptance
Handover ends with the service owner signing, and a signature means they have checked something rather than received something. The checklist behind it is short and specific: documentation reviewed and found usable, access tested, monitoring confirmed firing to the right place, open defects accepted with owners and dates, support contracts live, and the team confident enough to take the next incident unaided.
Where a condition is not met, it is accepted with a mitigation and a date rather than waved through. An acceptance signed over unresolved gaps transfers the paperwork and leaves the problem with the project anyway, usually as an informal call to someone's mobile three weeks later.
After the signature
A short review some weeks after acceptance is worth scheduling: what support has actually had to escalate, which documentation turned out to be wrong, which alerts were noise. It costs an hour and it corrects the handover while the project team can still be reached. The outcome belongs in the Project Closure Report, alongside the lessons that come out of it, and the fuller structure is covered in the project closure guide.
Questions
When does handover start?
During delivery. The receiving team should see the design, attend dry runs and be present at cutover, so acceptance confirms familiarity rather than creating it.
Is handover the same as hypercare exit?
They overlap. Hypercare exit tests whether the service can run without the project; handover is the transfer of documentation, access, monitoring and accountability that makes that possible.
What if support will not accept the service?
Their objection is usually specific — missing documentation, unresolved defects, no access, no contract. It is treated as a list to close rather than a signature to chase.
Who owns open defects after handover?
Whoever the transferred list names, with a target date against each. Defects handed over without an owner return to the project informally.