Software handover: what you should receive.
A complete software handover lets you operate the product and bring in another developer. It includes the source, account access, build and deployment instructions, data responsibilities and known limitations. A ZIP file alone is not a handover.
Use the free worksheetAsk for evidence, not just a folder.
Use three outcomes for each handover check: passed, failed or unverified. Unverified means there is still a decision to make. For a restore or deployment exercise, use an isolated environment and agreed test data so the check does not change the live product.
| Material received | Acceptance exercise | Record as incomplete when |
|---|---|---|
| Source and setup notes | A new developer builds the named revision from a fresh environment. | An undocumented local file or inaccessible service is required. |
| Account inventory | The nominated owner can access the services and see billing responsibility. | A necessary account still belongs only to the outgoing developer. |
| Deployment notes | Deploy the agreed version to staging and rehearse the documented rollback. | The procedure omits a data change that prevents rollback. |
| Backup and restore notes | Restore an agreed backup to an isolated environment and inspect sample records. | A backup exists, but no one has demonstrated that it can be restored. |
| Known limitations | Review open issues and assign an owner to each remaining item. | A failed check has disappeared from the handover record. |
Start with a reproducible build.
Ask for the repository, the revision that is deployed and instructions for setting up a fresh environment. The instructions should identify tool versions, required services and configuration names without putting live secrets in the repository.
Use a practical acceptance check: someone following the documentation on a clean machine can start the application and run its agreed checks. If the build depends on an undocumented local file, the handover is incomplete.
List accounts separately from credentials.
The domain registrar, DNS, hosting, database, email provider, payment provider and content platform may all be separate accounts. Record the owner, billing contact and people with access for each one.
Transfer or grant access through the provider's supported mechanism. Share necessary secrets through an agreed secure channel, then review which old access should be revoked. Do not put passwords or wallet recovery phrases into a handover document.
Separate custom code from third-party dependencies.
The project agreement should describe the rights to the custom work. Dependencies such as libraries, fonts, images and hosted services have their own licences or terms. Receiving source code does not replace those conditions.
A repository without a licence does not automatically grant general permission to reuse its code. GitHub's licensing documentation explains that distinction. For a commissioned build, the agreed contract and the dependency inventory need to be consistent.
Describe how the product stays running.
Document deployment, rollback, backups, restore steps and the important scheduled tasks. Identify who receives alerts and what they are expected to do. A backup that nobody knows how to restore is an untested assumption.
Also record data export and deletion procedures where they are relevant to the product. The handover should explain which system holds the authoritative data and which copies are made by integrations.
Finish with a handover rehearsal.
Walk through a release, a common support action and the recovery procedure agreed in scope. Record known limitations rather than hiding them behind a statement that the product is finished.
At BRÈCHE, full source ownership is part of the delivery approach. The operational scope still needs to be explicit: ongoing support, hosting fees and future development are not automatically covered by receiving the repository.
The checklist.
- Repository access and deployed revision identified.
- Fresh setup and build reproduced from the instructions.
- Domain, infrastructure and service account owners listed.
- Configuration shared without exposing secrets.
- Dependency licences and recurring costs documented.
- Deployment, rollback and recovery rehearsed within the agreed scope.
- Support responsibilities and known limitations recorded.
Take it into the project.
Software handover acceptance record.
Record evidence that another developer can run and operate the product. Use pass, fail or unverified for each check.
Download the worksheet (.txt)Plain text, ready to edit. No account or email required.
Preview the worksheet questions
- Release identity
- Record repository, branch, deployed revision, environment and verification date. Can the deployed version be matched to the source?
- Clean setup
- Record tool versions and setup instructions. Name the person who followed them from a fresh environment and the result of the agreed checks.
- Accounts and billing
- For domain, hosting, data, email and integrations, record account owner, billing owner, access role and transfer status. No passwords.
- Deploy and rollback
- Record the staging deployment and rollback checks, their outcome and any limitations involving data or external systems.
- Backup and restore
- Name the backup owner, restore instructions and a restore test into an isolated environment. Do not treat backup existence as a passed restore.
- Rights and dependencies
- Link to the agreed rights for custom work and the inventory of libraries, fonts, media and hosted services with their terms.
- Operations and recovery
- Identify alerts, scheduled jobs, exports and important recovery procedures. Name the person responsible for each.
- Open items and sign-off
- List failed or unverified checks, known limitations, remaining work and its owner. Record exactly what is accepted and what is still open.
Sources.
Technical references checked on .