Part IV After launch: operations, further development, independence
Chapter 24: Vendor lock-in and switching vendors
Vendor lock-in is a situation in which you cannot replace the vendor without disproportionate costs. To some extent, it is natural. The goal is to keep it within acceptable limits. Your safeguard is a continuously updated exit package with the rights, code, documentation, data, and access, which you test once a year; source code escrow is only an emergency brake in case the vendor goes bankrupt or fails to perform over a long period.
Vendor dependency is the rule, not the exception
In Czech public procurement, the Datlab Institute found 910 relationships between public authorities and vendors in vendor lock-in, worth roughly CZK 8.5 billion a year. That is about 53% of the analyzed government spending on IT vendors, and the dependency affects 13 of the 15 ministries Datlab Institute, 2021. The Supreme Audit Office (NKÚ) writes that dependency “significantly increases costs” and leads to a decline in IT competence on the government side NKÚ, Annual Report 2021. Companies have the same problem; it is just that nobody measures it.
Lock-in is like a car that only one garage is allowed to service. The garage sets the price, and when you want to go elsewhere, you find out that it also has the keys and the service book. You can recognize it when:
- every change is more expensive than the last one, and nobody can say why,
- tenders for further development end with a single bid (in government IT contracts, these have accounted for more than 20% of the volume since 2017 Datlab Institute, 2021),
- the vendor refuses to hand over the code, access, or documentation,
- you do not know the structure of your own data,
- nobody knows how much moving elsewhere would cost.
| Kind | How to recognize it | How to prevent it | How to get out of it |
|---|---|---|---|
| Legal | you are not allowed to give the system to another company for modification | a license with the right to modify and to transfer to a third party | a later transfer of rights or a license for modifications |
| Technical | a closed platform, integrations only through the vendor | widely used technologies, modules, documented APIs | open up the interfaces, replace module by module |
| Knowledge | only one person knows the system, onboarding takes months | documentation as a condition of acceptance, an annual handover test | workshops and shadowing during a transition period |
| Data | you pay for data from your own system | free export in an open format, a documented data model | negotiate an export, data migration as a separate project |
| Cloud | moving elsewhere means a rewrite | containers, standard databases, accounts in your name | Data Act time limits, rewrite proprietary services |
Go through them once a year as a checklist. Chapter 11 describes how to prevent dependency in the contract, and chapter 15 covers the choice of technologies.
Paying for data from your own system (MMR, NKÚ 2018)
The Ministry of Regional Development (MMR) is the administrator of the Public Procurement Information System (ISVZ), but it had access to the system’s data in aggregated form only for a fee. Since 2002, the system had been modified and operated by the same vendor. When NKÚ needed the data for an audit of centralized procurement, the ministry did not provide it: according to the ministry, it would have had to pay the external vendor about CZK 150,000 for it. NKÚ described this as vendor lock-in, which the ministry had not reduced by the end of the audit NKÚ, audit conclusion KZ 17/24.
The lesson: the right to a free export of your own data in an open format belongs in every contract.
Source: NKÚ, audit conclusion KZ 17/24
You get out step by step, not in one leap
Replacing the vendor completely is the last and most expensive step. Both Datlab and the methodology of the Public Procurement Association (AVZ) recommend starting with the cheapest thing that reduces the dependency AVZ, 2023:
- a partial transfer of rights or a license for modifications,
- handover of the code and documentation,
- transfer of know-how,
- opening up the interfaces,
- splitting the system into modules and replacing them gradually,
- only at the very end, a complete replacement.
When should you act? According to Datlab, when the costs exceed those of comparable services to such an extent that moving to another provider or a new system pays off in the medium term, say within 7 years Datlab Institute, 2021.
You agree on the exit plan in the contract (chapter 11). In practice, you then keep it up to date: update the handover package with every release, and once a year have an independent party test it. An audit at handover primarily verifies whether the system can be built, deployed, and modified from the materials delivered. It also checks whether the code handed over matches the version running in production.
Source code escrow is an emergency brake, not a way out
Escrow is a three-party contract: the vendor deposits the code with a third party, which releases it if the vendor goes bankrupt or fails to perform over a long period. It helps if the vendor goes under. If the vendor is just expensive or slow and you want a different one, you usually will not meet the release conditions. Even released code may not be usable if:
- the deposited version has not been updated for years and does not match production,
- nobody has verified that it can be built,
- a license for modifications by a third party, the documentation, and the data are missing.
Also expect vendors to stipulate in the contract that they are not liable for parts that another company has modified. So agree in advance that the warranty remains valid for the untouched parts and that changes are traceable in Git. The main safeguard remains the continuous handover of the code and rights.
Cloud: the Data Act only goes halfway
The EU Data Act has applied since September 12, 2025, and gives you the right to switch to another cloud provider within clear time limits (Article 25): a notice period of no more than 2 months, the switch itself within no more than 30 days, or up to 7 months if it is technically unfeasible, and then at least 30 days to retrieve your data. Until January 12, 2027, switching charges may cover no more than the direct costs. After that, they are to be abolished, including data egress charges Data Act, Art. 29.
There are, however, two important limitations. For services largely custom-built for a single customer, the ban on charges and the obligation of functional equivalence do not apply, but the time limits do (Article 31). So for custom software, the Data Act protects you only partially. It helps most with the standard cloud services the system runs on. And the proprietary services of a particular cloud have to be rewritten when you leave anyway. So build from portable parts (chapter 15) and plan large migrations for after January 12, 2027.
ADIS: thirty years of exclusivity and the question of who is to blame (GFŘ, 1992–2026)
ADIS, the Czech tax administration’s information system, was supplied by IBM under a contract that the Ministry of Finance (MF) concluded in 1992. In 2016, the General Financial Directorate (GFŘ) awarded post-warranty service worth CZK 33.3 million excluding VAT in a negotiated procedure without prior publication (JŘBU), citing IBM’s exclusive rights. The Office for the Protection of Competition (ÚOHS) imposed a fine, and the regional court upheld it in 2021.
The Court of Justice of the EU (CJEU) then clarified that the contracting authority is responsible for exclusivity even when it maintained it although it had “real and financially reasonable means” to end it CJEU, C-578/23. In February 2025, the Supreme Administrative Court (NSS) set aside both the regional court’s judgment and the ÚOHS decision: the 1992 contract cannot be attributed to GFŘ, and the fact that IBM refused to transfer the rights in 2015 is relevant to the assessment NSS, 8 As 314/2021. ÚOHS reconsidered the case and, in May 2026, imposed final fines on GFŘ totaling CZK 1.45 million for services related to ADIS (CZK 1.95 million including another proceeding concerning the VEMA system) ÚOHS, May 15, 2026.
The lesson: the customer is responsible for the consequences of being passive. If you want to defend a dependency, you must prove that you genuinely tried to end it. It is better to obtain the rights and code, even after the fact.
Source: NSS, 8 As 314/2021-123, ÚOHS on CJEU judgment C-578/23, ÚOHS, press release, May 15, 2026
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrongA license for use only; the code “remains our know-how.” | How to do it rightA license with the right to modify and to transfer to another company, the code continuously in your repository. |
| How it goes wrongAn exit plan as a paragraph in the contract that nobody has ever opened. | How to do it rightAn exit package updated with every release and tested annually by an independent party. |
| How it goes wrongData available only through the vendor or for a fee. | How to do it rightExport in an open format at any time and free of charge, a documented data model. |
| How it goes wrongCloud accounts, app store accounts, and domains held in the vendor’s name. | How to do it rightAll accounts in your name; the vendor has only delegated access. |
| How it goes wrongSource code escrow as the solution to dependency. | How to do it rightEscrow only as a rescue in case of bankruptcy or long-term failure to perform, with a verified build; the main safeguard is the handover of code and rights. |
| How it goes wrongSwitching vendors all at once, without an audit or parallel running. | How to do it rightAn audit, a selection with full documentation, a transition period with parallel support, replacement of all access credentials. |
- For a public authority, dependency is also a legal problem. A JŘBU justified by exclusive rights holds up only if the exclusivity objectively exists and the contracting authority neither caused it nor could reasonably remove it NSS, 5 Afs 42/2012. After the ADIS case, you must also prove that ending the dependency was not realistic or would have been disproportionately expensive.
- Prevention is legitimate, but it must be justified. In 2020, the chair of ÚOHS upheld the Ministry of Transport’s requirement for the economic rights and source code of an HR system ÚOHS, R0215/2019. The Regional Court in Brno set his decision aside on April 25, 2024, and on June 16, 2025, NSS dismissed the cassation complaint: you may require the code, but you must justify that the requirement is proportionate epravo.cz, 2026.
- Source code escrow does not solve dependency. If you could have obtained the code and rights at a reasonable price and did not do so, the courts may attribute the vendor’s exclusivity to you.
- Methodologies: the Digital and Information Agency (DIA) on vendor lock-in DIA, Vendor lock-in methodology and on disadvantageous contract terms DIA, Disadvantageous clauses, and AVZ with its step-by-step guide to measures (Krokář opatření) AVZ, 2023.
- In the higher-obligations regime of the Cybersecurity Act, an exit strategy is a mandatory part of the contract with a significant supplier Decree No. 409/2025 Coll..
- Choose cloud services from the Cloud Computing Catalog Decree No. 505/2025 Coll.. The catalog changes; for example, the offerings of SAP SE were removed from it on March 12, 2026 DIA, cloud catalog. So even with the cloud, you need an exit plan.