Switching AI Vendors: What Actually Breaks

Ordinary SaaS switching costs are mostly about data export and retraining people. Switching AI vendors adds a category of cost most teams don't budget for at all: the prompts, fine-tunes, and embeddings you built around one model's specific behavior, none of which travel cleanly to another one.

Why this is a different kind of switching cost

Our hidden-costs framework and TCO guide cover what applies to switching almost any SaaS tool: onboarding fees, migration labor, contract overlap, price escalation. Switching the AI model or provider underneath a product adds a layer those frameworks don't fully capture, because the thing you're moving isn't just data — it's behavior you spent time shaping around one specific model's quirks.

Three things that don't travel with you

• Prompts tuned to one model's style. A prompt that reliably produces good output from one model can produce noticeably worse output from another, even when both are described as comparable. Teams tune instruction wording and structure around a specific provider's reasoning behavior without realizing they've done it — the dependency is invisible until you swap the model underneath the same prompt.
• Fine-tuned models. A model fine-tuned on your data typically lives inside that provider's environment. If the underlying weights and training data aren't cleanly exportable — and for most hosted fine-tuning products, they aren't — moving providers means retraining from scratch, not migrating a file.
• Embeddings tied to one vector space. If you've built a retrieval system on top of one provider's embedding model, those vectors are meaningless to a different embedding model. Switching means re-embedding your entire corpus, not converting a format.

The OpenAI-compatible exception

Switching costs aren't uniform across every use case. Several major providers — including Anthropic, DeepSeek, and Mistral — support the OpenAI chat-completions request format natively, which means a basic text-generation integration built against that format can often point at a different provider with a configuration change rather than a rewrite. That compatibility covers the simplest case: sending a prompt, getting text back. It does not cover fine-tunes, provider-specific tool-calling formats, or embeddings, which is where the real lock-in still lives.

A pre-switch checklist for AI vendors

1. Build a verification test suite before you need one. A set of representative prompts with expected-quality benchmarks lets you evaluate a new provider objectively instead of by impression.
2. Check fine-tune export rights explicitly, before you fine-tune, not after — ask directly whether trained weights can leave the platform.
3. Budget for a full re-embedding pass if you're evaluating a provider with a different embedding model, and treat it as a real project, not a script that runs overnight.
4. Separate your prompt layer from your business logic so swapping the underlying model doesn't mean touching application code.
5. Price the switch the same way you would any other tool — engineering hours at a real internal rate, not "however long it takes."

Where this connects to the rest of your stack

The mechanism here is the same one covered in our vendor lock-in article — dependency that isn't visible until you try to leave — applied to a category where the dependency is behavioral rather than contractual. It compounds with ordinary SaaS lock-in rather than replacing it: an AI feature built on a single provider carries both the standard contract and data risks covered in our contract red-flags checklist, and this model-specific layer on top.

Bottom line

Switching AI vendors is rarely just a data-export problem. The prompts, fine-tunes, and embeddings built around one model's specific behavior are real, uncounted switching costs — and the gap between a two-day config change and a month-long migration is almost entirely determined by whether an abstraction layer existed before you needed one.