# A software handover should prove the next team can operate it

> Check source access, service accounts, documentation, release procedures, and open issues through a practical handover exercise.

- Published: Sep 25, 2026
- Topic: Project planning
- Author: RDR Digital
- Original: https://rdr.digital/blog/software-project-handover

Receiving a source-code folder is useful. It does not establish that your business can deploy a change, restore a service, or find the account responsible for a failing integration.

Plan the handover around what the receiving team must be able to do. That team might be an internal maintainer, the original supplier under a new support agreement, or another provider.

## Inventory the system and its accounts

Ask for a concise map of the application, data stores, integrations, and external services. Record the administrative owner, billing responsibility, and support contact for each relevant account.

Include domains, hosting, email delivery, identity, monitoring, and any scheduled work. Record where credentials are managed without placing secret values in a general handover document.

Agree access through appropriate individual or organizational accounts. Confirm that the receiving team can use its own access rather than depending on the departing maintainer's personal login.

## Confirm source access and rights separately

GitHub's [repository transfer documentation](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository) explains how repository ownership can be transferred and describes effects on associated features and permissions. Review the details for the actual account and repository before using that mechanism.

A repository transfer is one technical action. Treat hosting accounts, domain administration, third-party subscriptions, and contractual usage rights as separate items to confirm. Do not infer that a successful repository transfer settles them.

Ask for an inventory of third-party components and relevant licenses. Confirm ownership and usage arrangements in the actual agreement rather than relying on an informal description of “owning the code.”

## Ask for documentation that supports action

Keep the core pack focused on the system as delivered.

| Document or record          | What it should help the next team do                          |
| --------------------------- | ------------------------------------------------------------- |
| Setup instructions          | Run the application in an appropriate development environment |
| Environment and service map | Find dependencies and their owners                            |
| Release procedure           | Deploy a reviewed change and verify the result                |
| Recovery runbook            | Follow the agreed restoration or incident process             |
| Data and integration notes  | Understand important records, mappings, and exceptions        |
| Open-issue list             | See known limitations, priorities, and responsible people     |

Date the material and identify the release it describes. A long document about an earlier architecture can be less useful than a short accurate one.

## Rehearse the handover

Have the receiving maintainer perform an agreed exercise in a safe environment: obtain the source, configure the application, run relevant checks, and make a small reversible change.

Then ask them to deploy to a non-production environment and follow a representative operational task. This might be investigating a failed scheduled job or finding a rejected integration record.

Record where they need undocumented help. Update the instructions and repeat the affected step. The objective is to discover dependencies on individual memory while the original team is still available.

## Close the remaining responsibilities

List unresolved defects, deferred improvements, and known operating limitations. For each, identify the owner and next decision. Confirm the support start date and escalation route so responsibility does not fall between agreements.

Review access after the receiving team has demonstrated that it can operate the system. Preserve any supplier access that is explicitly required for continuing support; remove obsolete access through the agreed process.

Carry the handover evidence into the [maintenance plan](https://rdr.digital/blog/software-maintenance-after-launch), including the latest [recovery exercise](https://rdr.digital/blog/testing-backup-restoration). A useful handover leaves the next team with both the materials and the demonstrated ability to use them.

## Sources

- [GitHub Docs: Transferring a repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository)