A proper handover leaves the buyer able to operate, support and change the software without depending on one individual or supplier account. Confirm ownership, administrative access, source and release history, infrastructure, data controls, security responsibilities, operating instructions and an agreed support boundary before final acceptance.
Put this guidance into practice
Explore our custom CRM and ERP development, software development, application launch, premium website development and business automation services. We scope the work around your existing tools, team and goals.
Agree the handover before delivery begins
Handover is not a folder sent after the final demonstration. It is part of the delivery scope and should be defined while the project is being planned. Name what will be transferred, who will receive it, how acceptance will be tested and what the supplier must remove or retain after the transition.
Start with the outcome: your organisation must be able to access the service, understand its important dependencies, recover it, make an authorised change and bring in another qualified team if necessary. A large document set is not useful when the accounts, environments and operational knowledge still belong only to a supplier employee.
The GOV.UK Digital, Data and Technology Playbook emphasises continuity during transition and the need to keep the right people involved through completion and handover. For a smaller business, the same principle means scheduling knowledge transfer before the delivery team disperses and before unresolved access questions become urgent.
- Named business and technical recipients
- A handover checklist attached to the delivery scope
- Evidence required for acceptance
- A transition period with the people who built the system
- Clear post-handover support and exit responsibilities
Put the source, accounts and commercial rights under clear control
Confirm where the source code lives, who owns or licenses it and which organisation controls the repository. If the repository was created in a supplier's personal account, move it into an appropriate organisation account or establish a verified mirror before the project closes. GitHub notes that a repository transfer moves administration of its content, issues, releases, projects and settings to the new owner, although some features can change with the destination plan.
List the accounts that keep the service running: domain and DNS, hosting or cloud, app stores, email delivery, databases, analytics, monitoring, payment or messaging providers, design files and support tools. Record the business owner, billing owner, recovery contact and level of access for each. Avoid a shared password document; grant named access and use the platform's recovery and multi-factor authentication controls.
Commercial ownership also needs plain language. State which code, designs and documentation are created for your organisation, which reusable supplier components are licensed, and which third-party packages remain under their own licences. GOV.UK guidance on reusable source code recommends making ownership clear, keeping repositories under the commissioning organisation's control and storing credentials separately from source code.
- Repository and design-file ownership
- Administrator and recovery access for every essential platform
- Domain, hosting, store and data-account control
- Intellectual-property and third-party licence schedule
- No secrets committed to the source repository
Receive a reproducible release, not only a copy of the code
Source code alone may not reproduce the live service. Ask for the supported runtime versions, dependency lock files, build and deployment instructions, environment variables by name, infrastructure configuration, database migrations and the exact release identifier running in production. Secret values should be transferred through a secure channel and rotated when responsibility changes.
Configuration should explain how the application, database, networks and external services fit together. GOV.UK's configuration guidance recommends treating infrastructure as code where practical because it can be tested, reused and documented, and it reduces differences between development and production environments.
Keep an immutable copy of each accepted release and the evidence needed to identify it. NIST's Secure Software Development Framework recommends securely archiving release files and supporting integrity or provenance information, and maintaining information about the components in a release. The appropriate depth depends on the system, but a buyer should at least know what was deployed and how to verify the package.
- Release tag or commit matched to production
- Dependency and runtime versions
- Build, deployment and rollback procedure
- Database schema and migration history
- Environment-variable inventory without exposing secret values
- Protected release archive and component inventory
Document how the service is operated and recovered
Operational documentation should help a competent person act under pressure. Include the service architecture, important data flows, scheduled jobs, integrations, monitoring, backups, common alerts and the first safe diagnostic steps. Use diagrams where relationships matter, but connect them to real accounts, components and owners.
Test at least one restore or rollback with the receiving team. A statement that backups are enabled is not evidence that the required data can be recovered within an acceptable time. Record what is backed up, where it is stored, how long it is retained, who can restore it and which business transactions may need manual reconciliation after recovery.
Describe routine maintenance as well as emergencies: dependency updates, certificates, storage growth, queue failures, email reputation, app-store requirements and recurring costs. Assign responsibility after handover. An instruction that says 'contact the developer' is not an operating model unless that support arrangement, response boundary and commercial term are explicit.
- Current architecture and integration map
- Monitoring, alerts and responsible recipients
- Backup scope, retention and a tested recovery route
- Rollback and incident communication steps
- Recurring maintenance, renewals and operating costs
- Known limitations and temporary workarounds
Close security and data responsibilities deliberately
Review every person, service account, token and integration that had access during development. Remove accounts that are no longer needed, reduce remaining privileges, rotate sensitive credentials and confirm where audit logs are retained. Do not delete the evidence needed for an investigation or legal retention requirement merely because the project has ended.
Receive a record of the security work that was actually performed: dependency and secret scanning, code review, configuration checks, penetration testing where agreed, unresolved findings and the plan for future vulnerability updates. Avoid a vague statement that the system is secure. Security acceptance should name the evidence, remaining risk, owner and review date.
Confirm how production data was handled in development and support environments. Record data locations, subprocessors, retention, export and deletion routes, and any test copies that must be removed. The receiving organisation should also know how to respond when a customer asks for access, correction or deletion under the policies that apply to the service.
- Access review and credential rotation
- Outstanding security findings with owners and due dates
- Dependency and component inventory
- Production, backup and test-data locations
- Retention, export and deletion procedures
- Incident and vulnerability reporting contacts
Run a handover rehearsal before final acceptance
Ask the receiving team to perform the critical tasks while the delivery partner observes: sign in with organisational accounts, deploy a controlled change, inspect logs, restore a backup in a safe environment and follow one incident scenario. This exposes missing permissions and undocumented assumptions more reliably than a presentation.
Use acceptance criteria for the transition itself. For example: an authorised administrator can add and remove a team member; a tagged release can be built from a clean environment; a test backup can be restored; an alert reaches the named owner; and the business can export its data in the agreed format. Record what passed and any conditional acceptance.
Finish with a short ownership register: business owner, technical owner, data owner, security contact, support contact and suppliers that remain involved. DigiStartup India plans handover as part of custom CRM, ERP, portal and application delivery so the system remains understandable and operable after launch—not only while the original project team is present.
- Organisational access tested by the receiving team
- Clean build and controlled release demonstration
- Backup restore or recovery rehearsal
- Known-issue and decision log reviewed
- Final owner and support register
- Signed acceptance with clearly listed follow-up actions
Further reading
Frequently asked questions
Should the client always own the source-code repository?+
The commercial agreement determines ownership, but the arrangement must be explicit and should not leave the buyer dependent on one person's private account. For bespoke work, organisational control of the main repository or a complete verified mirror is usually the clearest route. Reusable supplier components and third-party packages can remain licensed under separately stated terms.
Is documentation enough for a software handover?+
No. Documentation is necessary, but access and operational capability must also be demonstrated. The receiving team should be able to build or deploy the accepted release, inspect the service, recover data, manage users and know where to escalate a failure.
When should credentials be transferred?+
Grant organisational access throughout delivery where practical. At handover, verify named access, move recovery contacts and billing ownership, remove unneeded users and rotate secrets that were known to departing staff. Never place passwords, private keys or live tokens inside the source archive or handover document.
What if the business does not have an internal technical team?+
Nominate a business owner and arrange an independent technical custodian or support partner. Your organisation should still control the domain, commercial accounts, data exports and recovery routes. The handover can include a managed-support agreement, but it should also define how another qualified provider could take over later.