Vendor lock-in

Vendor lock-in refers to a situation of dependence on a single supplier, where switching to an alternative is only possible at disproportionate effort, high cost or considerable risk. Vendor lock-in arises from proprietary formats and interfaces, contractual obligations, well-established processes, and data sets that cannot be transferred without loss. The result is a weakened negotiating position and limited ability to act on the part of the dependent organisation.

What is vendor lock-in?

Vendor lock-in is a situation in which an organisation’s switching costs are so high that changing suppliers is practically out of the question – even if there are objective reasons for doing so. The term originates from information economics, where switching costs have been described as a key market mechanism since the 1990s: the higher they are, the greater the supplier’s leeway in terms of prices, terms and conditions, and product decisions.

Switching costs encompass far more than just the cost of migration. They include the effort involved in data migration, the loss of historical data and links, downtime during the transition, training and induction, the adaptation of interfaces to other systems, project risk and the loss of investments already made. In many organisations, it is not the technical but the organisational switching costs that dominate: processes, roles and habits are tailored to a specific product.

It is important to distinguish between dependency and vendor lock-in. Any use of an external service creates dependency – this is the price of the division of labour and is not a fault. Vendor lock-in only exists when this dependency can no longer be broken. The crucial criterion is therefore not ‘Are we dependent?’, but ‘How long would a switch take, what would it cost, and have we ever assessed this?’.

What types of vendor lock-in are there?

Vendor lock-in takes several forms, which overlap and must be addressed in different ways:

Type	Cause	Typical signs
Technical lock-in	Proprietary interfaces, protocols and services with no equivalent offered by other providers	Functions can only be run within a single platform
Data lock-in	Proprietary formats, incomplete exports, missing metadata and history	The export provides raw data without any structure, links or permissions
Contractual lock-in	Long contract terms, bundling, tiered discounts, notice periods, licence metrics	Phasing out the scheme is theoretically possible, but economically unattractive
Process and knowledge lock-in	Processes, training and certification tailored to a specific product	Staff are only proficient in one platform; processes are tailored to them
Ecosystem lock-in	Integration of multiple products from the same supplier	Changing one component leads to changes in other systems
Cost lock-in	Fees for data export and migration support	The withdrawal will incur costs that are not provided for in the budget

Data lock-in is the aspect most frequently underestimated in this context. A contractually guaranteed export is of little value if it only provides the user data, but not the structure, permissions, links and time series. In the case of legacy systems with years of history, it is precisely this difference that determines whether migration is possible.

How does vendor lock-in arise?

Vendor lock-in usually does not arise from a single decision, but rather from a chain of plausible individual steps. It typically begins with a choice based on feature set and price, in which switching costs play no role because they lie in the future. Thereafter, the dependency grows with every integration, every data set imported and every process adaptation. Vendors encourage this development through bundling, discounts on additional products and features that cannot be replicated outside their own platform – a move that is economically rational and often initially advantageous from the customer’s perspective.

This effect is reinforced by three patterns. Firstly, gradual deep integration: what begins as a standalone application becomes interwoven with the rest of the IT infrastructure via identity management, data storage and automation. Secondly, the build-up of in-house expertise centred on a single vendor, which means that alternatives are thwarted by a lack of internal know-how. Thirdly, the lack of regular review: switching costs rise quietly over the years without ever being assessed. In practice, therefore, vendor lock-in is usually only noticed once it already exists – typically during a contract renewal, a price adjustment or when a compliance requirement is not met by the provider.

What are the consequences of vendor lock-in?

The most immediate consequence of vendor lock-in is the loss of bargaining power. A supplier whose customer is effectively unable to switch can raise prices, change licensing metrics, alter functionality or discontinue products without having to fear customer defection. Price adjustments upon contract renewals are the norm, and this is where existing vendor lock-in first becomes quantifiable.

The strategic consequences extend further. Vendor lock-in restricts the ability to respond to changes: to new regulatory requirements, to shifting threat landscapes, to technological leaps or to a change in the vendor’s market position. Should the vendor face insolvency, a takeover, product discontinuation or a strategic reorientation, the dependent organisation bears the consequences without having any influence over them. At the level of entire sectors, this gives rise to a concentration risk: if many organisations use the same platform, a disruption no longer has a local impact but a systemic one.

