Software handover checklist: what you should receive at the end of a project

The software handover checklist

We recommend agreeing this list against the scope of your project before signing, then using it to check the transfer. It is practical guidance, not a universal legal requirement. In our own engagements, we agree the handover list at the start of each engagement. It normally covers the code, the deployment and access setup, and the documentation needed to run the system; the exact scope is set per project.

The receiving engineer should carry out the technical checks. As the buyer, you can name the receiving owners, ask for evidence and make sure unresolved items have an agreed next step. You do not need to restore a database yourself.

Copy the applicable rows into a working register. Give each a receiving owner, status and evidence link. Use verified, gap or not applicable, recording a reason for exclusions. Evidence might be the receiving engineer's build record, a recovery exercise result or a confirmed account-access check.

A document link tells us where to look; a completed check tells us whether the material works. Keep that distinction visible when reviewing progress, particularly where a missing permission prevents the receiving team from verifying an otherwise complete set of instructions.

What documentation is required at software handover?

The required documentation depends on the system, receiving team and agreement. We would organise it around four jobs: understand, change, operate and accept responsibility. An accurate index linking to maintained instructions can serve those jobs better than a single PDF that soon becomes outdated.

To understand, the next team needs architecture, data flows and decision records. To change, it needs setup, test and release instructions. To operate, it needs runbooks, monitoring and recovery guidance. To accept responsibility, it needs known gaps, contacts, support boundaries and references to the relevant agreement.

Use this copyable software handover document skeleton as the index:

Project and release
- Project:
- Version/release and environment:
- Document owner and last verified date:

Deliverables register
- Item / location / receiving owner:
- Access checked / verification evidence / status:

Accounts and services
- Service / administrator / billing owner:
- Secure-vault reference / recovery route:

Known issues and unfinished work
- Issue / impact / workaround:
- Owner / agreed action:

Operational responsibility
- Operating owner / support boundary:
- Escalation contacts:

Acceptance record
- Checks completed and evidence:
- Exceptions / next steps / agreed by:

Keep passwords, keys and other secret values out of this document. Reference the approved secure store and verify that the receiving person can use it. Record what was actually checked, against which release and environment. When a document changes during the transfer, update its verification record so the next team can distinguish current instructions from material awaiting review.

What is a runbook, and what should yours contain?

A runbook is a set of instructions for a specific operating task or failure, written so the responsible person can carry it out and check the result. Architecture explains how the system fits together; a runbook guides an action when something needs attention.

We recommend recording the trigger, responsible role, required access, safe checks, action steps, expected result, stop and escalation conditions, recovery or rollback, and last-tested date.

Hypothetical example: a background processing queue stops moving. A queue holds work waiting to be processed; a worker carries it out.

1. The designated receiving operator receives the queue alert and opens the monitoring dashboard.
2. They check queue age, worker health and dependency status. Healthy workers waiting on an unavailable external service need a different response from stopped workers.
3. They collect relevant logs, affected job identifiers and recent deployment details before changing anything.
4. If the checks identify a worker problem and the documented procedure authorises a restart, they follow it. Otherwise, they stop and escalate to the named responsible role.
5. They confirm that processing resumes and check affected outputs. If progress does not resume, errors persist or data effects are unclear, they stop and escalate.

The real runbook needs the system's exact checks, permissions and recovery steps. Never blindly replay jobs that may already have made changes. AI systems also need procedures for the quality, cost and provider problems below.

What changes when the system includes AI?

AI adds material to the same checklist. We recommend agreeing prompt and model configuration records, approval rules, fallback paths, data sources and permissions, approved provider arrangements, and retrieval or index-refresh procedures where applicable. Include quality, cost and failure dashboards and instructions for evaluating and releasing changes.

Our applied AI deliverables describe the evaluation set and results precisely: “Your real cases with agreed answers, the checker that scores them and the results, so any later change can be measured the same way.” The published runbook description is: “What to do when quality drops, costs rise, a provider fails or a model needs to change.”

