Many buyers assume that paying for software makes them its owner. Guides written for buyers in the UK and in Türkiye both say that this does not happen by itself. If the contract is silent, the code may legally stay with the firm that wrote it.
This post covers the ownership clause and what a handover should include. It also covers what protects you if the firm that built your system stops trading. It is not legal advice: where a legal judgement is needed, ask your lawyer.
Paying for the work does not transfer ownership by itself
A UK guide notes that in most jurisdictions the copyright in code stays by default with the firm or the freelancer who wrote it. Unless the contract assigns ownership to you, what you usually receive is a licence to use the software. A UK guide adds that the assignment takes effect only when it is in writing and signed, and that an email saying "of course you own it" is not enough. A Turkish guide reaches the same conclusion under Turkish copyright law and advises putting two clauses in writing:
- ownership of the code passes to the client when payment is complete;
- the code is kept in a repository the client can access.
The clause should say what it covers: the code, the data and the documentation. Third-party and open-source components stay under their own licences, so the contract should list them. How the clause should read under your law is a question for your lawyer.
Some suppliers offer a licence with no end date that they cannot withdraw, instead of full ownership. One guide notes that this can give similar independence. The right choice depends on what you need to do with the code later.
Keep the repository in your own account from the first day
The simplest protection is practical. The repository that holds the code, the hosting account and the accounts for third-party services should be in your company's name from the first day of the project. A UK guide notes that when these are already yours, most of the handover happens without extra work.
The same accounts are hard to recover later. A Turkish guide warns that getting domain, hosting and app store accounts back after a change of supplier can take weeks, and sometimes does not succeed at all. Be careful with contracts in which nothing is handed over until the project is finished.
What a handover includes
A handover should leave another team able to run and change the system without the people who built it. Buyer guides list these parts:
- the full code, with its complete history in the repository;
- the build scripts, and a working build and deployment pipeline;
- the configuration for each environment, with setup and deployment instructions and the list of dependencies;
- every administrator credential, and the accounts for the services the system uses;
- documentation, including architecture notes and the known risks;
- a list of the open-source and third-party components and their licences;
- a current backup of the database;
- a test suite that passes before you accept delivery;
- knowledge transfer, in sessions with the developers who built the system.
Write the handover period into the contract as well, together with what a working build environment means for your system.
If the firm that built it stops trading
If the repository, the accounts and the credentials are already yours, a new team can take the system over. That is the main protection.
Software escrow is the other common answer. An independent third party holds a copy of the code. It releases the code to you when a trigger event named in the agreement occurs, such as the supplier's insolvency or the end of support. One guide says escrow is usually worth it for business-critical applications and may be unnecessary for low-risk internal tools. Another notes that it adds little when the code is already assigned to you and kept in your own repository. The code is released only under the conditions written into the agreement, so ask your lawyer to read them.
Ownership and the support contract
Ownership also decides how free you are after go-live. A Turkish guide on maintenance contracts makes two points. Ending the maintenance contract should not change the handover. When the handover terms are not defined, the maintenance contract can turn into a hidden dependency over time. Staying with the supplier should be your choice.
A supplier may handle personal data for you, for example in a live database, a data migration or support work. A UK guide notes that in that case Article 28 of the UK GDPR requires a written contract with specific terms. Ask your lawyer what applies in your country.
Questions to ask before you sign
- Who owns the code, the data and the documentation, and from what date?
- In whose name are the repository, the hosting and the domain?
- What does the handover include, and how long is the handover period?
- Which parts are third-party or open source, and under which licences?
- What changes if we end the support contract?
- Is escrow offered, and what releases the code?
How we handle it
For the custom systems we build, the code, the data and the documentation are yours, and your team can change the system without us. Handover is priced into the work. A support agreement after go-live is your choice: because the code and the documentation are yours, your own team or another firm can take the system on. The stages are described on our custom software page and on How we work.
For our AI CRM and our ERP, which are products, your data is yours and ownership is agreed per engagement.
If you are planning a custom system and want the ownership and handover terms clear from the start, write to us.