A software handover should let the responsible team run, maintain, and change the application. Receiving source code alone does not establish that they can do those things.
Agree the handover scope when commissioning the work. Use this checklist to identify deliverables and owners, then verify them together before closing the assignment.
Source code and project history
Confirm access to the repository and identify the version being handed over. Include the application code, database changes, and configuration templates required for the agreed scope.
Record known limitations, incomplete work, and external dependencies. Ask where architecture decisions are documented and which parts are most likely to need attention when requirements change.
Repository access and legal ownership are separate questions. Record the agreed rights and any third-party license constraints in the project documentation and agreement.
Accounts and access
List the services needed to operate the application: hosting, domain management, databases, email delivery, and connected APIs where relevant.
For each service, identify the account owner, billing contact, administrator, and recovery method. Confirm that the business can retain access when the delivery assignment ends.
Use an agreed secure method for transferring secrets. Configuration documentation should name the required values and explain where to obtain them, without putting passwords or tokens in a public repository or ordinary handover document.
Setup and release instructions
Ask the receiving engineer to follow the setup instructions in an appropriate test environment. They should be able to identify the required runtime, install dependencies, configure the application, and run the agreed checks.
Document how a release is made and what to check afterwards. Where a change alters data, include the planned recovery approach and any limits on reversing it. A command that deploys code is not by itself a complete recovery plan.
Capture missing steps during this exercise. Correct the instructions while the delivering team is available to explain them.
Data and integrations
Identify where business records live, which system owns each shared field, and how information moves between applications.
For each connection, record the relevant API documentation, permissions, expected delay, and the person responsible when it fails. Explain how to find incomplete transfers and how approved corrections are applied.
Agree backup responsibilities and how restoration will be checked. Record what is covered, where recovery instructions live, and any unresolved gaps. Do not treat the existence of a backup setting as proof that restoration has been verified.
Tests and acceptance
Keep the agreed acceptance criteria alongside the results. The recipient should know which checks are automated, how to run them, and which require a person.
For a customer portal, useful acceptance questions include:
- Can a customer complete the agreed request workflow?
- Can a customer access only the records they are permitted to see?
- Is a rejected or incomplete request handled as specified?
- What happens when a connected system is unavailable?
- Can the responsible person identify and resolve the failed operation?
These are illustrative questions. Select the checks that match the actual application and record anything that remains unverified.
Support and future changes
Name the person who receives incident reports and the person who can make a release. Agree what the initial supplier handles after handover and what requires a new assignment.
Distinguish defects against the accepted scope from new requirements. If support hours or response times are needed, put the agreed commitment in the support arrangement. Completion of development does not automatically create ongoing support coverage.
For agency projects, also decide who communicates with the end client. Our white-label briefing guide explains those delivery boundaries.
A practical handover rehearsal
This is a hypothetical exercise for a business application, not a report of client work.
Ask the receiving engineer to set up the application in a test environment, run the checks, and make a small agreed change. Then have the person responsible for operations locate a failed test transfer and follow the documented recovery steps.
Record gaps as specific actions with an owner. Decide which gaps prevent acceptance and which can be accepted with a documented follow-up. A successful rehearsal gives both sides something observable to review.
Checklist you can use
Download the editable software handover checklist. It has fields for each deliverable, its owner, and the evidence that it was checked.
Use it during scoping as well as at the end. Handover affects the work included in a software development estimate and should be visible before the quote is agreed.
Put it into practice.
Explore our custom software development service or send us the problem you are working on.