Those are specific published AI commitments; the additional configuration and data-flow checks above are buyer guidance to agree for the assignment. For wider context, see the checks before an AI workflow enters production and why a working demonstration still needs engineering checks.

Changing your software development partner mid-project: what to secure first

When switching software development company, we would work through the following sequence. The aim is to preserve continuity and establish a truthful account of what remains. A cooperative walkthrough with both teams can help where the agreement allows it.

1. Check the agreement and name a transition owner. Confirm notice and termination terms, permitted access and sharing, assistance obligations, payment dependencies and support dates. Ask a qualified adviser about unclear or disputed terms. Give one person responsibility for coordinating the transfer and recording decisions, with technical owners handling the engineering checks.
2. Secure authorised access and recovery routes. Confirm organisational administrators, billing, domain and DNS, code and cloud access. Obtain the agreed repositories, history and authorised backups. Check secrets through the secure process and keep a written inventory of gaps. If access is disputed, resolve authority and contract terms before proceeding; do not bypass permissions.
3. Establish the current baseline. Identify what is deployed, which code produced it, what works and what remains unfinished. Record defects, outstanding branches, integrations, known risks and upcoming renewals. Distinguish work demonstrated from work running in production. A mid-project handover needs to say clearly when something is not done, including any assumptions the next team must revisit.
4. Let the incoming team verify before committing to the next plan. Ask it to build and test what exists, review the deployment path and compare progress claims with evidence. Repository access alone is not a technical assessment. Changing suppliers does not automatically require a rewrite; the next plan should follow the findings, with uncertainties made visible before commitments are agreed.
5. Agree the cutover and support boundary. Specify who handles incidents and releases during overlap, any justified change freeze, escalation, fallbacks and the acceptance record. Confirm receiving access and service continuity before revoking outgoing access. Rotate shared credentials in a controlled way, accounting for service accounts and release pipelines that depend on them. Record who checks that these changes have succeeded.

Keep this sequence aligned with the agreement. Transition assistance, support overlap and the end of access need explicit arrangements rather than assumptions about what either supplier will provide. In our engagements, notice, overlap support, data retention and access removal are agreed contract by contract; we do not state standard periods.

Check ownership and licences before calling the handover complete

Check what your contract says about ownership and licences, and get it in writing.

We separate three questions: what code is delivered, what rights apply and who controls the operational accounts. Repository access or a paid invoice does not, by itself, answer them all.

Ask about assignment or licence, pre-existing components, open-source dependencies, restrictions on modification and incoming-supplier access, and payment or termination conditions. Our questions to ask before choosing a partner include this position: “who owns the code is agreed in the contract for each engagement, so ask any partner, including us, to put it in writing.” The access a new supplier receives is likewise agreed with the client.

For AI-assisted code, prompting, paying a provider or receiving generated files does not settle every copyright question. Ask for the contractual position and review relevant licence and provider terms. Refer unresolved questions to a qualified adviser who can consider the applicable jurisdiction and circumstances.

Our Cloud and delivery service covers release pipelines, infrastructure and operating runbooks within an agreed scope.

Rehearse the handover with the people who will run it

A walkthrough introduces the system. We recommend a receiving-team rehearsal to check whether the instructions and access are sufficient: build, deploy, inspect an alert and practise recovery in a safe environment, proportionate to the system's risk and scope.

Record gaps and material exceptions before acceptance, with owners and agreed actions. Confirm who handles incidents afterwards and which further assistance is included or separately agreed. Checklist completion should inform acceptance alongside the contract's milestones and requirements.

APM's guidance on successful project handover supports planning early and preparing operating knowledge for the people receiving it.

This connects to how we deliver and transfer a system: “Deploy, document decisions and leave the team with a system it can operate confidently.” Our published AI handover commitment is: “A walkthrough with the people who will run the system, so it does not depend on us.” We provide a walkthrough for the team taking over; any recordings, training or ongoing support are agreed per project.

Questions