Delivery guide · Ownership
Software Handover Checklist: Code, Infrastructure and Access
A handover is successful when a competent new engineer can understand, deploy, operate and change the system without depending on private knowledge. A repository transfer is only one part of that result. Use this checklist during delivery, not as a documentation scramble on the final day.
By Anjula Paulus, Founder and software engineer · Published · 4 min read
Key takeaways
- Keep core assets in client-controlled accounts throughout delivery.
- Document how the system runs, fails, recovers and changes.
- Transfer operational context as well as code and credentials.
- Rotate secrets and remove outgoing access explicitly.
- Prove the handover with a deployment or change performed by the receiving team.
01
Source and architecture
Transfer the complete repository and history, not a final archive. Include build instructions, dependency files, tests, code-generation steps and conventions that are not obvious. A short architecture record should explain components, boundaries, data flow and the reasons behind decisions that would otherwise be reversed accidentally.
- Repositories and branch/release model
- Architecture and important decision records
- Local setup and test instructions
- Known technical debt and unsupported paths
02
Infrastructure and environments
List every environment, account, region, domain, certificate, storage service, queue, scheduled job and external provider. Infrastructure should be defined in code where practical, with manual steps and ownership documented. Record backup and recovery expectations and prove that a restore works.
03
Deployment and release
Document how a change moves from commit to production, required approvals, migrations, feature flags, rollback and post-release checks. The receiving team should perform a deployment in a safe environment while the outgoing team observes; that exposes missing assumptions immediately.
04
Data and integrations
Describe schemas, retention, classification, migrations, imports, exports and reconciliation. For each integration, document credentials ownership, rate limits, webhooks, retry behavior, error queues, contact routes and how to replay work safely.
05
Operations and support
Transfer dashboards, logs, alerts, runbooks and current service levels. Identify common incidents, how they are diagnosed and which actions are dangerous. Record current capacity limits, cost drivers and maintenance tasks such as certificate, key or dependency rotation.
- Monitoring and alert ownership
- Incident and escalation routes
- Backup, restore and disaster recovery
- Scheduled work and recurring maintenance
- Current defects, risks and planned changes
06
Access, security and closure
Inventory human and machine access, transfer ownership, rotate shared secrets and revoke outgoing accounts. Confirm data copies and local exports are returned or destroyed under the agreement. Close with a signed list of delivered assets, open risks and the support window for handover questions.
Questions
Common questions about software handover checklist
What documents are needed for a software handover?
Architecture and setup guidance, environment and service inventory, deployment and rollback, data and integrations, operational runbooks, access ownership, known risks and current work. Keep documents close to the code and update them during delivery.
How do you prove a software handover is complete?
Have the receiving team set up, deploy, monitor and make a small change using the delivered material while the outgoing team observes. Record and close every missing dependency or undocumented step.
Who should own the source code repository?
The client should normally own or control the repository and grant the supplier access. This reduces transfer risk and preserves history, permissions and continuity if the relationship changes.