Why is vendor lock-in a security and compliance risk?

Vendor lock-in is a security risk because it removes the option that matters most in an emergency: switching providers. If it transpires that a service is inadequately secured, repeatedly causes security incidents or fails to honour commitments regarding incident response, switching providers is the most effective course of action – provided it can be carried out within a reasonable timeframe. Where vendor lock-in exists, the only option is to negotiate with a provider who knows that their customer cannot leave.

Vendor lock-in also affects compliance. If a legal basis for data transfer ceases to be valid, the legal situation in the provider’s country of incorporation changes, or extraterritorial access powers such as the US CLOUD Act come into effect, the organisation must be able to respond. Regulatory authorities and auditors do not expect a mere declaration of intent here, but rather a robust capacity to act. Without an exit strategy, the only option in case of doubt is to continue operating a service whose GDPR compliance is no longer guaranteed – a situation that no contract can remedy.

Finally, vendor lock-in affects availability. If a service is down for an extended period, a fallback solution is only of use if it has been prepared in advance. This is precisely why modern business continuity plans treat vendor failure as a separate scenario and require documented alternatives rather than contractual availability guarantees.

How can vendor lock-in be avoided or minimised?

Vendor lock-in can be most effectively mitigated at the source: during architectural and procurement decisions. From a technical perspective, open standards, documented interfaces and standard data formats make the greatest contribution, complemented by a loosely coupled architecture in which individual components remain replaceable. Open-source components further reduce dependency because, if necessary, operation and further development can be taken over by third parties – one reason why open source plays a key role in digital sovereignty strategies.

From a contractual perspective, short contract terms, clear termination rights, limits on price adjustments, and explicitly regulated obligations regarding data return and support at the end of the contract are effective. The data processing agreement is not the right place for everything: data return in usable formats, deadlines, and obligations to cooperate belong in the main contract or in a separate exit agreement. From an organisational perspective, it helps to regularly assess switching costs, avoid concentrating knowledge on a single manufacturer and consider the total cost of a solution, including exit costs.

One common response, however, warrants scepticism. Multi-cloud and multi-vendor strategies are frequently cited as the solution, but they increase complexity, costs and the attack surface – and often merely shift dependency to the abstraction layer that enables operations across multiple providers. They make sense where availability or negotiating position justify them, not as a matter of principle.

What should an exit strategy include?

An exit strategy describes how an organisation can leave a service within a defined timeframe, and provides specific answers to four questions: What data and configurations need to be migrated, in what formats are they available, which target environment is under consideration, and how long will the migration take and what staffing resources will be required? This is supplemented by the triggers that would prompt a review of the exit – price increases exceeding a threshold, security incidents, the loss of a legal basis, or a takeover of the provider.

Testing is crucial. An exit strategy that has never been tested is of no more value than an emergency plan that has never been practised: it merely describes a wish. It only becomes effective through practical verification – a full test export with checks for structure and completeness, a trial migration of a partial dataset, or at least a documented cost estimate based on real data volumes. Experience shows that even the first test export reveals whether a provider takes portability seriously or merely makes contractual promises.

Which legal requirements address vendor lock-in?

Vendor lock-in is now the subject of several regulations. The EU Data Act obliges providers of data processing services to actively facilitate switching to another provider: through contractually agreed notice and transition periods, the provision of data in structured, commonly used and machine-readable formats, requirements for functional equivalence in infrastructure services, and the phased elimination of switching fees. This transforms portability from a negotiating position into a legal requirement.

In the financial sector, DORA explicitly requires documented exit strategies for critical ICT services, as well as the assessment of concentration risks; comparable requirements have long been part of regulatory guidelines for outsourcing management. NIS-2 indirectly addresses vendor lock-in through the requirement to secure the supply chain, including the service providers used. In public procurement, the principle of product neutrality under public procurement law also applies; this permits reference to specific brands or procedures in service specifications only in very limited exceptional cases – a tool to prevent the perpetuation of existing dependencies in tender documents. In addition, initiatives such as Gaia-X and the debate around the sovereign cloud are developing interoperability criteria designed to make switchability verifiable.

