A software handover is complete when the receiving team can access the agreed assets, build and deploy the application, understand its operating risks and carry out essential support tasks. Receiving a ZIP file of source code is useful, but it does not prove any of those abilities.
Plan handover when the project begins, then verify it with a practical rehearsal. This is valuable whether a founder is hiring an internal team, a company is changing suppliers or a development engagement is moving into maintenance.
Distinguish rights from operational access
Contractual rights and technical control are related but separate. Your organization may hold rights to commissioned code while lacking administrative access to the cloud account that runs it. Equally, access to a repository does not establish rights to every component inside it.
Ask the responsible parties to document what is assigned, licensed, retained by the supplier or obtained from third parties. Clarify the treatment of pre-existing components, open-source dependencies, design assets and commercial services. Legal ownership questions require the appropriate contractual review.
Alongside that review, create an operational asset register with the current owner, administrative contact, billing party and transfer action for each item. Keep actual credentials in an approved secret-management process, not in the register itself.
Inventory more than the main repository
The application may depend on several repositories and services. Include infrastructure definitions, database migration files, background workers, build scripts, automated tests and any tools needed to publish a release.
For each repository, verify access to the relevant history, branches, release tags and issue records within the agreed scope. Identify archived or abandoned code so the receiving team does not mistake it for the active application.
The handover checklist should cover:
- ▸Application and infrastructure source, with the deployed version identified.
- ▸Build and dependency instructions, including required tool versions.
- ▸Deployment pipeline configuration and approval rules.
- ▸Environment configuration names and securely transferred secrets.
- ▸Database schemas, migration history and data export procedures.
- ▸Automated tests and their known limitations.
- ▸Third-party dependencies, licenses and renewal responsibilities.
- ▸Known defects, operational constraints and outstanding decisions.
Request an explanation of any artifact that cannot be transferred and an agreed alternative before acceptance.
Verify organizational control of accounts
Review cloud tenancy, domain registration, DNS, source hosting, identity, email delivery, monitoring, payment and analytics accounts. Identify which accounts should be controlled directly by the customer organization and which services remain managed under contract.
Use named accounts and appropriate administrative roles. Avoid leaving an individual developer's personal email address as the only recovery route for a business-critical service. Confirm that billing and renewal notices reach the responsible organization.
Some services cannot be moved by simply changing an email address. They may require a formal account transfer, resource migration or new commercial agreement. Document the actual process and its impact before revoking the outgoing supplier's access.
For international delivery, also record who will retain remote access after transition and for what purpose. Technical access changes should match the agreed processing and support arrangements.
Rebuild from the delivered materials
The receiving team should attempt a clean build using the documented instructions in an authorized environment. The outgoing team can observe and answer questions, but the exercise should reveal which undocumented assumptions remain.
Identify missing packages, unpublished dependencies, manually configured settings and files that exist only on one person's machine. Resolve those gaps in the documentation or delivery artifacts.
Next rehearse deployment to an appropriate non-production environment. Confirm that the deployed version can be traced back to the agreed source and that a person outside the original team can run the release process. Do not use a production cutover as the first test of incomplete instructions.
Prove data access and recovery
Inventory the data stores, uploaded files, backups and supporting configuration. Confirm that export and recovery procedures include the information needed to operate the application, rather than only the most obvious database tables.
Run a scoped recovery exercise in an isolated environment. Record what was restored, how completeness was checked and which dependencies remained outside the exercise. NIST's contingency planning guidance is a useful reference for evaluating recovery requirements and priorities.
Define how the parties will handle remaining data held by the outgoing supplier, including backups and logs, according to the agreed obligations. A transfer is not complete merely because a new team has a copy; residual access and retained copies also need an accountable decision.
Hand over knowledge through real tasks
Ask for architecture notes, operational runbooks and a walkthrough of the most important workflows. Documentation should explain why unusual decisions were made, not only list the technologies.
Have the receiving team perform several agreed tasks: investigate a failed background job, locate a relevant audit event, change a non-production configuration and identify the procedure for restoring service. Choose tasks that reflect the application's actual risks.
Record answers to practical questions. Which alerts are noisy? Which external provider has special escalation requirements? What operation cannot safely be repeated? Which manual step is still necessary? These details make the handover usable.
Close access carefully and record acceptance
Schedule credential rotation and removal of outgoing access after the receiving team has verified the required control. Identify credentials shared with integrations so rotation does not unexpectedly interrupt service. Revoke access that is no longer justified, and document any limited transition access that remains.
Accept the handover against an evidence list, with unresolved items, owners and dates. Define the transition support period and the route for reporting missing information. The maintenance agreement checklist helps establish responsibility after that period.
For an upcoming engagement, include this handover evidence in the software quote comparison. It should be part of the purchased delivery, not an improvised final request.
To discuss a new build or vendor transition, explore software engineering services and send the current asset inventory and transition constraints. A clear inventory makes the next step concrete.