89% Say They Could Switch AI Providers. 58% of Those Who Tried, Couldn't.

Every piece of AI advice tells you to choose carefully. I have spent six weeks documenting a market where the correct choice changed roughly every nine days.

Every piece of AI advice tells you to choose carefully. I have spent six weeks documenting a market where the correct choice changed roughly every nine days. The skill that matters is not picking right. It is being able to be wrong cheaply, and almost nobody measures it.

A slightly worse setup you can abandon in a week beats a slightly better one that takes a quarter to leave. That sentence contradicts nearly all mainstream AI guidance, and I think the last six weeks make it hard to argue with.

The idea that vendor lock-in is bad is not new, and I am not claiming it. Portability has been standard engineering advice for decades, and there is a competent body of work on it specific to language models, which I will link throughout.

What I want to argue is narrower and, I think, unsaid: the rate of change has crossed a threshold where switching cost stops being a line on a risk register and becomes the primary metric you should optimise your AI architecture around — ahead of capability, ahead of price, ahead of fit.

The Ledger

Let me start with evidence rather than assertion. Here is what changed in the six weeks I have been documenting this market. Every item is something I covered and verified at the time.

A major provider announced a price increase for its mid-tier model, then cancelled it and made the introductory rate permanent. Anyone who migrated away to avoid the rise did so for nothing.
A different provider cut its cheapest tier by 80% three weeks after launching it. March's flagship intelligence became available at roughly one-thirteenth of the token price in four months.
A frontier open-weight model shipped under a different licence than its predecessor, adding a commercial-use threshold that did not exist in the prior version. The technical evaluation was unchanged; the legal one was not.
Open weights went from requiring 64 or more accelerators to running on a single consumer GPU in nine days, which reversed a conclusion I had published the week before.
A binding regulatory obligation took effect, and a major provider shipped global content marking in response nine days later.
A lab paused development of its most capable model over capability it could not bound, indefinitely and without a release date.
A widely used coding agent retired per-action human approval and replaced it with a classifier, changing the security model for every team using it.
The dominant agent-tooling protocol went stateless, deprecating several features and a whole transport in a single release.
A regulator moved an entire hardware category from unrestricted to restricted in one afternoon.
And earlier this summer, two frontier models were suspended within days of launch following a government directive. Enterprises that had built production workflows around them lost access overnight.

That is ten structural changes in six weeks. Not capability improvements — those are continuous and expected. Changes that invalidate a decision somebody made deliberately, with analysis, and wrote into an architecture.

If your AI planning cycle is quarterly, roughly five of those events landed inside a single cycle. The plan you approved in June described a world that no longer exists, and nobody told you.

The Number That Should Worry You

Here is where the argument stops being anecdote.

Ask organisations whether they could switch AI providers and the answer is reassuring. A Zapier survey found 89% believed they could — while 58% of those who actually attempted a migration hit failures or unexpected difficulty.

That is a thirty-one point gap between believing and doing, measured against attempted migrations rather than opinions about hypothetical ones.

I find this the single most useful statistic in the AI operations literature, because it is the same shape as every other measurement I have written about this month. People believed their approval prompts caught dangerous commands; a controlled study put it at 13.6%. People believe they could switch providers; the ones who tried mostly could not.

The supporting figures point the same way. A 2026 Parallels survey found 94% of organisations concerned about lock-in. Gartner projects that by 2027, 60% of organisations will face significant migration costs from pricing changes, API deprecations or strategic pivots. One estimate puts the average enterprise migration at around $315,000; another puts switching costs at 19 to 34%.

Treat the dollar figures as directional — they come from vendors selling portability layers, which is precisely the incentive you would expect. The Zapier confidence-capability gap is the one I would put in front of a board, because it measures behaviour rather than opinion.

Why Lock-In Happens to Careful People

The literature on this is good and unanimous on one point: nobody chooses lock-in.

As one analysis puts it, lock-in creeps in through small speed-driven choices — provider-specific SDKs, prompts tuned to one model's quirks, evaluation data trapped in one vendor's platform. Each individual decision is correct on the day it is made. The aggregate is a dependency nobody approved.

I would add a mechanism the literature underweights. Lock-in accelerates precisely when a vendor is performing well. A model that works is a model you build more on. Six months of good service produces more coupling than six months of mediocre service, which means your exposure is highest to the vendor you are happiest with.

That is not a paradox to be resolved. It is a reason to build the exit while you are not thinking about leaving.

The Seven Couplings

Concretely, switching cost accumulates across seven surfaces. I list them because each one is separately fixable, and most teams have never enumerated them:

