AI Vendor Exit and Portability: An Enterprise Whitepaper

Every AI vendor relationship ends eventually, through acquisition, price change, quality decline, strategic shift, or failure. What differs is whether the ending costs a quarter or a year. That cost is not decided at exit; it is decided at the architecture review nobody held and in the contract nobody read closely, two years earlier. This whitepaper sets out what must be owned, where lock-in genuinely binds, and how to structure both contracts and systems so that leaving is a project rather than a rebuild. It draws on FISTA Solutions' AI enablement practice and complements the AI vendor due diligence whitepaper and ai third-party risk management. This whitepaper is general guidance, not legal advice.

Where does lock-in actually come from?

Layer	Portability	Why
Foundation model	High	Interfaces converge; prompts need adjustment and re-evaluation
Inference hosting	High	Commodity, with cost and latency differences
Embeddings and vector store	Medium	Re-embedding is compute, not redesign, if source data is held
Prompts and configuration	High if owned, zero if not	Depends entirely on where they live
Orchestration and agent framework	Low	Proprietary abstractions rarely map across
Workflow platforms	Very low	Business logic encoded in vendor tooling
Fine-tuned models	Low	Artifacts often non-portable; training data may be
Evaluation tooling	Medium	Sets are portable; scores in vendor tools are not
Data held by vendor	Depends on contract	The single most important term

The counterintuitive point is that the model, which dominates procurement debate, is the most replaceable part. The parts nobody negotiates over, orchestration and workflow encoding, are where migrations die.

What must an organisation own?

Data. Source data, derived artifacts, and anything the vendor generated from your data. Held in your environment where possible; exportable in documented, non-proprietary formats where not.

Prompts and configuration. System instructions, task prompts, routing rules, thresholds, and tool definitions, kept in your version control, not in a vendor console. This costs nothing at build time and is frequently the difference between a two-week and a two-month migration.

Evaluation sets. The reference cases and expected outputs that define what correct means for your tasks. These are the organisation's accumulated understanding of its own requirements, and they are what make a replacement provable rather than hopeful.

Logs and traces. Interaction history with inputs, outputs, versions, and costs, exported continuously rather than retrieved at exit. They support audit obligations independently and become the regression corpus for any migration.

Model artifacts or their inputs. Fine-tuned weights where the contract allows, and the training data regardless, since the data lets you reproduce the tuning elsewhere even when the artifact cannot move.

What does an abstraction layer buy?

Enough to be worth its modest cost. Applications call an internal interface; a gateway resolves the route, provider, model version, and parameters; prompts and configuration live in your repository; logging and evaluation hook in at the gateway.

With that in place, changing providers is a configuration change validated by evaluation. Without it, every application that embedded a provider SDK, a proprietary response shape, or a vendor-specific feature becomes a separate migration. The layer also delivers benefits unrelated to exit, including cost attribution, version pinning, and consistent logging, which is why it is worth building before any exit is contemplated. See the LLM gateway architecture whitepaper.

The discipline that matters is resisting vendor-specific features that cannot be replicated. Some are worth the dependency; most are conveniences that cost a rewrite later. The test is whether a feature could be reimplemented in a few days against another provider.

What contract terms decide exit cost?

• Data ownership, stated plainly, covering source data, derived data, embeddings, and outputs.
• No training on your data, including for model improvement, with audit rights.
• Export rights specifying formats, completeness, and timeframes, so export is an obligation rather than a best effort.
• Deletion obligations with certification, covering backups and derived artifacts.
• Transition assistance, with defined duration, scope, and rates, committed before you need it.
• Continuity during wind-down, so service does not degrade during migration.
• Ownership of fine-tuned artifacts or, failing that, of the training data.
• Notice periods for material changes to models, pricing, or terms, which protect against surprises that force an unplanned exit.
• Concentration and subprocessor transparency, since your vendor's dependencies become yours.

These are negotiable at signature and rarely at renewal, which is when most organisations discover they need them. See outsourcing contract checklist and how to negotiate an ai development contract.

How is a migration run?

1. Inventory. Every dependency on the outgoing vendor: models, features, data held, integrations, workflows, and the people who know them.
2. Establish the baseline. Run your evaluation sets against the incumbent and record quality, cost, and latency per task. Without this, you cannot demonstrate equivalence.
3. Select and evaluate candidates against the same sets, adjusting prompts as needed, since prompt behaviour differs across models.
4. Migrate data early, verifying completeness, and re-embed where the embedding model changes.
5. Shadow. Run the candidate against live traffic without serving its output, comparing results at scale.
6. Canary and expand, per route rather than all at once, with rollback available.
7. Decommission with deletion certification and retention of your exported logs.

