Avoiding AI Vendor Lock-In | Strategy Guide

A provider change may follow a model retirement, altered requirements, or a better result from another supplier. Portability means knowing what must change and having a tested migration path. A two-week target can be a project goal, but it is not a promise an architecture pattern can establish.

Where Lock-In Happens

Lock-in in AI systems is rarely one contract clause. It is five places your team quietly specialises in one vendor.

Prompt behaviour. Instructions that “just work” on one large language model often fail on another. Tone, tool-calling, JSON discipline, and refusals all differ. Prompts that live only in a vendor playground are a habit, not an asset.

Fine-tunes. Check whether the selected service permits exporting trained weights and whether the licence permits running them elsewhere. Hosted proprietary fine-tunes and self-hosted open-weight training have different portability constraints. Keep training data and evaluation records under your control where you have the right to retain them.

Platform features. Proprietary retrieval, vendor-only tool formats, and “assistants” products feel fast on day one. They become the migration, because your logic now follows someone else’s object model.

Data shape. Chunking rules, metadata, and embedding dimensions are easy to ignore until you move a vector database. Re-embedding is a project with quality risk, not a config change.

Call sites. A provider SDK used throughout business logic increases the code that may need changing. An internal client can concentrate that work, but migration duration still depends on feature differences, data, and validation.

You can still pick a strong primary vendor. Write down which of those five you have accepted.

The Cost of Switching

A mid-complexity system. retrieval over internal documents, a few tools, some workflow automation. does not stall on the new API key. It stalls because four workstreams land at once.

Prompt testing and adaptation. Test the current prompts against the replacement before deciding what to change. Estimate time from task coverage, failures, and review capacity.

Re-embedding. A different embedding model generally produces a different vector space. Keep document and query embeddings compatible and validate the rebuilt index. Existing vectors remain usable with their original model; they do not become intrinsically “wrong”. Changing only the answer-generating model need not require re-embedding.

Quality re-testing. Review the cases that already caused trouble. Hallucination rates and refusals shift even when the prompt is identical.

Team retraining. Operators who learned one vendor’s tracing UI and error codes will page you on the first incident. Write a one-page runbook before you switch.

Estimate migration work from an inventory: adapters, prompts, provider-only features, data export, embedding changes, tests, and rollout. An abstraction can reduce some of that work but does not justify a generic two-week or six-month estimate. See AI migration costs for the categories to assess.

Architectural Patterns for Portability

You do not need a grand “AI platform”. You need four boring habits.

One internal interface. Business code asks to complete a task. A thin adapter talks to the vendor. Text, tokens, tool calls, and errors are normalised before anything else sees them. SDKs stay behind that boundary.

Prompts as versioned files. System prompts, tool schemas, and few-shot examples live in your repo, tagged with the last model they passed. On a switch you re-validate; you do not hunt Slack for the “real” prompt.

Vendor-neutral data. Documents, chunks, and labels are JSON or markdown you can export today. The vector store is a cache. If it vanished tonight, you rebuild from files you already own.

Recorded embeddings. Store name, version, dimensions, distance metric, and preprocessing alongside the index. Different embedding models need not share a compatible vector space even when dimensions match. See the embedding concepts and test retrieval before a change.

A LangChain or LlamaIndex wrapper is not a strategy if prompts and data are still vendor-shaped. The boundary is the strategy; the library is optional plumbing. Further dependency checks are covered in AI dependency planning.

Multi-Provider Strategies

Choose the amount of provider redundancy from the required recovery time and the cost of maintaining it. Three patterns to assess are:

Primary plus fallback. Define eligible availability failures and test the fallback against the same quality, privacy, permission, and safety requirements. Do not automatically retry a safety refusal elsewhere. Use duplicate protection for actions that may already have succeeded before a timeout.

Use-case routing. Evaluate lower-cost models on each task and route only where their measured results meet the requirement. Classification, extraction, and generation can all vary in difficulty. Changing a model ID still requires tests.

Quiet bidding. Once a year, run the eval set against one alternative. You need a current quality and price number so a deprecation notice is not your first measurement.

Sending every request to two providers adds the second provider’s usage and review costs. That can be justified for a defined evaluation or reliability requirement, but calculate the extra cost rather than assuming it is exactly double.

A Practical Portability Plan

Set a migration objective based on the system’s importance, retirement notice periods, and the work a trial cutover reveals. The following checklist identifies dependencies; it does not predict a completion date.

Suggested preparation steps:

Put a single client module in front of every model call. No other package imports the vendor SDK.
Move prompts and tool schemas into versioned files. Start an evaluation set with representative and high-impact cases, then expand it as gaps appear.
Keep raw documents and chunk text outside the vector store. Confirm you can rebuild the index from those files.
Add a second provider behind a feature flag, even if it only handles a synthetic test request in staging.
Write the cutover checklist: swap config, re-embed if required, run evals, enable fallback, watch error rates for a week.

Dependency checklist. Use each row to identify work. The categories are planning aids, not a validated scoring system.

Area	Dependency to examine	Preparation to consider
Call sites	Vendor SDK everywhere	One adapter
Prompts	In a vendor UI	In git, with evals
Fine-tunes	Core path depends on them	Prompting or your own data only
Embeddings	Unknown model, no rebuild	Named model, source files owned
Fallback	None	Second provider tested in staging
Runbook	None	One page, last reviewed this quarter

Prioritise dependencies that would prevent continued operation, data export, or a safe cutover. Validate the plan through a trial migration rather than converting checklist points into a time estimate.

Same discipline as any other production dependency: know the exit, practise it, and do not confuse a favourite model with a business process. Off-the-shelf can still be the right buy. see when to build custom AI vs off-the-shelf. behind a boundary you control.

Where Fernside Fits

Our advisory work can map provider dependencies and scope the adapter, data, evaluation, and cutover work. The estimate should follow that assessment.

Want to understand the work involved in changing provider? Book a discovery call and we will map call sites, prompts, and data ownership before recommending changes.