Vendor lock-in

Vendor lock-in describes the economic and technical dependency of a customer on a single provider, which makes switching to a competing product disproportionately expensive, risky or time-consuming. The term originates from IT economics and is central in the B2B software context (SaaS platforms, ERP systems, shop systems, cloud hyperscalers) because once an architecture investment has been made, it is often set up for five to ten years.

How vendor lock-in arises

Lock-in is rarely the result of a single decision. It arises in layers, often as a side effect of convenience. Three levers typically run in parallel and reinforce each other.

The first is the data lever. As soon as business-critical data (order histories, customer profiles, configuration and contract logic) is stored in a provider's proprietary data model, an exit is no longer just a technical migration, but a data reconstruction. Data export functions sound like freedom on paper, but in practice they usually only export the raw data, not the relationships, segments and derived fields built up in the system. Anyone who has spent three years curating HubSpot lead scoring or Salesforce validation rules not only has data records, but also ingrained logic that doesn't come along in a CSV.

The second is the integration lever. With every third-party system that has been trained on APIs, webhooks or data formats of the provider, the bill of exchange increases. This is the typical point at which lock-in risk is underestimated in midmarket architectures: it is not the core system that is at the centre of the damage, but the dozen integrated tools around it, all of which are built on the API form of the current provider.

The third is the personnel lever. Once a team has built up several years of expertise on a specific platform (Salesforce Apex developers, Shopify Liquid theme specialists, SAP consultants), the switching costs are not just code, but knowledge transfer. External agencies that are familiar with the replacing platform cost in the learning curve. Internal employees need to be retrained or replaced. For rare specialisations, the market is also thin and expensive.

The four typical appearances

Vendor lock-in is not a uniform phenomenon. In practice, there are four types, each with a different outcome.

Data lock-in

Data is stored in a schema that only exists with this provider. Data models such as Salesforce's custom objects, Shopify's metaobjects or SAP's IDocs are so specific that a 1:1 export to a neutral format is practically impossible. The typical consequence: migration does not mean "moving data", but "interpreting and re-modelling data".

API and format lock-in

A platform defines its own interface conventions to which integrations must adapt. If the provider cancels API versions or changes rate limits, integrations are cancelled without warning. Consequence: every integration is a bet on the long-term API stability of the provider.

Ecosystem lock-in

The provider offers a bundle of several products whose value lies primarily in their integration with each other. Examples: the Salesforce suite (Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud), Microsoft 365, the Adobe Experience Cloud ecosystem. Once you use two or three modules, you pay an increasing switching price because each individual replacement cancels out the bundle synergies.

Contractual lock-in

Multi-year contracts with upfront commitments, minimum terms or revenue-based licences bind customers even if the technology could be easily replaced. Here, the lock-in is not in the code, but in the paper.

Why vendor lock-in is particularly relevant for SMEs

In the corporate environment, vendor lock-in is often accepted as a calculated risk: Sheer size makes for negotiating power, and replatforming budgets in the double-digit million range are feasible in exceptional cases. In the SME sector, this equation is reversed. A fast-growing company whose licences scale according to turnover pays twice for every success. Salesforce Commerce Cloud, for example, licences for B2C via a percentage of the GMV (according to Salesforce list rates 1% Starter, 2% Growth, 3% Plus). Anyone growing to a GMV of 50 million euros is already paying 750,000 euros per year in platform fees at 1.5%, regardless of whether the platform has created new value this year.

At the same time, SMEs lack the internal specialist pools that corporations use to partially cushion lock-in losses. An 80-person company cannot afford a permanent Salesforce architect pool that remains in-house when the platform is changed; tying an external agency to the migration is the norm, with the corresponding risk premiums.

Concrete example: Shopify and the theme investment

A typical lock-in pattern from the D2C midmarket: A shop starts on Shopify with a slightly customised standard theme. Over the course of two to three years, customisations grow into complete custom themes with hundreds of hours of frontend work, written in Shopify's own template language Liquid. Apps from the Shopify app shop are deeply integrated, often with data models that only make sense within the platform. Customer service workflows run on Shopify Flow, which doesn't exist anywhere else.

When switching to an open system such as Shopware 6 or a headless setup with MedusaJS, the problem is not primarily the data migration (orders and customers can be exported), but the reconstruction of the logic that has grown over the years. Realistic migration project: twelve to twenty-four months, depending on the depth of customisation. This period is the real cost of lock-in.

Strategies to avoid vendor lock-in

Lock-in is not binary. There is no architecture that is completely vendor-agnostic, and there are rarely good reasons to consistently avoid every source of lock-in. The question is not "if", but "how much" and "at what point". Three pragmatic levers:

