Almost nobody asks this question until the relationship is ending, which is exactly the wrong moment. It is a cheap conversation before a contract is signed and an expensive one after.
Paying for it is not owning it
The intuition is that if you commissioned and paid for software, it is yours. In most jurisdictions that is not how copyright works by default. Copyright generally vests in the author, meaning the developer or the company employing them, unless it is assigned to you in writing.
Employment and contracting differ here too. Work produced by your own employees usually belongs to you automatically. Work produced by a contractor or agency often does not, absent an assignment clause.
The practical effect of getting this wrong is rarely dramatic. Nobody usually turns up demanding their code back. What happens is subtler: an ambiguous position that makes due diligence awkward in a funding round or acquisition, and that weakens you in any dispute. It is worth a paragraph in a contract to avoid.
This is general commercial context, not legal advice, and it varies by jurisdiction and contract. If the software matters to your business, have a lawyer read the IP clause. One hour of that is cheaper than the alternative.
The five things that must transfer
1. The source code. Not a deployed build. The repository, with its history. Commit history is genuinely valuable: it tells a future team why things are the way they are, which is information no document reliably captures.
2. The infrastructure. Cloud accounts, databases, DNS, certificates, CI pipelines. If these sit inside a supplier’s account, you cannot leave without a migration, and you are exposed if they have a billing dispute or go out of business.
3. The intellectual property. A written assignment of copyright in work produced for you. Also worth confirming what the supplier retains. Reusing their own generic libraries is normal and reasonable. Retaining rights over your business logic is not.
4. The documentation. Enough for a competent team who has never seen the system to run it, deploy it and change it. Architecture, environment setup, deployment process, scheduled jobs, external dependencies, and the decisions that would otherwise look arbitrary.
5. The credentials. Every third-party account the system depends on: payment gateway, email delivery, SMS, mapping, analytics, error tracking, app store listings. This is the one most often forgotten, and it is the one that breaks things at the worst moment.
Own the accounts from the start
The single most effective protection costs nothing and takes an afternoon: create the accounts yourself and grant the supplier access, rather than letting them create accounts and grant you access.
Repository under your organisation. Cloud infrastructure in your account, billed to your card. Domains in your registrar. Third-party services signed up under your company email.
Do that and the handover conversation is mostly removing access, rather than a project. It also removes an entire category of leverage from any future disagreement, which is a reasonable thing to want on both sides.
Third-party components
Every modern system is built substantially from other people’s code, and those components carry licences with terms. Most open-source licences are permissive and unremarkable. Some are not, and copyleft terms can matter if you intend to distribute the software rather than run it as a service.
Ask for a dependency list with licences before signing. A supplier who cannot produce one does not know what is in the system, which is itself informative. It also matters for security: you cannot patch what you have not inventoried.
Commercial components need separate attention. If a licence is in the supplier’s name, establish whether it transfers, what it costs on renewal, and what happens if it does not.
What good handover looks like
- A named end state, agreed at the start: what transfers, in what form, verified how.
- Documentation written as the work proceeds, not as a final deliverable that gets cut when the deadline tightens. This is the one most often promised and least often delivered.
- A deployment someone else has actually performed. The real test of documentation is whether a person who did not write it can follow it.
- A defined support window afterwards, so questions have somewhere to go for a period.
- An exit clause that works even if the relationship has soured. That is the scenario it exists for.
Ask before you sign
These belong in the same conversation as price, and a supplier confident in their work will answer them without friction.
- Who owns the copyright in work produced for us, and where is that written?
- What do you retain or reuse, and does anything we need depend on it?
- Whose name are the repository, cloud accounts and domains in?
- Can we have a dependency list with licences?
- What documentation will exist at the end, and when is it written?
- If we ended this next month, what would we have, and what would be missing?
That last one is the useful one. The answer tells you how the supplier thinks about the relationship, and hesitation is itself an answer.
More on evaluating suppliers in choosing a development partner, on the contract structure around it in fixed price or time and materials, and on the ongoing cost of keeping what you own running in what software maintenance really costs.
We put code, infrastructure and documentation in your name throughout, and treat handover as a deliverable rather than a favour. If you have an existing system and are not sure what you actually hold, tell us what you have.
Common questions
Do I own the code if I paid for it?
Not automatically. In most jurisdictions copyright vests in the author unless assigned in writing, and work by a contractor or agency often does not transfer by default the way employee work does. Get a written assignment in the contract rather than assuming payment settles it. This is general context rather than legal advice.
What should a software handover include?
The source repository with its history, infrastructure in accounts you control, a written IP assignment, documentation good enough for a new team to deploy and change the system, and every third-party credential the system depends on. Credentials are the item most often forgotten.
How do I avoid being locked in to a development agency?
Create the accounts yourself and grant the supplier access, rather than the other way round. Repository, cloud, domains and third-party services in your name from day one turns handover into an access change rather than a migration project.
Note
This article is general commercial guidance drawn from practice, not legal advice. Copyright default positions, assignment requirements and contractor rules vary by jurisdiction and by contract. Have a qualified lawyer review the intellectual property and exit clauses in any agreement that matters to your business.
Written September 2026.