Prompt coupling. Prompts tuned to one model's quirks over months of iteration. This is usually the largest and least visible cost.
Output-format coupling. Downstream code that parses one model's characteristic response shape.
SDK and API coupling. Provider-specific libraries threaded through application code rather than sitting behind an interface.
Evaluation coupling. Your test set and quality history living inside a vendor's console, where it cannot be replayed against a competitor.
Retrieval coupling. Embeddings tied to one provider's model, since switching can force re-embedding and reindexing your whole corpus.
Contractual coupling. Committed spend, seat minimums, and terms that make leaving expensive independent of engineering effort.
Commitment coupling. Promises made to clients on one vendor's capabilities, pricing or compliance posture. The one nobody counts, and often the one that actually blocks the move.

A useful practitioner framing from the same literature: portability does not mean provider-neutrality on everything. It means keeping prompts, evaluations and routing logic in a portable layer so model choice becomes a configuration change rather than a rewrite.

The Coupling That Arrives With Your First Enterprise Client

One coupling deserves separate treatment because it appears suddenly and from an unexpected direction: procurement.

A hosted model API can take a product from prototype to paid pilot in a fortnight. The same decision can later stall a six-figure enterprise contract, because enterprise buyers ask for EU data residency, private inference, audit log export, subprocessor review and contractual control over model changes.

None of those are engineering questions. They are questions about which vendor you are on, and they arrive at the moment your business is trying to move upmarket. A team that has never considered switching cost discovers it as a blocked deal rather than as a technical constraint.

The compounding version is worse. Analysis of enterprise AI dependencies notes that switching costs accumulate across multiple vendors simultaneously and compound where integrations share data flows — so leaving one vendor requires evaluating downstream effects on the others. Almost no organisation has a methodology for measuring that accumulation, which is exactly why it works so well as a moat for the people selling to you.

The Metric: Days to Replace

So here is the framework I now use, and the thing I would actually like you to take away.

For every AI dependency in your business, answer one question: if this became unavailable tomorrow, how many working days until we are running on something else at acceptable quality?

Not whether you could. How many days. A number.

Most teams have never computed this, and the exercise itself is the value — because the honest answer usually arrives as a series of realisations rather than an estimate. The prompts are tuned. The evals live in their console. The embeddings would need rebuilding. Three clients were sold on a compliance certification only that vendor holds.

Reading the Number

Under 5 days: genuinely portable. You can take advantage of price cuts, respond to a deprecation, and negotiate from a position where leaving is credible.
5 to 20 days: workable. A migration is a project but not a crisis. Most well-run teams should target this band for their core dependencies.
20 to 60 days: exposed. You will absorb a price increase rather than move, which means your vendor's pricing power over you is effectively unlimited within that range.
Over 60 days, or unknown: this is not a dependency, it is a merger. Treat it with the seriousness you would apply to any other decision that binds your business for a quarter.

The band that matters most is the third, because it is where most businesses actually sit and where the consequences are invisible. You never experience a twenty-to-sixty-day switching cost as a crisis. You experience it as a series of reasonable decisions to stay, each of which is individually correct and collectively expensive.

You will never receive an invoice for your switching cost. You pay it as the price increases you absorb, the better options you do not take, and the negotiations you enter without leverage.

The Test That Makes It Real

An estimate is worth something. A rehearsal is worth much more.

The practitioner advice here is sound and almost nobody follows it: do a practice swap in staging before you are forced to, and observe specifically what changes in tool calls, citations and refusals.

Pick one workflow. Move it to a different provider. Time it. Whatever number you get is your real switching cost for that class of work, and it will be larger than your estimate — that is what the 89-versus-58 gap is measuring.

Do this once a quarter and the number falls, because you fix what broke. Do it never and the number rises silently.

The Uncomfortable Trade

Now the part that genuinely contradicts standard advice.

Conventional guidance says to evaluate models on capability and cost for your use case, pick the best fit, and commit. That is correct when a decision holds for a year. When the landscape reshapes every few weeks, it produces a business that is optimally configured for conditions that have already passed.

I would state the trade explicitly: prefer the option you can leave.

If model A is 5% better on your evaluations but locks you in for two months, and model B is portable in three days, take B. The 5% is real but static. The portability compounds, because it lets you capture every subsequent improvement in the market rather than one snapshot of it.

The last six weeks are the argument. A portable team took the 80% price cut the week it happened. A locked team is still running a comparison and will finish it after the next repricing.

The Limits of That Claim

I want to bound this properly, because stated without limits it becomes an excuse for never committing to anything.

The trade only holds where the capability difference is modest. If one model can do the job and the others cannot, portability is irrelevant — you do not have a choice to preserve. Frontier-only work is frontier-only work.

It also has a real cost. An abstraction layer is another component to operate, evaluate and debug, and the honest practitioner literature says so directly. Building for portability you never use is waste. My argument is that the last six weeks have shifted the probability you will use it from low to high, not that the layer is free.

And there is a threshold effect. Below a certain scale, migration is genuinely cheap for everyone and none of this matters much. If your whole AI footprint is two workflows and forty prompts, you are portable by default. Enjoy it, and revisit when you are not.

