Topics: Custom software & SaaS
Want this done for your business? Get a fixed quote or book a free 30-minute call.
Quick answer: A complete handover gives you the full code repository with its history, every account and credential in your company's name, a short set of essential documents, and the data, backups and licences the system relies on. Then you prove it works: someone other than the original developer deploys it to a fresh environment and restores a backup.
Handover is the moment you find out whether you own your software or merely have access to it. Contracts can say all the right things about intellectual property, but if the cloud account sits on a developer's personal card and the only working copy of the deployment steps lives in their memory, ownership is theoretical.
This checklist is the practical side. Our guide to who owns the code covers the contract wording; what follows is everything to collect, and how to test that you've actually got it.
When do you need a formal software handover?
Any time responsibility for the software changes hands, not only at the end of a project. Common triggers:
- The build contract ends and a different team will maintain it
- You're switching developers or agencies
- You're bringing development in-house
- A freelancer or key engineer is leaving
- An investor or buyer is doing due diligence
- The warranty period after launch is ending
The earlier you start, the easier it is. Ideally, ask for the items below to be set up in your name from day one, so handover becomes a check rather than a rescue.
Which code, repositories and build scripts should you receive?
The whole working project in version control, not a zip file of the latest code. A zip loses history, branches and the context of every change. Collect:
- [ ] The Git repository transferred to your organisation on GitHub, GitLab or Bitbucket, with full history
- [ ] All active branches and release tags
- [ ] Build scripts and dependency files, with versions pinned
- [ ] Database schema and migration scripts
- [ ] Infrastructure-as-code or written server configuration
- [ ] CI/CD pipeline definitions and any secrets they need, listed (not pasted into documents)
- [ ] Automated tests and instructions to run them
- [ ] Seed or sample data for setting up a test environment
- [ ] Design source files, such as the Figma project
- [ ] For mobile apps: signing keys and certificates, held in your own developer accounts
Mobile signing deserves special care. If the Android upload key or iOS certificates are lost, publishing updates becomes painful. Our app store submission checklist covers the account set-up that makes this simpler.
Which accounts, domains and credentials must be in your name?
Every account the software depends on should belong to the business, with the developer added as a user you can remove.
| Asset | Owned by | Developer's access |
|---|---|---|
| Cloud hosting (AWS, Google Cloud, Azure, others) | Business, billed to your card | Named user with limited role |
| Domain registrar and DNS | Business | None, or DNS editing only |
| Business email and workspace | Business | Their own user account if needed |
| Apple Developer and Google Play Console | Business | Team member role |
| Payment gateway | Business, under your KYC | Developer API access only |
| Analytics, error monitoring, crash reporting | Business | Team member |
| Email, SMS and WhatsApp providers | Business | Team member or API key |
| Maps and other third-party APIs | Business | API keys under your account |
| Code hosting | Business organisation | Member, removable |
Then deal with secrets. Ask for a list of every environment variable, API key and password the system uses, and where each is stored. After handover, rotate them: generate new keys, update the system, and revoke the old ones. Anyone who had the old values, including former contractors, then has nothing that works.
What is the minimum documentation you should accept?
Enough for a competent new developer to understand, run and change the system without phoning the old one. You don't need a library of documents. You do need these:
- Architecture overview. One or two pages and a diagram: components, how they connect, where they run.
- Setup README. How to get the project running locally, step by step.
- Deployment runbook. How to release a change, roll it back and restore from backup.
- Data model. The main tables or collections and what they mean in business terms.
- Third-party services list. Every external service, what it does, which account owns it and what it costs.
- Known issues. Bugs, shortcuts and workarounds, honestly listed.
That last document is the most revealing. Every system carries some technical debt; a developer who lists theirs openly is doing you a favour, while one who claims there's none probably hasn't looked.
How do you check that the handover actually works?
Ask someone who didn't build it to deploy it from scratch. Documentation that looks complete often hides a missing step that lived in one person's head. A practical test:
- An independent developer clones the repository onto a clean machine.
- They follow the README to run it locally, noting every gap.
- They deploy it to a fresh environment using only the runbook and your accounts.
- They restore the latest production backup into that environment.
- They run the tests and click through the main user journeys, including logins for each role.
- For mobile apps, they produce a signed build from your accounts.
Every gap they hit goes back to the original developer to fix while they're still engaged. Agree this test in the contract if you can, so it's an expected step rather than a sign of distrust. If you don't have someone to run it, you can ask us to review a handover.
What about data, backups and third-party licences?
Your data, your backups and your licences should all be under your control, and documented.
- [ ] A full export of production data in a usable format
- [ ] Backups running on a schedule, stored in your account, with retention you've chosen
- [ ] A successful restore test, recorded with the date
- [ ] A list of open-source components and their licences, flagging any with obligations that affect how you distribute the software
- [ ] Paid licences (themes, fonts, components, SDKs) bought in the business's name, not licensed to the developer personally
- [ ] Written confirmation that the developer has deleted copies of production data they no longer need
The last point matters for privacy. Under laws such as India's DPDP Act and Australia's Privacy Act, your business remains responsible for personal data it controls, including copies sitting on a former contractor's laptop.
How should knowledge transfer sessions run?
As a short series of recorded walkthroughs, followed by a window for questions. Three to five sessions of about an hour usually cover a small or mid-size system:
| Session | Covers |
|---|---|
| Architecture tour | Components, data flow, why key decisions were made |
| Deployment and operations | Releasing, monitoring, backups, common alerts |
| Data and integrations | Data model, third-party services, scheduled jobs |
| Known issues and roadmap | Debt, fragile areas, half-finished features |
| Open Q&A | Questions from the new team after reading the code |
Record every session and store the recordings with the documentation. Then agree a short warranty or Q&A window after handover, often a few weeks, during which the original developer answers questions and fixes defects in their own work. Our guide to the first 90 days after launch explains which issues typically surface in that period. And next time you're comparing software development quotes, check that handover appears as a line item.
Frequently asked questions
What should a software handover include?
The full code repository with history, build and deployment scripts, every account and credential in the business's name, essential documentation, data exports and backups, a list of licences, and recorded knowledge transfer sessions. It should end with an independent test that the system can be deployed and restored.
Who should own the hosting or cloud account?
Your business, billed to your payment method, with the developer added as a user whose access you can change or remove. If the account is in the developer's name, ask for it to be transferred or migrated before handover is signed off.
How do I know the source code I received is complete?
Have an independent developer build and deploy it from the repository to a fresh environment, using only the documentation provided. If it runs, matches the live system and passes the tests, the code is complete; any step that needs the original developer's help reveals what's missing.
Should the developer delete our data after handover?
Yes, once they no longer need it, and you should ask for written confirmation. Your business stays responsible for the personal data it controls, so copies on a former contractor's devices or accounts are a risk. Keep any data they need during the warranty period to a minimum.
How long should knowledge transfer take?
For a small or mid-size system, three to five recorded sessions of about an hour, plus a Q&A window of a few weeks, is usually enough. Larger or poorly documented systems take longer. Plan the sessions after the new team has had time to read the code.
Taking over software from another developer?
We regularly pick up systems built by other teams. We'll run the handover checks, flag what's missing and give you a fixed quote for maintenance or further work. Book a free call to talk through your situation.