AI Switching Costs: Keeping Them Near Zero

Switching costs are what it takes to move off a vendor: the money, the engineering, the retraining, and the disruption you would absorb to replace one AI system with another. They matter more than almost any other number in an AI contract, because switching costs are the actual mechanism of vendor lock-in. A vendor rarely traps you with a clause. They trap you by letting switching costs accumulate quietly until leaving is too expensive to consider, and then they price accordingly. Keeping those costs near zero is how you keep the power on your side of the table.

The reason this deserves its own discipline is that switching costs do not announce themselves. Nobody signs up for lock-in. They sign up for a tool that works, build a few workflows on it, let their data settle into it, and train the team on it, and each of those reasonable steps adds to the cost of ever leaving. By the time the vendor raises the price or a better option ships, the switching cost is already built, and it was built by the buyer, one convenient decision at a time.

Why switching costs quietly rise

The accumulation is the whole problem. Every workflow wired directly to a vendor’s proprietary interface, every dataset that lives only in their system, every process your team learns in their tool, is a strand tying you in place. Individually none feels like a commitment. Collectively they become one.

Enterprises have watched this movie before. Oracle locked large companies onto its databases, then raised prices once leaving was impractical. VMware did the same, and when Broadcom acquired it, costs rose roughly tenfold essentially overnight, and companies faced migration projects they had never budgeted for (Atolio). The pattern is always the same: switching costs are allowed to build gradually, and then the extraction begins. In AI the strands accumulate faster, because the tools are easier to adopt and the data they ingest is stickier. A single AI workload can already cost six figures to migrate off a proprietary platform, and shared platforms run into seven (StackAI). At renewal, that switching cost quietly becomes the vendor’s pricing power.

Two kinds of switching cost

Not all switching costs are bad, and telling the two kinds apart is what keeps this from becoming paranoia about every tool.

Healthy switching costs come from value. If leaving a system means giving up real performance it delivers, that cost reflects the product being good, and it is a fine reason to stay. You are not trapped; you are choosing.

Structural switching costs come from architecture. Proprietary data formats you cannot export cleanly, workflows hard-wired to one vendor’s interface, configurations you cannot replicate elsewhere, these exist regardless of whether the product is any good, and they are the ones that turn into lock-in. The goal is not to eliminate switching costs. It is to make sure the only thing keeping you is the value, not the architecture.

Keeping switching costs near zero

Low switching costs are a design choice, made up front and maintained. A handful of practices keep them near zero.

Put an abstraction layer between your systems and any vendor. Instead of hard-wiring your workflows into one provider’s API, route them through an interface you control, a gateway, so the provider underneath can change without your systems changing. When your code addresses one stable interface, swapping a model becomes a routing change rather than a rebuild.

Own your data and context. Keep the data, the documents, and the accumulated context that make your AI valuable in a store you control and can export cleanly, not locked inside a vendor’s proprietary format. The context layer is the part worth the most and the part most often surrendered by default.

Prefer standard formats and avoid proprietary critical-path dependencies. The more of your critical path that runs on open, portable formats, the less any single vendor can hold. Treat a proprietary dependency in a load-bearing place as a red flag, not a convenience.

Test the exit before you need it. A portability plan you have never rehearsed is a hope, not a plan. Periodically confirm you can actually move a workload, and how long it takes, so the answer is known before a vendor forces the question.

You cannot reach zero, and should not try

Honesty matters here, because chasing literal zero wastes effort and credibility. No AI application is perfectly model-agnostic; swapping a model always involves some rework, and total independence from every vendor is neither achievable nor worth the cost of pursuing (Writer). Some coupling is the price of using AI at all.

The realistic goal is not zero switching cost. It is to make sure the hard-to-move parts are the parts you own, and the easy-to-move parts are the ones you rent. A company gets into trouble only when it inverts that: when the proprietary vendor holds the data, the workflows, and the context, and the company holds a subscription. Fix the inversion and switching cost stops being an existential risk and becomes a manageable, known number.

Measure it

What gets measured gets kept low. A few metrics turn portability from a good intention into an operational discipline: the share of your AI workloads that are actually portable, the time it would take to redeploy a model to a new provider, the amount of your critical path that depends on proprietary formats, and your data-egress exposure. If those are trending the wrong way, your switching costs are rising whether or not anyone decided they should. Watching them is how you catch lock-in while it is still cheap to undo.

Low switching costs are the buyer’s power

Everything here comes back to one thing: who holds the power at renewal. A company with low switching costs negotiates from strength, because it can credibly leave; a company with high ones takes the price it is given, because it cannot. Keeping switching costs near zero is not a technical nicety. It is how you make sure the buyer’s power stays yours, which is the whole of the own-versus-rent decision made concrete.

This is why the portability discipline belongs at the architecture level, designed into how you build versus buy and into the operating system your AI runs on, not bolted on after a vendor has already raised the price. Thane Alaric builds every engagement so that the client owns the system, documented and portable, for exactly this reason: keep the switching costs near zero, and you keep the freedom to always use the best, cheapest model without a rebuild. Switching cost is a design choice made early and paid for late. If you want to know where yours sit, tell Daniel what you have built and what it runs on. Book 30 minutes with Daniel.

Frequently Asked Questions

What are switching costs in AI?

Switching costs are what it takes to move off an AI vendor: the money, engineering, retraining, and disruption of replacing one system with another. They matter because they are the mechanism of vendor lock-in. Vendors rarely trap customers with contract clauses; they let switching costs accumulate until leaving is too expensive, then price accordingly at renewal.

How do AI switching costs create lock-in?

Through accumulation. Every workflow wired to a proprietary interface, every dataset living only in a vendor’s system, and every process your team learns in their tool adds to the cost of leaving. Individually each is minor; collectively they make switching impractical. Once a vendor knows you cannot realistically move, your switching cost becomes their pricing power, exactly as happened in the Oracle and VMware-to-Broadcom cases.

What is the difference between healthy and structural switching costs?

Healthy switching costs come from value: leaving means giving up real performance the product delivers, so staying is a genuine choice. Structural switching costs come from architecture: proprietary formats, hard-wired workflows, and configurations you cannot replicate elsewhere. Structural costs exist regardless of product quality and are the ones that become lock-in. The goal is to be held by value, not by architecture.

How do you reduce AI switching costs?

Put an abstraction layer between your systems and any vendor so models are swappable through an interface you control. Own your data and context in a portable store rather than a vendor’s proprietary format. Prefer standard formats and avoid proprietary dependencies in critical paths. And test the exit periodically, so you know you can actually move a workload before a vendor forces the question.

Can you eliminate AI switching costs entirely?

No, and trying wastes effort. No AI application is perfectly model-agnostic, and some rework is always involved in switching. The realistic goal is to make sure the hard-to-move parts are the ones you own, your data, workflows, and context, while the models underneath stay cheap and swappable. Trouble comes only when a company owns nothing but a subscription and the vendor holds everything else.

How do you measure AI portability?

Track the share of AI workloads that are actually portable, the time to redeploy a model to a new provider, how much of your critical path depends on proprietary formats, and your data-egress exposure. If these trend the wrong way, switching costs are rising whether or not anyone chose that. Measuring them catches lock-in while it is still cheap to undo.