AI Vendor Lock-In: Test Your Exit Before You Sign

Reduce AI vendor lock-in by testing what your team can move before you sign or renew. Ask one engineer to restore a real type of task in a separate test environment. Check its records, permissions and unfinished work, then price the gaps in engineering time.

For a founder or CTO with a small team, the expensive surprise is the product work you have to postpone. A cheaper AI subscription helps little if switching consumes the same engineers who are meant to ship your next feature.

Start with your most important workflow. A recoverable export and a manual fallback may be enough; two live providers would add another system to maintain. The useful question is whether another authorised environment can continue the work your business needs.

Product changes make this a current operating question

OpenAI’s deprecations page, checked 8 October 2026, lists reusable prompt objects and the v1/prompts API as scheduled to shut down on 30 November 2026. Its documented migration moves reusable prompt content into application code. Even if you keep the same provider, someone must find those dependencies, move the prompts and test the affected features.

Put that work on the roadmap with an owner. The same question comes back when a price changes, a contract ends or your required deployment becomes unavailable: who can make the change, and which delivery commitment moves to accommodate it?

Focus first on the workflow that would hurt most to lose. A personal drafting assistant and a customer-facing process with pending transactions need different exit evidence.

The export test that exposes the rebuilding bill

Imagine your 12-person SaaS company uses an AI tool to process incoming contracts. In this illustrative example, the export contains every document and conversation. But when your engineer tries to resume a pending case elsewhere, the approval owner, access rules and receipt for a sent notification are missing.

That gap matters more than the file format. Someone must reconstruct the state before the replacement can safely continue. Your acceptance test should therefore restore a fresh case, a pending approval and a completed action, with enough evidence to tell them apart.

Put numbers against the gap. Assume 40 engineering hours to rebuild the missing workflow and 8 hours to reconcile records, at an internal planning rate of €80 per hour. That is 48 hours and €3,840. If the replacement saves €400 a month, those labour costs alone take 9.6 months to recover. Hosting, supplier charges and disruption would extend that period. These are assumed inputs for a buying decision; replace them with your team’s estimate.

If the work fits your existing team’s capacity, keep it there. If the product roadmap is already full, compare the delay with adding an AI/ML engineer to your team. Either way, assign the work before accepting the supplier’s export demonstration.

Inventory the assets that keep the workflow running

Start with one diagram or list of dependencies. Mark what your team controls, what the supplier stores and what another connected service owns. Do not copy credentials into an inventory or migration archive.

Include only assets your application uses and that your organisation may legitimately transfer. Make their relationships explicit. Which document supports this answer? Which customer owns this case? Which source version was used? Otherwise, a collection of files can become a costly reconciliation project.

Persistent agent context adds another dependency. Separate approved reusable facts from conversation history, temporary assumptions and sensitive material. Our agent memory guide covers how to define those records and their lifecycle.

Decide what an acceptable exit means

Choose the outcome your business needs: a model replacement, a platform exit or a continuity fallback. Each requires a different amount of engineering.

A model replacement keeps the application and changes inference. The team still needs to adjust provider-specific settings and compare task quality.

A platform exit may also move stored records, orchestration, connectors, user experience and operating controls. It can involve a meaningful rebuild.

A continuity fallback keeps essential work available while the normal AI path is unavailable. A manual queue or reduced-function service may cover the interruption.

Write a target for the workflow: which functions must return, what interruption is acceptable and which work may wait. Set the requirement from the business consequences, not a universal recovery time copied from another company.

The surrounding architecture determines which responsibilities can move. Review our API, platform and framework comparison before assuming a direct API removes every dependency.

Run a clean-environment exit rehearsal

Give the engineer responsible for your integration these acceptance checks. Start with a small set of sanitised cases that exercise the workflow you actually use.

1. Select cases that reveal real dependencies

Use permitted, sanitised fixtures in a separate environment. Include a new request, an unfinished request, an approval waiting for a person and a completed action whose response was lost. Add a denied-access case.

Record the starting state and expected outcome. Avoid relying entirely on easy examples that only ask for text. If the application changes another system, the rehearsal must inspect that system’s state.

2. Export through the documented supported path

Have your team perform the export with the intended customer permissions. Record the format, fields, duration, omissions and any supplier assistance required.

