Software Handover: A Checklist for Acceptance, Not Just Delivery

UDT Insights

From UDT’s knowledge archive: source document created in 2023, updated August 2026. Newly edited for publication.

A demonstration is not the whole handover

A supplier demonstrates the feature. The screens look correct, but the receiving team still cannot answer basic questions. Which version did we review? What remains incomplete? Who handles a problem after release?

Treat handover as a set of decisions supported by evidence. Use this checklist to agree on responsibilities with your delivery partner. Adapt it to your product and working arrangements.

Separate three decisions

Code completion means the implementation is ready for its next check. Acceptance records whether the delivered behavior meets agreed criteria. Operational handover confirms that the receiving team knows how to use, support, and maintain the accepted version.

These decisions can happen at different times. A demonstration does not replace acceptance, and acceptance does not automatically authorize a production release.

The Scrum Guide describes the Definition of Done as the quality standard for an Increment.[1] Keep that shared quality standard distinct from feature-specific acceptance criteria. Neither removes the need to agree who accepts the delivery.

Prepare a compact acceptance pack

Keep the pack close to the release record. Link to evidence rather than copying entire reports into several places.

• Scope and criteria: identify included behavior, exclusions, and observable conditions for acceptance.
• Version and evidence: identify the reviewed build, test environment, test results, and unresolved defects.
• Review and decision: name the accepting role, record the decision, and explain each unmet criterion.
• Limitations and guidance: provide release notes, known limitations, and instructions for the intended users.
• Operational readiness: agree on deployment checks, recovery arrangements, and any required data-change review.
• Ownership: identify the receiving owner, support route, open actions, and the next review.

A hypothetical example: a booking form

This is a hypothetical example, not a UDT client case. A team delivers a room-booking form for an office.

Before review, the teams agree that users can reserve an available room and receive a clear message for conflicting bookings. The acceptance pack identifies the exact build and includes evidence for both cases.

The reviewer finds that a conflicting booking shows a blank screen. The team records the failed criterion and assigns a correction. A successful demonstration of an available room does not cancel that finding.

After the correction, the reviewer checks the new build and records the decision. The receiving owner then checks the user guide and support route. Production release remains a separate, explicitly authorized step.

A four-step handover flow

Use this sequence to make the next decision visible.

• Agree: define scope, acceptance criteria, and the receiving role.
• Inspect: review the identified version and its supporting evidence.
• Decide: record acceptance or corrections with an accountable owner.
• Transfer: confirm guidance, release responsibilities, and follow-up actions.

Do not hide uncertainty behind a signature

An acceptance record should say what the reviewer checked. If a limitation remains, record its effect and the agreed treatment. Do not present an unresolved issue as an unconditional pass.

Keep the record current after changes. New behavior needs new criteria and evidence, not a reused approval. Start with one release and ask whether another person can understand the decision without a private explanation.