A software handover is complete when the organisation can operate, inspect, change, recover and support the system without depending on one individual developer's laptop or personal accounts. Receiving a ZIP file or an administrator password is not enough.
For Kenyan and East African organisations changing developers, bringing a system in-house or completing a custom software project, the handover should be treated as a tested transition. This checklist helps business owners, operations leads and technical reviewers define what must be transferred, what must remain confidential and what evidence proves the receiving team is ready.
Start with the system, the accounts and the date ownership must change.
Share the system type, current provider, expected transition date and the main access gap. Do not send passwords, API keys, database exports or customer records in an enquiry.
Discuss the handover on WhatsApp Explore website and software supportWhat software ownership should mean in practice
Ownership has several layers. The contract may address rights to custom code, design files and documentation. Separately, the organisation needs operational control of the repository, domain, hosting, cloud resources, data, deployment pipeline, monitoring and third-party accounts. A licence to use software is not automatically ownership of every component, and access to a running site is not the same as being able to rebuild it.
Have the agreement reviewed by an appropriately qualified adviser where intellectual-property, employment, procurement or data-protection obligations are material. This operational checklist does not decide legal ownership; it helps the parties identify the assets and acceptance evidence that the transition needs.
12 deliverables for a dependable software handover
1. A signed scope and asset register
List every website, application, API, database, mobile build, background job, domain, subdomain and environment in scope. For each item, record its purpose, current location, business owner and whether it is custom code, licensed software, open-source software or a third-party service.
Write exclusions explicitly. A marketing website, customer portal and reporting database may share a brand but have different owners and suppliers. The register prevents an apparently complete handover from omitting a quiet scheduler, webhook endpoint or renewal account that the business still depends on.
2. An organisation-controlled source repository
Transfer the complete repository with meaningful history, branches, tags and release references—not only the files currently deployed. The organisation should own or administer the repository workspace, use named accounts and protect important branches with review and multi-factor authentication where the platform supports it.
Confirm that the latest production release can be traced to a commit. Keep generated secrets and private customer data out of the repository. Record any separate private package or submodule required to build the system.
3. Reproducible setup, build and environment instructions
The receiving team should be able to prepare a clean environment from written instructions. Document supported runtime versions, package managers, lock files, system extensions, build commands, configuration keys, queues, scheduled tasks, storage paths and external services.
Provide safe example configuration without live credentials. Separate local, test, staging and production settings. A successful build on the outgoing developer's computer is not evidence that another authorised team can recreate the release.
4. A dependency, licence and component inventory
Record direct and important transitive dependencies, their versions, licences and update route. Where suitable, provide a software bill of materials for the release. The purpose is not paperwork for its own sake; it helps the owner identify affected components when a vulnerability, licence concern or abandoned package appears.
Include commercial themes, plugins, fonts, image licences, SDKs and private packages. State which subscriptions are renewable, which licences are tied to a supplier account and which components can be replaced.
5. Business-owned infrastructure and provider accounts
Prepare an account register for domain registration, DNS, hosting, cloud, source control, deployment, email delivery, storage, monitoring, analytics, app stores, payment or messaging providers and any other integration. Record the organisation owner, billing contact, renewal date, support route and recovery method.
Move business assets out of personal accounts where the provider supports an organisation or delegated role. Do not solve the handover by sharing one unrestricted login. Named access makes later review and revocation possible.
6. A controlled credential transfer and rotation plan
Use an agreed secure channel or password manager for credentials. Do not put passwords, private keys, API tokens or production database exports in ordinary email, WhatsApp or project documents. Prefer creating new owner-controlled credentials, testing them and then revoking the outgoing access.
List every secret by purpose and location without copying its value into the asset register. Include deployment keys, database users, API clients, webhook secrets, signing keys, backup credentials and recovery codes. Record who can rotate each one and what service will fail during rotation.
7. Data definitions, exports and migration evidence
Document the main data stores, schemas, migrations, retention rules, personal or sensitive fields, encryption dependencies and authoritative records. Provide a tested export in a usable format where the contract and applicable obligations allow it.
Reconcile counts and key totals before and after any transfer. Keep production data out of a casual demonstration environment. If the system connects to other tools, the API integration guide helps define record ownership, duplicate controls and reconciliation.
8. Deployment, rollback and release records
The handover needs the path from reviewed source to production: build, tests, approvals, deployment commands or workflow, database changes, cache steps and smoke checks. Identify the current production commit and the person authorised to release.
Test a controlled deployment in an appropriate environment. Document rollback limits, especially when a release changes data or triggers external transactions. Restoring old code does not automatically reverse an invoice, payment, message or migrated record.
9. Backups with restore proof
List what is backed up, where copies are stored, how often they run, how long they are retained and who can restore them. Cover databases, uploaded files, configuration needed for recovery and any externally hosted content that is not reproducible from source.
Request evidence from a recent restore test. A green “backup completed” message proves that a job ran, not that the result is complete, decryptable or usable within the business recovery target.
10. Monitoring, logs and security history
Transfer uptime checks, error monitoring, performance alerts, log locations, vulnerability reports, security contacts and the known incident history that the owner is entitled to receive. Logs should support diagnosis without exposing secrets or unnecessary personal information.
Record unresolved vulnerabilities and technical debt with severity, affected component, current mitigation and owner. Do not reset the backlog to zero by moving it outside the handover document. Ongoing review can be scoped through website and software support.
11. Tests, acceptance evidence and known limitations
Provide the automated test suite, manual test scripts and the scenarios used to accept the release. Include ordinary journeys, permissions, invalid input, failed integrations, duplicate requests, recovery and important mobile or browser combinations.
Maintain a written list of known defects, unsupported workflows, capacity limits and deferred changes. Acceptance means the receiving team understands the current state; it does not require pretending that every limitation has disappeared.
12. Documentation, training and an access-revocation closeout
Deliver architecture notes, data flows, administrator tasks, user guidance, operational runbooks, provider contacts and a decision log for important design choices. Hold role-specific sessions for administrators, support staff and the technical team, then record unanswered questions.
Agree a transition window, support contacts and response expectations. At closeout, confirm the new owners can operate the service, rotate critical credentials, deploy a small safe change and restore a backup. Remove or reduce outgoing access, update recovery contacts and retain an approved handover record.
Use a practical acceptance test
- A new authorised maintainer can clone the organisation repository and identify the production commit.
- A clean environment can install dependencies and build using the documented versions and lock files.
- The team can deploy to a suitable test environment and run agreed smoke tests.
- Named organisation accounts control the domain, hosting, repository and critical providers.
- New credentials work and outgoing credentials can be revoked without losing access.
- A representative data export can be opened, counted and reconciled.
- A recent backup can be restored to an isolated environment within the agreed target.
- Monitoring produces a test alert that reaches the responsible person.
- Known defects, security issues and renewal dates have named owners.
- The receiving team can explain the support and escalation path without contacting a former employee's personal account.
If the current provider cannot supply everything
Do not begin by replacing a live system blindly. Preserve available access and records, inventory what is controlled by the organisation, and identify the highest continuity risks. A technical review may recover enough source, configuration and data to create a controlled improvement or migration plan, but a running application cannot always be converted back into a complete maintainable codebase.
Prioritise domain and DNS control, current backups, data access, hosting ownership and the ability to communicate with users during an incident. Then assess whether the system should be stabilised, documented, migrated or rebuilt. The website redesign migration checklist covers URL and launch continuity; the custom software cost guide explains lifecycle cost drivers for a replacement scope.
Frequently asked questions
Is receiving the source code enough for a software handover?
No. The organisation also needs repository history, build instructions, dependencies, data, infrastructure accounts, credentials, deployment and rollback steps, backups, monitoring, documentation, known issues and tested operational access.
Who should own the domain and hosting accounts?
The organisation should normally control business-critical accounts through named, recoverable ownership and delegated roles. The contract and provider rules determine the exact arrangement; avoid dependence on one supplier's or employee's personal account.
Should passwords be sent during handover?
Transfer secrets through an agreed secure mechanism, preferably by creating new organisation-controlled credentials and rotating or revoking the old ones. Do not send production passwords, private keys, API tokens or customer data in ordinary email or WhatsApp.
How do we verify that backups really work?
Restore a recent representative backup into an isolated environment, verify the expected data and files, record the time and resolve any gaps. A successful backup job alone does not prove recoverability.
Can Rx Code Labs take over software built by another developer?
Often, yes. The first step is a scoped review of source, accounts, hosting, data, dependencies, security, deployment, backups, documentation and known defects before a safe support, improvement or migration plan is agreed.
Verify that your team can build, deploy, recover and support the system.
Bring the asset list, current access position and transition deadline. We can assess the handover and define the safest first actions without requesting secrets in the initial enquiry.
Plan a handover review Use the contact page