The Handover Ledger: What Buyers Should Require Before a Supplier Declares Completion

Contractual completion and operational delivery are not the same event. A supplier can satisfy the acceptance criteria in a statement of work and still leave the buyer with a service that is fragile, undocumented or more expensive to run than the business case assumed. The distinction matters most after the vendor's key people have left the distribution list.

For UK organisations, the handover gap is rarely one dramatic failure. It is a sequence of small omissions that accumulate: a process step known to one contractor, a defect parked as a known issue, a licence renewal nobody has diarised, an escalation route that exists only in a slide deck. Individually they look manageable. Collectively they transfer cost and risk to the receiving team.

Completion Is a Contract Event, Not an Operating State

Contract acceptance asks whether the supplier has delivered what was specified. Operational readiness asks whether the buyer can run, support, change and assure the service without leaning on the supplier. Those questions overlap, but they are not identical. A signature that confirms the former should not be treated as proof of the latter.

The practical consequence is that the receiving team inherits two jobs at once. It must absorb knowledge that was never properly transferred, and it must stabilise a service that may still be carrying unresolved defects. When the supplier's commercial incentive to fix those defects ends at contract close, the buyer's leverage falls sharply.

Where the Gap Opens

The gap usually appears in four places. First, knowledge: process maps may describe the happy path but not the exceptions, workarounds and informal checks that keep the service running. Second, defects: items may be logged but not owned, priced or scheduled, leaving the receiving team to manage them as business as usual. Third, access and data: administrative rights, service accounts, data maps and retention obligations are often transferred late or incompletely. Fourth, commercial tail: support boundaries, licence renewals, warranty conditions and third-party dependencies can create costs that were never visible in the project budget.

None of these are exotic. They are ordinary transition risks. They become expensive when handover is treated as a meeting rather than a managed gate.

A Practical Handover Ledger

A handover ledger gives both sides a single evidence base. It should be agreed before completion is claimed, not assembled afterwards.

• A named receiving owner and a named supplier exit owner, with authority to accept or reject handover evidence.
• Process documentation that covers triggers, inputs, exception routes and the informal workarounds that currently keep the service alive.
• A roles and responsibilities map for the first 90 days, including out-of-hours cover and escalation paths.
• A defect register showing severity, owner, agreed fix date, workaround, cost and acceptance status.
• An asset and licence schedule with renewal dates, ownership and transfer conditions.
• Access transfer evidence covering administrator rights, service accounts, credentials and the removal of supplier access.
• A data map covering location, retention, deletion and any regulatory obligations.
• A support model that states hours, response times, boundaries and what falls outside the contract.
• Training evidence that demonstrates competence, not merely attendance.
• A list of known risks and unresolved decisions, each with an owner and a review date.

The ledger should be reviewed in a formal operational readiness gate. That gate is distinct from contract acceptance. It asks whether the receiving organisation can operate the service, not whether the supplier has met a specification.

Questions to Ask Before the Vendor Walks Away

The most useful questions are specific and evidence-based. Who fixes what after day one, and at whose cost? Which defects are being accepted, by whom, and on what basis? Which processes are undocumented, and who will be shadowed before exit? What happens when the documented process fails? Which licences transfer, and which must be renegotiated? What supplier access will be removed, and when? What support remains in the first 30 days, and how is it triggered? What evidence shows that the receiving team can run the service without the supplier? What happens if the supplier's key person leaves before handover is complete?

These questions are not adversarial. They are the minimum basis for a credible transition.

Making Handover a Gated Decision

Handover should end with an explicit decision: ready, ready with conditions, or not ready. Conditions should be time-bound, owned and evidenced. Final acceptance should depend on the operational readiness gate, not only on contractual completion. That may require commercial and legal teams to agree the mechanism early, but the principle is simple: payment and sign-off should follow evidence of operational capability.

Clearer delivery, done properly, means recognising that the supplier's departure is part of the delivery. A service is not delivered when the contract says so. It is delivered when the receiving team can run it, support it and improve it without inheriting a hidden backlog of risk.