How to Sunset an AI Vendor

Leaving an AI vendor is harder than leaving most software vendors, because the valuable assets are not the application: they are the prompts, the connector definitions, the evaluation sets, and the accumulated configuration that encodes how your business works. Companies discover during an exit how much of that lives only in the vendor's console. This guide covers the sequence that works and the terms that make it possible.

What should be recovered, and when?

Before notice is given, while the relationship is cooperative and support is responsive:

Asset	Why it matters	Typical difficulty
Prompts and system instructions	They encode your process knowledge	Often exportable; sometimes only by hand
Configurations and workflows	Rebuilding is slow and error-prone	Varies widely by vendor
Connector and tool definitions	The integration layer you paid for	Frequently proprietary
Evaluation sets and results	Your evidence and your validation asset	Often overlooked entirely
Conversation and decision logs	Audit, regulatory, and investigation needs	Retention limits may apply
Fine-tuned artifacts	Only where the licence permits	Frequently not permitted
Your data held by the vendor	Obvious, and usually covered in contract	Usually available

Two rules: recover before notice, and verify the exports are usable rather than merely delivered. A JSON dump nobody can import is not a recovered asset.

What order should migration follow?

Dependency order, not importance:

1. Shared connectors and integrations, because everything else uses them.
2. The platform layer: gateway, identity, evaluation tooling, observability.
3. Low-risk agents, to prove the path and find the surprises cheaply.
4. Higher-risk agents, with parallel running.
5. Monitoring, reporting, and dashboards, last, since they depend on everything above.

The common mistake is migrating the most important agent first, which means rebuilding shared components under time pressure with executive attention on the outcome. The how to manage AI across business units guide covers the platform layer being rebuilt.

How is the replacement validated?

Against your own evaluation set, on your own cases, comparing pass rate, cost per task, and latency with the incumbent's measured performance. This is where companies with evaluation discipline have a straightforward migration and companies without one have a leap of faith: with no baseline for the current system, there is no way to know whether the replacement is better, worse, or the same.

If the evaluation set does not exist, build it before migrating rather than during. The AI evaluation explained for executives piece covers the construction; it is also the asset that makes every future switch cheap.

Should systems run in parallel?

For anything consequential, yes. Run identical inputs through both systems for a period, compare outputs, and investigate the differences. It costs double for the overlap, which is far less than discovering a quality gap through customer complaints. For low-risk internal agents, a short shadow period is usually sufficient. The how to run shadow mode deployments guide covers the technique.

What contractual levers exist?

Whatever was negotiated at signature, which is why this belongs in procurement rather than in the exit:

• Export rights for prompts, configurations, connectors, evaluation data, and logs, in specified formats.
• Exit assistance as a defined obligation with a scope and a duration.
• Data deletion certification after migration.
• Notice periods that allow orderly migration rather than a cliff.
• Continued service during transition, including if the relationship has soured.
• Standards support, which reduces the migration effort in the first place.

The agent interoperability explained for executives piece covers the standards that make connectors portable. Consult counsel on the terms; this is general guidance, not legal advice.

What if the vendor is failing rather than being replaced?

Compress everything. A vendor in distress stops supporting exports before it stops operating, and support quality degrades first. Recover assets immediately, in parallel with the internal decision-making, and do not wait for a formal decision to secure what you can. The how to respond to an AI vendor failure guide covers the wider failure scenarios.

How do you avoid repeating this?

Keep the assets that matter on your side of the boundary: prompts, specifications, and evaluation sets in your repositories; connector definitions built to open standards; model access through your own gateway; logs in your own observability platform. Then the next vendor change is a configuration exercise rather than a project. Add concentration limits to the risk appetite so one vendor never becomes load-bearing again without a deliberate decision. The chief risk officer's guide to AI agents covers the concentration view.

What should executives ask?

• If we gave notice tomorrow, what could we actually export, and in what format?
• Do our prompts, specifications, and evaluation sets exist outside the vendor's system?
• What does the contract oblige them to do during exit?
• Could we validate a replacement against our own cases?
• Which of our current vendors would be hardest to leave, and why?

How can FISTA Solutions help?

FISTA Solutions runs AI platform migrations, recovering and rebuilding prompts, connectors, and evaluation assets on a governed stack the client owns, and builds AI agents whose assets live in client repositories from the start, through its AI enablement practice. Since 2017, FISTA has delivered 150+ projects for 50+ companies across 12+ countries, with a 99.9% uptime record on production systems.

To assess how hard your current vendor would be to leave, talk to FISTA on WhatsApp, or read LLM vendor lock-in.