AI Vendor Exit Checklist: Migrating Off a Provider Without Losing Production Continuity

Why Vendor Exits Fail (and It Is Not the New Provider's Fault)

Most AI vendor switches that break production share three problems. No code ownership. No way to export data. No tested fallback. These are not mistakes made during the move. They are gaps left in the contract on day one.

When a team starts a vendor exit, they often find several problems. The pipeline code sits in the vendor's private repo. The fine-tuned model weights are in a format the new provider cannot read. The incident runbook refers to steps only the vendor's staff can take. None of this was in the original contract. The migration stalls until each gap is fixed. No one budgeted for that time.

The root cause is missing Audit Criterion 10 from sincllm's 10-Point AI Vendor Audit: a written handover plan with no lock-in. Most AI contracts cover uptime and SLOs. They say nothing about exit rights. A vendor can hit 99.9% uptime and still own your code, your data, and your runbooks. That makes leaving expensive. Uptime and exit rights are two separate things. The SLA covers runtime. The handover clause covers exit.

The NIST AI RMF 1.0 GOVERN function requires third-party AI vendor exit planning as part of responsible AI deployment (see NIST AI RMF 1.0). ISO/IEC 42001:2023 requires supplier management that covers transition and handover (see ISO/IEC 42001:2023). Both treat exit planning as a contract requirement. You settle it upfront. You do not clean it up after the move.

Before You Migrate: What You Need From the Exiting Vendor

1. Demand a Complete Handover Package

The handover package is not just a data export. It is a transfer of full ownership. A complete package includes several items. A git repository URL where your team is the owner (not a zip file). All model config files in a format you can reuse elsewhere. Integration scripts and API client code with clear dependency notes. API keys and credential hand-off steps with defined revocation dates. Written notes on every custom change the vendor made that is not in the public API.

The practical test is simple. Can your team get the integration running from the handover materials alone? No vendor call allowed. If the answer is no, the handover is not done.

This maps to Audit Criterion 3 (source-code ownership and audit trail). sincllm's own production work shows why code ownership matters: see engineering proof that replacing an API provider is feasible when the code is yours. Without code ownership, the migration schedule is controlled by the vendor. Your team does not set it.

Read the source-code ownership contract clause analysis before signing your next contract. It covers the exact language to require.

2. Confirm Data Portability and Export Format

Training data, fine-tune datasets, and logged inference history often sit in the vendor's cloud. There may be no clear export path. The contract may have a data-residency clause that blocks export to certain regions. Finding this out during migration, instead of before it, adds weeks to the timeline.

Ask for these items in writing before migration starts. The export format for all training data and fine-tune datasets. The export format for logged inputs and outputs, including date range. Any data-residency restrictions on the export. The vendor's data retention and deletion schedule after the contract ends.

This maps to Audit Criterion 9 (data-handling and privacy boundaries). The EU AI Act (Regulation 2024/1689) puts documentation and handover duties on providers of high-risk AI systems. This includes data portability at contract end (see EU AI Act). To check a replacement provider's data handling, use the Build vs Buy Framework. It covers data sensitivity and residency as Criterion 3.

3. Get the Incident History and Runbook

The incident history is a critical migration artifact. The new team inherits the old system's failure modes. Without the incident log, they will hit each failure in production again. They will not know how it was fixed the first time.

Here is a concrete example. The outgoing vendor may have quietly fixed a prompt-injection attack by adding a server-side filter. The new team may not know the filter exists. They will not copy it into the new integration. Then the same attack hits production with no defense in place. OWASP LLM Top 10 (2025) lists supply chain vulnerabilities (LLM05) as a main risk area for vendor-exit planning (see OWASP LLM Top 10 2025).

Ask for three things. The full incident log for the past 12 months. The current on-call runbook with escalation steps. Notes on any known failure modes and how they are currently handled. This maps to Audit Criterion 8 (on-call and incident response).

During Migration: Running Parallel Without Breaking Production

4. Stand Up a Shadow Environment Before Cutting Over

A shadow environment sends a small share of live traffic to the new provider. The old integration keeps answering real users. Shadow responses are logged and compared. They are never sent to the end user. This is not a full parallel system. It is a read-only tap on your existing traffic.

Start with 5% of traffic routed to the new provider. Set your pass/fail criteria before the shadow run starts, not after. Define target latency at p95, accuracy on your evaluation set, and cost per resolved task. A shadow run without defined criteria is just watching. It is not a real gate.

sincllm uses this parallel-run and shadow-testing method in production. The production migration example of a local model replacing a vendor API without downtime used controlled traffic routing before cutover.

5. Establish a Fallback Path Back to the Exiting Vendor

The old vendor integration must stay live and tested. Keep it running until the new one passes a defined evaluation period. This is Audit Criterion 5 (fallback paths). A fallback you have not tested is not a fallback.

"Live and tested" means one specific thing. A synthetic request sent to the old provider every day. An alert fires if that path returns an error. It does not mean "we kept the old API keys." A fallback path untested for two weeks will fail when you need it. You will need it at the worst possible moment.

Set the evaluation period before migration starts. A good baseline is 5 business days of shadow traffic passing your success criteria before cutover. Adjust based on workload criticality and available evaluation data.

6. Migrate Monitoring and Alerting First, Not Last

The most common sequencing mistake is moving the model first and adding monitoring later. A migration without the observability layer fails without warning. By the time an unmonitored error rate triggers a user complaint, the damage is already large.

Every critical path needs a monitor before cutover. This is Audit Criterion 1 (monitoring on every critical path). Think of it like testing circuit breakers before turning the power back on. Monitoring is the diagnostic surface. A system without it fails without warning.

Stand up four monitors before cutover. Latency at p95 and p99. Error rate by endpoint. Cost per task, to catch runaway token use. Accuracy on a synthetic evaluation set run on a fixed schedule.

After Cutover: Verifying the New Provider Before Retiring the Old

7. Run the 10-Point AI Vendor Audit on the Replacement Provider

You are replacing one vendor. To avoid the same contract gaps, audit the replacement provider before signing. All 10 criteria from sincllm's 10-Point AI Vendor Audit apply to the new vendor. That includes monitoring, SLOs, source-code ownership, drift detection, fallback paths, cost-anomaly alarms, rollback cadence, incident response, data-handling, and documented handover.

The contract you sign at the start governs the worst case. The demo and the SLA cover the expected case. Most teams look only at the expected case. The 10-Point Audit checks the worst case. Vendor exits happen in the worst case.

8. Test Rollback Before You Need It

Rollback is not a backup plan. It is an engineering step with a clear trigger and a verified execution path. Set the rollback trigger in metrics before cutover. Options: latency above a threshold at p95, error rate above a percentage, or cost per task above a ceiling. These numbers come from your workload. The vendor does not set them.

Confirm the rollback path is live and tested before shutting down the old provider. This maps to Audit Criterion 7 (model-update cadence and rollback). The verification is simple. Run the rollback procedure in a staging environment. Confirm the old integration responds correctly. Confirm the routing switch finishes within your defined maximum response time.

9. Document the New Architecture and Update On-Call Runbooks

Every architectural change that is not written down is a future incident. The migration is complete only when the new architecture is documented. That means three things. An updated architecture diagram. New on-call runbooks with the replacement provider's escalation paths. Notes on any new failure modes found during the shadow period, with their fixes.

This is not cleanup after the migration. It is an exit criterion for the migration itself. A migration that ends without updated runbooks moves the knowledge gap from the old vendor to the new one.

10. Close the Old Vendor Relationship: Data Deletion and Contract Exit Clauses

After cutover is confirmed and rollback is no longer needed, close the old vendor relationship carefully. Get written confirmation that the vendor has deleted your data from their systems. This is required for GDPR and EU AI Act compliance for most production workloads.

Revoke all API credentials and rotate any keys the vendor had access to. Include keys used for integrations the vendor ran. Check whether the contract has an auto-renewal clause. Many AI vendor contracts auto-renew 30 to 90 days before the end date. Submit the legal notice before that trigger fires. Finding this out after the renewal date means paying for another full term on a provider you have already left.

The Checklist in One View

The table above also helps you spot problems during the handover negotiation. The vendor response patterns below signal structural blockers.

Evaluate Your Replacement Vendor With the Same Rigor

You just finished a difficult exit. Every step in this checklist points to a gap in the original contract. The only way to avoid repeating it is to run the 10-Point AI Vendor Audit on the replacement provider before you sign.

The 10-Point Audit covers all the criteria in this checklist: monitoring, SLOs, source-code ownership, drift detection, fallback paths, cost-anomaly alarms, rollback cadence, incident response, data-handling boundaries, and documented handover. Teams also working through the build-versus-buy decision can use the Build vs Buy Framework. It covers 10 criteria, including data residency and vendor lock-in tolerance.

Note: this checklist is an engineering operations guide. Contract termination, data deletion rules, and regulatory requirements vary by jurisdiction and industry. Teams in regulated sectors such as healthcare and financial services should involve legal counsel. This applies especially to data deletion confirmation and auto-renewal exposure.

Conclusion

A clean vendor exit is an engineering operation, not a procurement event. This checklist maps each migration step to production-engineering controls. These controls should have been in the original contract. The teams that complete vendor exits without breaking production treated exit rights as a real requirement from day one. They did not wait until termination to address it.

The ISO/IEC 42001:2023 AI Management System standard covers supplier relationship management for AI systems. It includes transition and handover requirements at the organizational governance level (see ISO/IEC 42001:2023). The standard treats exit planning as part of the supplier lifecycle, not an afterthought. Production AI teams benefit from the same discipline.