The step teams skip is the second, and it is the one that makes the rest defensible. Migrations without a measured baseline become arguments about whether the new system feels worse.

What makes prompt migration harder than expected?

Prompts are model-specific in ways that are easy to underestimate. Instruction phrasing that reliably produces structured output on one model may not on another. Refusal behaviour differs. Context handling differs. Tool-calling conventions differ. Few-shot examples tuned for one model can mislead another.

Budget for prompt re-engineering and re-evaluation per task rather than assuming prompts transfer. Teams that maintain their prompts in version control with the evaluation set attached handle this in days; teams whose prompts live scattered in vendor consoles discover they do not have a complete inventory of what they are migrating.

What about fine-tuned models?

They are the least portable artifact. Some providers permit export; many do not. Where export is unavailable, the fallback is the training data, which lets you tune an equivalent model elsewhere at the cost of the tuning run and re-evaluation.

The practical protections are keeping the training dataset under your control, versioned and documented; recording the tuning configuration; and evaluating regularly whether the tuned model still outperforms a current base model with good retrieval, since base model improvements frequently erase a tuning advantage and remove the dependency entirely.

How does concentration risk fit in?

Regulators in several sectors now ask about dependence on a small number of AI and cloud providers, because sector-wide concentration creates systemic exposure. For an individual organisation the practical questions are whether a single provider outage stops critical operations, whether a single provider's policy change could force an unplanned migration, and whether the organisation could operate degraded on an alternative.

Multi-provider capability, even if unused day to day, is the mitigation. Maintaining a tested secondary route for critical workloads costs the evaluation effort to keep it current and converts a strategic dependency into an operational choice.

What does an exit plan document contain?

An inventory of dependencies by system; the data and artifacts held by the vendor and how they are retrieved; contractual export and assistance rights with their timeframes; an alternative for each dependency with evidence it is viable; a migration sequence with estimated effort; the evaluation sets that would prove equivalence; and a named owner. Reviewed annually and after any material contract or architecture change.

In regulated sectors this document is increasingly a supervisory expectation rather than good practice, and the test applied is whether it is credible, meaning whether the alternatives have been evaluated rather than merely named.

What goes wrong?

Prompts living only in a vendor console. No evaluation sets, so migration is unprovable. Business logic encoded in a vendor's workflow builder. Data export discovered to be unavailable in usable form at exit. Fine-tuned models with no retained training data. Transition assistance negotiated during a dispute. And the most common failure: an architecture where twenty applications each call a provider SDK directly, making the abstraction layer a migration project in itself.

How does this apply to AI features inside existing software?

Most organisations acquire far more AI through their existing vendors than through AI-specific purchases. The CRM adds summarisation, the service desk adds triage, the ERP adds document processing, the collaboration suite adds a general assistant. Each arrives inside a contract signed before anyone considered AI terms.

Three questions settle the exposure for each. What data does the feature send, and where does it go, including subprocessors? Does the vendor train on it, and can that be disabled contractually rather than by a setting someone may change? And can the feature's outputs, logs, and any configuration be exported, or does switching the underlying platform lose them entirely?

The answers vary widely, and the third is usually the worst. Embedded AI features rarely expose their logs, which means an organisation cannot evaluate their quality, cannot audit what they did, and cannot reproduce their behaviour elsewhere. That is acceptable for conveniences and unacceptable for anything that touches a decision, which is the line worth drawing explicitly in an AI use policy.

What does a portability review look like?

An annual exercise, an afternoon per major system. For each: list the dependencies, confirm where prompts and configuration live, confirm evaluation sets exist and are current, check that data export has been tested rather than assumed, and verify the alternative named in the exit plan has been evaluated within the last year.

The single most valuable item is testing the export. Organisations routinely discover at exit that the export endpoint returns a subset, a proprietary format, or nothing at all within the contractual window. Testing it while the relationship is healthy costs a day and converts a contractual right into a demonstrated capability.

How FISTA Solutions delivers this

FISTA Solutions builds AI systems on an abstraction layer with prompts, evaluation sets, and configuration held in the client's own repositories, data and logs in the client's environment, and portability tested rather than assumed, so vendor decisions remain commercial choices rather than structural commitments, through AI enablement, AI agents, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To keep your AI vendor choices reversible, message FISTA on WhatsApp, or read the AI vendor due diligence whitepaper.