Avoiding vendor lock-in: what to look out for

Vendor lock-in is the situation in which switching to another supplier becomes so expensive, time-consuming or technically difficult that in practice you no longer do it, even if an alternative is better or cheaper. The risk applies to SaaS packages and cloud platforms, but also, often underestimated, to custom software. This page shows which forms of lock-in exist, how to recognise them before you sign, and which measures actually protect your freedom of choice. Torn between a package and your own platform? Also see our build-vs-buy assessment.

Vendor lock-in Data portability Open standards Exit strategy SaaS risk
Discuss your situation Go to the checklist

What vendor lock-in is and why it matters

Vendor lock-in doesn't arise on the day you sign a contract, but in the years afterwards, as data, processes and team knowledge accumulate within one supplier. At that point the balance shifts: you no longer decide whether to stay; the costs and risks of leaving decide for you. It is most evident with SaaS packages (CRM, ERP, HR systems) and cloud infrastructure, but at least as often with custom software whose architecture only the builder understands.

Why is this more than a theoretical risk? Three reasons come up most often in practice. First, negotiating position: a supplier who knows that switching is unrealistic has little incentive to keep prices sharp. Second, agility: if a new business process or integration doesn't fit within the limits of your current system, you can't simply switch to make it possible. Third, continuity: suppliers get acquired, discontinue a product line or change their roadmap; without an exit option, you carry that risk entirely.

Build vs buy software Low-code vs custom development Custom software costs

Four forms of vendor lock-in

Lock-in is not a single, uniform risk. It arises at four different layers, and each layer calls for a different measure.

Data lock-in

Years of administration, reports and customer records end up stored in a system that offers no usable export, or only in a proprietary, undocumented file format. Without re-entering that data manually, you cannot leave.

Technical lock-in

Proprietary architectures and closed formats make integration with other systems difficult. A counterexample shows how it can be different: the Amazon S3 API has become the de facto standard for object storage, which makes S3-compatible storage from other providers possible without rebuilding everything.

Contractual lock-in

Long contract terms, high termination fees, or no clause on data transfer when the contract ends. This lock-in is not technical but purely contractual.

Knowledge lock-in with a single party

The architecture, code and workings of a system sit only in the head of one vendor or development partner. This is most acute with custom software that has no handed-over documentation; we go into this in more detail below.

Build vs buy software Information security policy

Signs you are already locked in

Four questions that, in practice, quickly show how tied you are to your current supplier.

No usable export

You can only view data within the system itself, not export it in a standard format such as CSV or JSON.

Unilateral price increases

The supplier raises prices without you having a realistic alternative within a reasonable timeframe.

Nobody else understands it

There is no up-to-date documentation, and the knowledge of how the system works rests with one person or party.

Penalties for leaving

Termination fees or data transfer charges that bear no relation to the actual effort involved.

Custom software can also create lock-in

Custom development is often presented as the answer to vendor lock-in: no package, so no dependency. That is not automatically true. If you do not own the source code, if there is no current architecture documentation, or if only one small development firm truly understands the application, you are just as tied in as with a SaaS package. The only difference is that your supplier is now called a development partner rather than a software vendor, and the dependency is often less visible because there is no annual licence invoice to remind you of it.

Therefore, with every party that builds for you, whether that is us or another partner, ask the same questions you would ask a SaaS supplier: who owns the source code and documentation, does the codebase use mainstream, widely adopted technology rather than a uniquely self-built framework, is there up-to-date technical documentation that another party could take over, and what concretely happens if the collaboration ends. With low-code platforms, a similar risk exists at platform level: Mendix, OutSystems and Power Apps offer speed, but the application you build runs within their runtime and licensing model. Unsure whether low-code or custom development suits you better? Read our comparison of low-code and custom development.

Low-code vs custom development Custom software consultancy

Practical measures to prevent lock-in

None of these measures is a guarantee, but together they reduce the chance that you will ever be stuck without an alternative.

Choose open standards

Where possible, choose systems with open, documented APIs. The S3 API is a good example: because it became the de facto standard for object storage, you can use S3-compatible storage from several providers without rebuilding everything.

Demand data portability

Ask for export in common formats such as CSV, JSON or Parquet rather than a proprietary format. For personal data processed automatically on the basis of consent or contract, you also have the right to data portability under Article 20 of the GDPR in the EU.

Record exit arrangements

Reasonable notice periods and, where the impact of departure is significant, a source code escrow agreement: the source code is deposited with an independent third party and released if the supplier stops or no longer meets its obligations.

Make documentation a delivery requirement

Architecture documentation, data model and API specification should form part of the delivery, not a loose attachment that only arrives later. Without that documentation, every change of supplier costs more than it needs to.

Information security policy Build vs buy software

Checklist for a new software partner or package

Five questions to ask before you sign, whether it's a package, a SaaS subscription or a custom development project.

Export without intervention?

Can you export your data in a standard format without depending on the vendor's cooperation?

Who owns it?

With custom development, do you own the source code and documentation, or are you only licensed to use the result?

What does leaving cost?

What are the notice periods, and what costs are involved in switching to another provider?

Is there documentation?

Is there up-to-date technical documentation that another party could actually take over?

If you don't receive a satisfactory answer to any of these questions, that isn't necessarily a reason to walk away from the partnership, but it is a signal to set the agreements down more precisely in advance rather than trusting that it will all work out.

Frequently asked questions about vendor lock-in

What is vendor lock-in?
Vendor lock-in is the situation in which the cost, effort or operational disruption of switching to another supplier becomes so high that, in practice, you no longer choose to do so, even when an alternative is objectively better or cheaper. It arises with SaaS packages, cloud infrastructure and custom software alike.
What are the main forms of vendor lock-in?
Four forms occur most often: data lock-in (data that cannot be exported in a usable way), technical lock-in (proprietary formats and architectures), contractual lock-in (long terms and high exit fees) and knowledge lock-in (only a single party understands how the system works).
Can custom software also cause vendor lock-in?
Yes. If you don't own the source code, no up-to-date documentation exists, or only a single development agency understands the application, the same dependency arises as with a SaaS package. Therefore always ask about source code ownership, documentation and the technology used.
What is the right to data portability under the GDPR?
Article 20 of the GDPR gives data subjects the right to receive the personal data they have provided, which is processed automatically on the basis of consent or a contract, in a structured, machine-readable format, or to have it transmitted directly to another party.
What is a source code escrow agreement?
An arrangement in which the source code of a custom system is deposited with an independent third party. It is released to the customer if the supplier ceases to exist, goes bankrupt, or can no longer meet its maintenance obligations.
How do I avoid lock-in with a low-code platform?
Recognise that a low-code application runs within the platform's runtime and licensing model, even though you build the logic yourself. Ask about export options for your model and data, and for critical processes, consider whether custom development on a common technology would give you more freedom.
Can vendor lock-in be avoided with cloud infrastructure?
Complete avoidance is difficult because every cloud provider has its own services, but you limit the risk by using open standards wherever possible, such as S3-compatible storage, and choosing provider-specific services only where there is a concrete advantage that outweighs the cost.

An independent view of your software architecture

We build custom software and integrations with existing packages, and from the design stage we factor in open standards and data portability, so you won't be locked in when you switch systems in the future.

Book a no-obligation conversation

Edit content