Software · Practical guide
Your software is ready. Can your team run it without the developer?
A practical handover checklist for source code, business accounts, deployment, backups and ongoing support.
Handover is a working capability, not a ZIP file
Receiving source code is useful, but it is not the same as being able to operate a product. If nobody can identify the live environment, restore the data or publish a small correction, the business still depends on undocumented knowledge.
Plan the handover while the project is being scoped. Decide what your team will operate directly and what remains part of an ongoing support arrangement. That distinction helps everyone prepare the right documentation and avoids a last-week scramble for access.
List the accounts that keep the product running
Start with the domain, hosting, database, email delivery, file storage, app stores and external integrations. Record the business owner, billing owner and administrator for each. Do not place passwords or secret keys in a shared public brief or ordinary project document.
Check recovery methods and whether an appropriate second administrator can access essential services. A system should not become unreachable because one employee changes roles or a contractor’s personal email account is no longer available. Arrange access through a secure, agreed process.
Rebuild from the instructions
Ask someone other than the original implementer to follow the setup documentation in a separate non-production environment. They should be able to identify the required runtime, install dependencies, configure non-secret settings and run the relevant checks. Record anything they had to ask the author.
Use that exercise to improve the documentation. Include the release procedure, environment differences and where configuration is supplied. The objective is not to make every business owner a developer; it is to make the product understandable to the next qualified person who supports it.
Restore a backup, not just create one
A backup schedule does not show whether the stored data can be restored into a usable application. Agree what must be backed up, how recovery is tested and who is responsible for checking the result. Include uploaded files when the product depends on them.
Rehearse recovery in an isolated environment using appropriate access controls. Compare important records and verify a representative user journey. Record the observed recovery time and any missing data so the business can decide whether the arrangement meets its needs.
Define support in terms people can act on
Separate a defect in the agreed scope from a new feature request. Write down the support channel, service hours, response expectations and escalation process. A phrase such as “maintenance included” leaves too many unanswered questions unless the actual work is described.
Also assign ownership for dependency updates, security fixes, certificate renewals and service billing. Keep an inventory of third-party components and their licence conditions. Changes to external services can create work even when the custom application itself has not changed.
Run one final ownership rehearsal
Choose a small, low-risk change in a test environment. Ask the receiving team to locate the code, make the change, run checks and prepare a release using the documented process. Then ask them to find the support and recovery instructions without help.
The result should be a short list of remaining actions with owners—not a vague declaration that everything is complete. A confident handover means your business understands what it owns, what it licenses, what it can operate and where it will get help.