Code ownership: how to avoid vendor lock-in

Code ownership and the ability to change suppliers are different things. You might hold rights to custom code while missing files or access. Conversely, a licence may allow another party to maintain the software under its terms. Look at what you’re legally permitted to do, what you receive and what a successor needs. Our custom software guide places these arrangements within the development process; this article examines handover.

What does code ownership mean legally and practically?

Several questions get mixed together in discussions about ownership. Who holds rights to the software? Who can access its source files? Who can build, start and maintain the application? One answer doesn’t cover all three.

The Dutch government’s copyright guidance distinguishes licensing from transfer: a licence permits use while copyright remains with its holder; transfer moves the agreed rights. Record which arrangement applies to your assignment, which components it covers and under what conditions. This article provides discussion points, not a substitute for reviewing your contract.

Existing libraries and services may have different terms from code written for your project. Open source doesn’t mean there are no conditions. The RVO guide to digital innovation explains that open-source code can be protected by copyright and carries licence conditions. Ask for a list of these components and the terms relevant to use, modification and handover.

Which forms of dependency should you distinguish?

Dependency isn’t automatically a bad choice. You might deliberately choose a managed service because your team doesn’t want to operate it. What matters is understanding the options that remain and the work involved in a change.

Area	Possible problem on departure	What should you ask beforehand?
Rights	Unclear whether a successor may make changes	Which rights apply to which code?
Source files	A component is missing or inaccessible	Which version and supporting files will be supplied?
Dependencies	A private library or paid component is missing	How will it remain available, and on what terms?
Data	Export omits attachments or record relationships	What does the export include, and how is it checked?
Environment	Settings exist only on the current server	How are the environment and installation documented?
Knowledge	Only the original developer knows unusual procedures	Which decisions and maintenance tasks are recorded?

A familiar framework doesn’t prove this is arranged well. The application may still reference an unavailable library or manually configured server. Conversely, a specialist component needn’t be an insurmountable problem if another party has access, rights and documentation.

Examine integrations too. Another maintainer needs to know which data is exchanged and how failures become visible. Our guide to connecting software helps identify those business rules. A list of API keys isn’t enough.

What should you agree before the project starts?

Request a description of the deliverables. Name the custom code, documentation and configuration, as well as anything excluded from handover. A supplier might offer a reusable component under a separate licence, for example. Clarify what that means if someone else maintains the application later.

Discuss access for each service. Who can recover accounts for your business, inspect charges and grant access to a new maintainer? That needn’t mean giving every employee administrative permissions. Nominate an authorised person and arrange a usable recovery procedure suited to the service.

Also agree on assistance at termination: which information will be supplied, how it will be transferred and how additional work will be estimated. Set time limits that fit the process and contract. Choosing your own deadline doesn’t automatically make a claim enforceable.

How do you test whether the handover package is usable?

Have an authorised developer who doesn’t work on the application daily run a trial in an isolated test environment. The aim isn’t to leave immediately. It’s to find missing information while the current supplier can still help.

Provide an identified software version, installation instructions, required components and suitable test data. Agree which tasks the trial must demonstrate. Can the developer start the application, sign in with different roles and complete a relevant operation? Record any extra verbal explanation required and add it to the handover material.

Take a hypothetical example: a quotation application starts after handover but won’t produce PDFs. Its templates turn out to be stored outside the supplied code. The finding isn’t that all the code is useless. It’s that the templates and settings need adding and retesting. A successfully loaded homepage would have missed that.

Also test a recovery operation that matters to your process. Reversing an incorrect import needs different information from installing a release. Agree who assesses the results and which gaps must be resolved first. A trial only helps if someone follows up its findings.

Which data and accounts need separate attention?

A source-code copy doesn’t automatically contain current business data. Establish what’s in the database, where files live and which information sits with other services. Check attachments, references and field meanings in an export. A file that opens isn’t the same as data a successor can use correctly.

List services with a responsible person, required roles and a route for recovering access. Include domains, hosting, email, payments and other services in use. Check with each supplier what transferring or replacing an account actually involves.

Secrets such as API keys and passwords need secure handover. Don’t place them in a general document or source code. Agree who issues new access and when old access will be revoked. A change of supplier may require replacing keys; plan this so integrations keep working.

Deleting data on departure also needs agreement. Distinguish working files, backups and information subject to retention obligations. Have the relevant parties determine what may or must be retained. A blanket promise that every copy disappears immediately can overstate what’s possible.

How do you switch when dependency already exists?

Start with an inventory, rather than shutting down the current environment. Gather the contract, available files and an overview of systems and contacts. Ask a successor what needs investigating before they can take responsibility.

Then make a handover plan with checkpoints. When can the new environment be assessed? How will recent data changes be included? Who authorises the switch, and what happens if a check fails? These answers determine the sequence and schedule.

Running two environments for a period can help, but requires clear rules about where changes happen. Two independently updated databases don’t create a simple fallback. Describe how data stays consistent and what returning to the previous environment would mean in practice.

Budget for investigation, transfer and any changes required. Our custom software cost guide separates one-off work from recurring maintenance. No universal migration figure can reliably account for missing information or unusual technology.

When might escrow still have a role?

Software escrow may be relevant for materials you don’t receive directly or for a specific continuity arrangement. It concerns safekeeping and access under agreed conditions. Examine which dependency it addresses and which remains.

Source code might become available while a necessary external service remains unavailable, for example. Safekeeping alone then isn’t a recovery plan. Assess the arrangement against the application you need to continue, rather than a fixed project-budget threshold.

With TopDevs, the custom code is and remains yours, with technical documentation and handover. You still need specific arrangements for data, access and services. Ownership isn’t a promise that every future switch will be effortless or free.

How do you actually get started?

Make one list with three columns: what you need, what’s demonstrably available and what still needs investigation. Start with an important application task and follow the code, data and services involved. Ask the responsible party to fill in the gaps.

If you’re commissioning custom software development, discuss these points before the assignment. For an existing application, use them to define a handover trial. Book a call to examine the technical dependencies.