Is vendor lock-in always a bad thing?

No – vendor lock-in is not inherently harmful, but rather a matter of awareness and proportionality. Deep integration delivers real benefits: better coordination of components, reduced integration effort, standardised support, and often lower operating costs. An architecture that avoids any dependency at all costs pays the price in complexity, interface overhead and a level of functionality that falls short of what is achievable.

The sensible objective is therefore not independence, but a dependency that has been consciously entered into and assessed. Two questions structure this assessment: How critical is the process in question, and how long could the organisation cope with a change or failure? For non-critical applications, a high degree of integration is justifiable. For processes that must function even in exceptional circumstances – identity management, alerting, communication, core business processes – interchangeability is a requirement, not a secondary consideration.

What role does vendor lock-in play in communications solutions?

Vendor lock-in is particularly pronounced in communication solutions because all its manifestations are evident simultaneously. The data set does not consist of documents, but of historical records: messages, group structures, memberships, attachments, timestamps and permissions. An export that provides messages without context is largely useless for audit purposes and for continuing collaboration. Added to this is an internal network effect: a communication solution can only be switched over completely, as parallel operation would disrupt accessibility – the switch is a deadline-driven project placing significant pressure on all parties involved to adapt.

To complicate matters further, end-to-end encryption and exportability are at odds. If the provider cannot read it, it cannot export it at the server level either; migration paths must therefore be resolved on a device-by-device basis or via separately authorised archiving components. For organisations that treat communication as a critical resource, these questions therefore need to be addressed during the selection process, not just when renewing a contract: What export formats are available, what structural information do they contain, how long does a complete migration take, and can the service be transferred to the organisation’s own infrastructure?

In practice, organisations limit their dependence by using solutions that provide open or documented interfaces, enable operation within their own area of responsibility, and deliver the data set – including its structure – in usable formats.

What are the typical mistakes made when dealing with vendor lock-in?

The most common mistake when dealing with vendor lock-in is only assessing the situation once it has already occurred – usually following a price increase or a compliance requirement. Further weaknesses observed in practice include:

• Selection decisions based solely on feature set and entry-level price, without assessing switching costs and the effort involved in exiting
• Export capability contractually guaranteed but never tested – the scope and structure of the export remain unknown
• An exit strategy drawn up as a document but not subsequently maintained, even though data volumes and integrations are growing
• Staff knowledge and certifications entirely focused on a single manufacturer
• Exit costs, such as fees for data extraction and migration support, not factored into the overall cost model
• A multi-vendor approach chosen as a blanket countermeasure, without assessing the additional complexity and attack surface
• Vendor lock-in treated purely as a cost issue, even though it limits responsiveness to security and legal problems

Summary: Key points on vendor lock-in

• Vendor lock-in refers to a situation of dependence on a particular supplier, where switching is only possible at disproportionate effort, high cost or considerable risk.
• The switching costs are crucial: data migration, loss of historical data, downtime, training, interface adaptation and project risk – often the organisational aspects outweigh the technical ones.
• Vendor lock-in takes six forms: technical, data-related, contractual, process- and knowledge-related, ecosystem-related and cost-related.
• Data lock-in is most frequently underestimated because exports often provide only raw data without structure, permissions or links.
• Vendor lock-in is not merely a cost issue: it removes the option to switch providers in the event of security incidents or the removal of legal grounds.
• At sector level, similar dependencies create a concentration risk, whereby a disruption has a systemic rather than a local impact.
• Effective countermeasures include open standards, loosely coupled architecture, short contract terms and regulated return obligations at the end of the contract.
• An exit strategy must specify data, formats, the target environment, duration and triggers – and must be tested, for example through a full test export.
• From a legal perspective, the EU Data Act addresses the interoperability of data processing services, DORA addresses exit strategies in the financial sector, and public procurement law addresses product neutrality in public tenders.
• Vendor lock-in is not inherently harmful: the aim is a deliberately assessed dependency, the permissible extent of which is determined by the need for protection and the criticality of the process.