• Open source foundation at the right layer. The platform/runtime (Linux, PostgreSQL, Node.js, PHP, Redis) and the application system (Shopware 6, Mautic, EspoCRM, Strapi) are the layers with the greatest lock-in leverage and at the same time the ones with mature open source alternatives. Your own business logic is yours by definition.
Data sovereignty by default. Business-critical data belongs in a database whose schema you can control and export. Vendor-specific custom objects are a lock-in risk that is cheap to avoid in the early stages, but expensive to repair in the later stages.API abstraction layers. If third-party systems are bound to a provider API, it is worth having a separate abstraction layer (adapter pattern, separate service layer) that encapsulates the direct binding. The initial complexity pays for itself many times over with the first change.

A fourth heuristic from practice: Buy in commodity functions, control differentiation functions yourself. Transactional mail (via an IP reputation provider), code hosting or DNS are pure commodities. Lock-in here costs little because migration is simple. Business model-defining functions (shop logic, pricing, customer data model) belong in a stack that you control.

The AI effect on the lock-in invoice

Since the widespread availability of production-ready coding agents (Claude Code, Cursor, GitHub Copilot Coding Agent), the economic balance between proprietary and open systems is shifting. The historically most important advantage of proprietary SaaS platforms, that the maintenance burden is borne by the provider, is increasingly being equalised by AI-supported maintenance on open source stacks. If a coding agent processes dependency updates, CVE patches and refactors largely automatically, the ongoing maintenance bill of a self-operated open system is reduced by a third to a half. This makes the price of lock-in (limited negotiating position, GMV-dependent licence, provider pivot risk) clearly legible for the first time in a long time.

Historical context: where the term comes from

The term vendor lock-in was coined in the mid-1990s in the context of mainframe and enterprise software markets and became widely recognised with the rise of Microsoft's Office dominance, IBM's DB2 and Oracle's relational databases in the late 1990s. The term was popularised by Hal Varian and Carl Shapiro's influential book Information Rules (1998), which described lock-in effects as an economically rational strategy both for providers and (within limits) for customers. The core insight of this book is still relevant today: Lock-in is not a market failure per se, but an expected result of switching costs that providers can strategically utilise and customers can consciously enter into. In the cloud and SaaS era (from around 2010), the term has shifted: away from software licences and towards data sovereignty and API binding.

Differentiation from related concepts

Vendor lock-in is often confused with two related but different concepts.

Switching costs are the economic measure that every switch entails, even between two completely interchangeable vendors. Lock-in occurs when these switching costs are so high that an economically rational change of provider does not take place, even though it would make strategic sense.

Network effects describe the increase in value of a platform through each additional participation (e.g. social networks, marketplaces). They can reinforce lock-in, but are conceptually different: a network effect rewards staying, a lock-in penalises switching.

Path dependency is the broadest of the three terms and generally describes the historical conditionality of current decisions. Lock-in is a concrete case of path dependency that relates to a specific supplier relationship.
Practical checklist before every major SaaS contract

Five questions that should be answered before every multi-year software commitment:

1. What do the data export functions look like? Not just "is there an export", but: in which format, which fields, which relationships, which derived logic is also exported?
2. Which APIs are officially guaranteed stable? Does the provider version cleanly, how long is the deprecation window for API versions?
3. Which licence models scale with success? GMV-, user- or transaction-based models mean that your growth rewards the provider, factor in fairly.
4. How large is the pool of specialists on the market? Niche technologies mean expensive experts and more difficult agency changes.
5. Are there realistic migration paths? If no reference migration of a comparable size is publicly documented, this is a warning signal.

These questions cost little in the evaluation phase and often save years of pain. If you don't ask them, you will pay for them later in the replatforming bill.

Frequently asked questions about vendor lock-in

Is open source automatically free from lock-in?
No. Open source stacks also generate switching costs. If you live in a Magento 1 custom code base for five years, you have similar replatforming problems as a SaaS customer. The key difference is the negotiating position: no one can take away the source code, change the data model or invent a licence that you no longer fulfil.

How much switching costs are "normal"?
For medium-sized e-commerce platforms, the usual order of magnitude is twelve to twenty-four months project duration and engineering costs in the high six- to seven-digit euro range. These figures are not fixed market averages, but patterns of experience from projects with custom logic of medium depth.

When does accepted lock-in make economic sense?
When the platform provides functions that would be significantly more expensive to develop in-house and when your own business model does not come under pressure from GMV-scaling licences. Standard example: small shops with low custom depth often benefit from Shopify; as soon as turnover reaches three-digit thousand euro months, the calculation tips over.

What role does composable commerce play?
Composable Commerce is an architectural response to lock-in risks: instead of a monolithic platform, best-of-breed components are orchestrated via open APIs. This means that every component can be replaced in principle without having to rebuild the entire system, albeit at the cost of greater architectural complexity.

Which external standards reduce lock-in?
Wherever open standards are on a par with proprietary interfaces, the standard is worthwhile. In the e-commerce context, these are primarily REST/GraphQL APIs, the JSON-LD format for structured data and standards such as OpenAPI for API documentation. For cloud infrastructure, container standards (OCI) and Kubernetes are among the most important lock-in minimising standards.