What This Explains

A framework earns its place by connecting things you already knew.

Why do 74% of AI agent deployments get rolled back? Partly because a rollback is what a migration looks like when switching cost was never measured. The team could not move sideways, so they moved backwards.

Why do 80% of executives report no measurable AI ROI? Because captured value requires acting on improvements, and a locked-in organisation watches the market improve without being able to participate. The gains are real and accrue to someone else.

Why does task-model matching keep being the highest-return architectural move? Because it requires portability as a precondition. You cannot match a task to the best model for it if you can only reach one model.

And why does process ownership beat tool delivery? This is the sharpest version of that argument I have found. If you own a process, the tool is an implementation detail and switching cost is low by construction. If you sold a tool collection, the tools are the product and every one of them is a dependency you cannot leave.

What To Do This Week

List every AI dependency and assign each a days-to-replace number. Models, platforms, agent tools, vendors. Guess where you must, but write a number rather than a shrug.
Pick the highest one and cut it in half. Usually the cheapest win is moving prompts and evaluation data out of a vendor console into your own repository. That is a day of work and it moves the number more than anything else you could do.
Export your evaluation set today. If your quality history lives in one vendor's platform, you cannot compare alternatives, which means you cannot leave even when leaving is obviously correct.
Run one practice migration this quarter. One workflow, different provider, timed. The measured number replaces the estimate, and the estimate is wrong.
Audit your client commitments. Anything you promised that depends on one vendor's pricing, compliance posture or specific capability is switching cost you cannot engineer away. Know what those are before you need to.
Re-read your contracts for the exit terms, not the price. Committed spend and seat minimums determine how free you actually are, and they are usually agreed by someone who never asked how they would leave.

The Argument in One Line

For two years the industry has optimised for making the right AI decision. The last six weeks demonstrate that no decision in this market stays right for long enough to justify that effort.

The organisations that will do well are not the ones that chose best. They are the ones that can change their minds in under a week, repeatedly, at low cost — capturing each improvement as it arrives instead of one snapshot of a market that has already moved.

That capability is not a product. No vendor sells it, and every vendor has a mild interest in you not having it. It is architecture, discipline and a number somebody has to be responsible for.

Which is, as always, a systems problem — and this one has the unusual property that the work required to fix it is the same work that makes everything else in your stack better.

Frequently Asked Questions

Isn't this just "avoid vendor lock-in", which everyone already says?

The concept is old and I have not claimed otherwise. What I am arguing is a change in priority: that switching cost has moved from a risk-register item reviewed annually to the primary metric that should shape architectural decisions, ahead of capability and price. That follows from the rate of change, not from anything new about lock-in itself.

Doesn't an abstraction layer just add complexity?

Yes, and that is a genuine cost the portability literature is honest about — it is another component to operate and evaluate. The question is whether the option it buys is worth more than the complexity it adds, and the answer depends on how often you will exercise it. Six weeks ago I would have said this was marginal for small teams. The ledger above changed my view.

What if the best model is clearly better for my use case?

Then use it — the trade I describe only applies where the capability gap is modest. But measure your switching cost anyway, and know the number. Using the best model is a decision; not knowing what it would cost to stop is an accident.

How do I measure switching cost without doing a migration?

You cannot, precisely, which is the point of running a practice swap. Estimate first by walking the seven couplings above, then test one workflow for real. The gap between your estimate and the measured result is itself the most useful finding — it is your organisation's version of the 89-versus-58 problem.

Is this an argument for using cheaper or open-weight models?

Not directly, though they often score better on portability. It is an argument for structuring things so the choice remains live. A self-hosted open model with prompts hard-coded into application logic can be less portable than a hosted frontier model behind a clean interface.

What is the single highest-return action here?

Get your prompts and your evaluation set out of any vendor's console and into your own version control. It takes a day, it costs nothing, and it converts "we would have to rebuild our quality baseline" from a blocker into a non-issue.

About the Author

Hamza Baig is the founder of Hexona Systems, an AI automation agency serving clients across six continents, and the AI Automation Institute, a community of more than 40,000 entrepreneurs building with AI.

He has been featured in the GHL Top 50, Yahoo Finance and Brainz Magazine, and writes regularly on automation architecture, agent governance and the operational realities of AI deployment.

Read more analysis on the Hamza Automates blog, including the no-code automation workflow guide, or get in touch to discuss an automation build.

Follow @hamza_automates on Instagram for daily automation breakdowns.

Note: the concept of vendor lock-in and the portability practices referenced here are established engineering guidance, credited and linked throughout. The switching-cost banding and the argument for treating it as a primary architectural metric are the author's. Cost figures sourced from vendors selling portability tooling are flagged as directional in the text.

About

Hamza Baig is the founder of Hexona Systems—an automation agency and softwareplatform that helps thousands of entrepreneurs and business owners implement AI-powered workflows at scale.