Cybersecurity & Trust

Vendor Lock-In: How to Spot It Before You Sign

A UK regulator spent two years investigating cloud pricing and found that less than 1% of customers switch provider each year. That statistic describes what lock-in looks like once it has already happened. Here is how to spot it before it does.

Written by Gurubalan G.T. · · 4 min read

A single key that appears to fit many locks but is shown, on closer inspection, only cut to fit the very first one, representing the illusion of vendor flexibility that turns into lock-in.
A single key that appears to fit many locks but is shown, on closer inspection, only cut to fit the very first one, representing the illusion of vendor flexibility that turns into lock-in.

By the time lock-in is obvious, it is usually too late to do much about it. The UK's competition regulator investigated this properly, and its findings describe what lock-in looks like once it has already happened. The more useful exercise is spotting the conditions for it before you sign anything.

What the regulator actually found

The UK Competition and Markets Authority spent nearly two years investigating the cloud services market and concluded in July 2025 that "competition is not working well." Its most quoted finding: "less than 1% of customers switch provider each year." The CMA identified egress fees — charges to move your own data out — as a key commercial barrier, and found that technical and commercial barriers together "lock customers into their initial choice of provider." (CMA, July 2025)

As of March 2026, the CMA declined to open a formal market investigation into Microsoft and AWS specifically, accepting voluntary commitments instead — a materially different regulatory outcome than a full investigation would have produced, and worth knowing if you are relying on regulatory pressure to eventually solve this for you.

The mechanism, mapped to what you can check before signing

Lock-in rarely arrives as a single dramatic clause. It accumulates from several smaller design choices, each individually reasonable-sounding, that combine into a position where leaving costs more than staying.

Proprietary data formats. If your data can only be exported in a format specific to this vendor, migrating it to anywhere else requires custom transformation work, which is itself a cost and a risk.

Egress fees. Charges specifically for moving data out, as distinct from charges for storing or processing it, exist for one purpose: making the exit expensive regardless of how good a competitor's offer becomes.

Deep integration with proprietary tooling. The more your team's workflows are built around a vendor's specific, non-standard tools, the more expensive retraining and rebuilding becomes if you leave — this is lock-in achieved through convenience rather than through a contract clause.

Long contract terms with automatic renewal. A multi-year default renewal, especially one requiring active cancellation within a narrow window, converts inertia into a switching cost.

Silence on data portability in the contract. If the contract does not specify format, timeline and cost for a full data export, assume the vendor has not thought about your exit — or has thought about it and decided not to make it easy.

What is actually changing, and where

Under Article 29 of the EU Data Act, cloud switching charges are capped at directly incurred cost now, and prohibited entirely from 12 January 2027. (Regulation (EU) 2023/2854) This is a real, binding change — but it applies within the EU's jurisdiction, and it addresses fees rather than the deeper forms of lock-in built through proprietary tooling and data formats, which no regulation directly reaches.

Outside the EU, buyers are relying on contract terms and their own diligence rather than regulatory protection, at least for now.

Questions to ask before signing, specifically

What format does a full data export use, and is it a standard, non-proprietary one?

Is there a named egress fee, and what does it cost for a dataset your current size?

How much of what we would build on this platform is genuinely portable, versus specific to this vendor's tooling?

What does the contract say about data return timelines and format if we terminate?

Has anyone actually tested exporting a meaningful dataset from this vendor, or are we relying on their documentation?

Why this belongs at the start, not the end

Every one of these questions is easy to ask before signing and expensive to ask after. The CMA's finding that fewer than 1% of customers switch annually is not evidence that switching is rarely worth it — it is evidence that the barriers, once in place, are effective. The leverage to negotiate favourable exit terms exists precisely once, at the point of signing, and disappears the moment you become dependent.

What we do

We build with data portability as a design requirement, not an afterthought, and we write the exit into any contract at the start — your data, your repositories, your documentation, in standard formats, on request. If you are evaluating a vendor and want the lock-in risk assessed before you sign, that is a conversation we are glad to have.


Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source.

Cybersecurity & Trustvendor lock-incloud contractsswitching costsprocurement
Considering a build? Describe the process and we will come back with a scope and a cost range — including if our view is that software is not the right answer. Get a range Message on WhatsApp