Inspect the contents. Can you distinguish records with stable identifiers? Are instructions readable outside the product? Can you identify the source and version behind a retained fact? Record gaps as gaps, rather than treating a successful download as a passing exit.

3. Restore without the original platform

Use a separate approved environment. Disable access to the original platform for the tested workflow so hidden calls cannot make the rehearsal look successful.

Restore the necessary records and configuration. Rebuild derived retrieval indexes from original sources if that is the chosen path. Record the rebuilding effort and requirements; regeneration can be acceptable even when direct export is unavailable.

4. Re-establish identity and permissions

Create or authorise the destination’s approved identities. Check access with a permitted user and a denied user. Do not assume a copied role name or connector definition carries the original authorisation with it.

For Model Context Protocol, or MCP, the 25 November 2025 authorisation specification requires servers to validate tokens intended for them and forbids passing the client’s token through to an upstream service. Treat credentials as destination-specific, even when the tool interface stays the same.

5. Continue work without repeating side effects

Inspect pending approvals and previously completed operations. The replacement should not turn an old “please send” instruction into a new send merely because it imported the conversation.

Verify destination receipts where available. Pause unresolved outcomes for reconciliation. Our safe agent retry guide explains how an action can succeed even when its acknowledgement is lost.

6. Compare usefulness and record the remaining gap

Run the defined cases against the replacement. Assess accepted outcomes, access failures, review effort, latency and total operating cost. A schema-compatible response can still be factually wrong or unsuitable for the task.

Use the same acceptance criteria rather than requiring identical wording. Apply the methods in our agent evaluation guide. Record what passed, what requires rebuilding and what cannot currently be recovered. A partial success is useful evidence when its limits are explicit.

Keep deletion separate from export and restoration

Restoration and deletion are separate jobs. After you have a working replacement, check the old supplier’s retention and deletion rules for each feature you used.

For example, OpenAI’s API data-control documentation distinguishes abuse-monitoring logs from application state. Retention differs by endpoint, and data sent to third-party MCP servers follows those services’ retention policies. Map the equivalent stores and rules for your chosen supplier.

Map the stores your workflow creates: active records, derived indexes, logs, replicas and backups where relevant. Identify who is responsible for each. After a verified cutover, revoke obsolete credentials and follow the applicable deletion process. Obtain the evidence your requirements call for; do not promise complete erasure from one successful delete request.

Choose the dependency your team can afford

Use the rehearsal to decide whether to buy, negotiate or build. Ask the supplier to demonstrate its supported export process and identify exclusions. Your founder or CTO can own this short decision record, with legal advice where contract or data obligations need interpretation:

• Specify the assets and relationships the exit must preserve.
• Identify formats, supported interfaces and known limitations.
• Clarify export assistance, charges and access after termination.
• Assign migration responsibilities and a way to resolve missing records.
• Define how product changes and retirements enter your review process.
• Document deletion obligations and available evidence for each store.

A standard product may offer enough value to justify a known rebuilding cost. Accept that dependency deliberately, with an owner, an estimate and a fallback. Build custom software when control of the workflow justifies its ongoing engineering cost.

Keep any multi-provider design proportionate to that decision. If important state and controls remain trapped in one platform, a router changes little. Our LLM routing guide addresses request selection; an exit plan addresses recovery of the required workflow.

Frequently asked questions

Does an OpenAI-compatible API prevent AI vendor lock-in?

No. Request compatibility can reduce integration work. Tools, stored state, permissions and task quality still need separate testing with the features your application uses.

Do we need two AI providers in production immediately?

Not necessarily. A maintained export, tested restoration and adequate manual fallback may fit the risk. Running two providers adds cost and maintenance. Use it when continuity requirements justify that burden.

Should we require vector embeddings in the export?

Only if they are useful and permitted to transfer. Original sources, metadata and access mappings may let you rebuild retrieval with the destination’s embedding model. Test rebuilding effort and quality before accepting that approach.

How often should we rehearse the exit?

Set the cadence from criticality and change. Recheck after material changes to storage, tools, providers or workflow state, and before a consequential renewal. Keep the recovery test aligned with the application you run today.

If you need to build or replace the AI workflow, explore Powercode Group’s AI development and integration services. Tell us what the workflow must do, which systems it connects and who can own it internally. That gives us a concrete starting point for discussing the engineering you need. If a supported export and manual fallback already cover your risk, keep the simpler setup.