Vendor lock-in with custom software means you can no longer switch supplier without serious cost or risk, because the code, the knowledge or the environment effectively sits with that supplier. You prevent it before the first line of code: agree what is yours and make sure everything lives in your own accounts from day one.
This article covers what lock-in looks like, what to agree in the contract and the way of working, which safety nets work, the signs that you're stuck and how to switch.
What vendor lock-in looks like in custom software
Most people think of lock-in as a cloud problem. In custom software it more often sits in the agreements and habits around the code. A customer portal can be well built and still impossible to move, because nobody outside the supplier knows how to build and release it.
| Type of lock-in | What it looks like | Example |
|---|---|---|
| Legal | The supplier keeps the rights, you get a limited right of use | Another agency may not change your ERP integration |
| Technical | The application runs on the supplier's own framework | Your planning app relies on an internal base package without source code |
| Knowledge | No documentation, the knowledge sits in a few heads | Nobody else knows how the webshop calculates prices |
| Operational | Repository, cloud, domain and app store account are in their name | No update of the field-service app without their account |
| Data | Data only through the supplier or in their own format | An export from the customer portal takes a quote and three weeks |
Operational lock-in is often the most stubborn. You can renegotiate a contract, but not a domain name registered to a supplier you've fallen out with. If you build on a low-code platform or a supplier's own platform, your application also depends on that platform's runtime and licence. See low code vs custom software for when that's a fair trade.
What to put in the contract before any code exists
Ownership or licence of the source code
The Dutch Copyright Act (Auteurswet, in Dutch) names computer programs and their preparatory material as protected works (Article 10). For work done in employment, the employer counts as the author (Article 7). If a supplier builds your software with its own developers, the supplier is the author, not you. A transfer of copyright requires a written agreement and is made by a deed drawn up for that purpose (Article 2(3)).
With a licence instead of a transfer, make sure it is perpetual, transferable if your company is sold, includes the source code and lets another party or your own team change the code. For libraries the supplier reuses across projects, such a licence is a fair solution.
General terms
NLdigital (in Dutch) says more than 3,000 IT companies use the NLdigital Terms. They apply only where the parties have not made explicit written arrangements to the contrary (Article 1.2 of the 2025 version). For the transition to a third-party supplier or to you, the supplier endeavours to cooperate with exit activities at its applicable rates (Article 8.5). It only performs data conversion if that was explicitly agreed in writing (Article 8.6). If you want more, put it in the agreement.
Third-party licences and exit terms
At every delivery, ask for a list of third-party components, such as libraries, a paid PDF module or a maps service, with their licences and registered owner. A licence in the supplier's name doesn't move with you. Add the supplier's own framework too, with what you may do with it afterwards. Agree how many hours of knowledge transfer you get at exit, and at what rate. Include documentation, scripts and tests in your acceptance criteria, so "done" also means "transferable".
The way of working from day one: everything in your name
Much lock-in starts in week one, when someone sets up a repository or cloud account "for now" under their own account. Agree that you own the accounts and the supplier gets access.
| Item | What you agree | How you check it |
|---|---|---|
| Code repository | In your company's organisation on GitHub, GitLab or Azure DevOps | You are an administrator and can make a copy yourself |
| Build and deploy scripts | The pipeline is code in the repository, with no manual steps | Someone outside the team deploys a test version using only the README |
| Test suite | Automated tests run on every change | You see the results in the pipeline |
| Documentation | Architecture, setup, integrations and a log of architecture decisions | Lives in the repository and changes with the code |
| Hosting and cloud | Account and billing in your company's name | You can revoke access |
| Domains and app stores | Registrations and developer accounts in your name | You log in yourself |
| Third-party services | Email, payments and monitoring in your name | The API keys sit in your vault |
For architecture decisions, use a short record per choice, as Michael Nygard described it: context, decision, status and consequences. A new team can then read why the ERP integration runs through a queue. What the software should do belongs in the functional design.
Every six months, have someone outside the team build the application from the repository onto a test environment. If they need to phone the supplier, you know what's missing.
Safety nets: data export, the Data Act and escrow
Data in open formats
Agree that you can get a full export at any time in open formats: a dump of a mainstream database, or CSV and JSON with a description of the fields, plus files and documents. A documented API helps with a later migration. Restore the export into an empty environment now and then. An export that has never been restored is a promise.
The Data Act for cloud services
The Data Act has applied since 12 September 2025, and from 12 January 2027 it removes switching charges for data processing services entirely, including charges for data egress, according to the European Commission. Under Article 25, the contract with such a provider must include, among other things, a notice period of no more than two months to start a switch, a transitional period of in principle no more than 30 calendar days, and then at least 30 calendar days to retrieve your data. For a service where most of the main features were custom-built for one customer, some obligations do not apply, including those on switching charges (Article 31). Agreements about the copyright in your source code go in your own contract.
Escrow
With escrow, the supplier deposits the source code with an independent party, and you receive it on an agreed event, such as bankruptcy. That helps when the supplier keeps the code and you depend on it for a business-critical system. It helps little when:
- nobody updates the deposit after each release;
- build scripts and documentation are missing, so nobody can build the code;
- your problem is a slow or expensive supplier, which usually falls outside the agreed events;
- the code is already in your own repository.
If you choose escrow, have a third party check periodically that the deposited code can be built.
Signals that you're already locked in
- Only the supplier can release. The pipeline runs on their servers, or there isn't one.
- You don't have your own copy of the code. Or you have a zip file from two years ago.
- Every question about how it works becomes a quote. Even how the webshop calculates prices.
- The cloud invoice comes through the supplier. You don't know what runs or what it costs on its own.
- Two developers know everything. When one is on holiday, the roadmap stops.
- A data export takes weeks. Or it only comes in the supplier's format.
- Nobody can estimate what a handover would cost. So nobody has ever priced an alternative.
If you recognise two or more, take the first two steps of the exit plan below, even if you don't plan to leave. Your own access to code, accounts and data also strengthens your hand in the next price negotiation.
An exit plan in six steps
1. Map what you have
For each item in the table above, note whose name it's in and who has access. Put your contract next to it: notice period, exit terms, intellectual property and third-party licences.
2. Secure access before you give notice
Move the repository, cloud accounts and domains into your name while the relationship is still running normally. That's ordinary good management. After notice, every request becomes a negotiation.
3. Have an outsider build the application
Ask a new party or your own developer to build, test and review the application from the repository. The list of gaps becomes your agenda for the handover. If you're choosing a new supplier, read how to choose a software company as well.
4. Plan a handover with overlap
Arrange a period with both the old and new party on board, recorded knowledge sessions per component and a handover of open issues and known bugs. Under the NLdigital Terms the supplier may charge its applicable rates for exit work, so budget for it. If you're taking development in-house, let your own developers make changes while the old supplier still reviews them.
5. Move data and hosting
Make a full export, restore it in a test environment and compare record counts with production. Only then move the hosting.
6. Replace what can't come along, step by step
If you may not keep a framework from the previous supplier, replace it in parts with the strangler fig approach: new components next to the existing system, old parts switched off once the new ones take over. If replacing the application is cheaper than taking it over, read about legacy systems.
Avoiding vendor lock-in with Isatis
Isatis builds custom business software, with teams in Nijmegen, in the Netherlands, and Sarajevo. We've been doing this for more than 30 years, with 30+ engineers and more than 100 projects, and we're certified for ISO 9001 and ISO 27001. Our page on custom software development shows how we work.
If you want to set up a new project so that you or another party can carry on later, or you want to know how locked in you are with your current supplier, book a conversation. We'll also tell you when switching would cost more than it brings.
Frequently asked questions
Do I own the source code if I pay for the development?
Not automatically. Under the Dutch Copyright Act, the employer counts as the author of work made in employment, so when a supplier builds with its own developers, the author is the supplier. A transfer needs a written agreement and a deed. A broad licence can also be enough.
Is escrow enough to prevent vendor lock-in?
Usually not. Escrow mainly helps in a bankruptcy, and only if the deposited code is current and can be built. If the code sits in your own repository from day one, you rarely need escrow.
Can I take development in-house later?
Yes, if code, pipeline, tests and documentation are in order and sit in your accounts. Plan an overlap period with the supplier. Choose mainstream languages and frameworks at the start, so it's easier to hire developers later.
Does the Data Act apply to my custom application?
Its switching rules apply to providers of data processing services, such as cloud services. For services largely custom-built for one customer, some obligations do not apply, including those on switching charges. Agreements about your source code go in your own contract.
Should I tell my supplier I'm preparing to switch?
Not at every step. Putting accounts in your own name and asking for a copy of the code is ordinary good management. Read your notice period first, then have an open conversation, because you still need the old supplier for knowledge transfer.
