Continuity playbook / 30–60–90 days

Do not rage-quit your AI vendor. Make it replaceable.

A Canadian AI exit plan reduces single-provider risk without breaking the workflows people already use. Inventory, benchmark, dual-run, cut over in slices, and keep a tested rollback.

Build the plan Choose a destination

What is an AI vendor exit plan? It is a tested route for moving a workload, its data, prompts, evaluations, integrations, and operating knowledge away from one model or API provider. The goal is not to delete the old account on day one. The goal is to prove that your organization can keep working when price, policy, model behaviour, jurisdiction, or availability changes.

Start with the dependency graph, not a model shopping list

“We use ChatGPT” rarely describes the whole dependency. Staff may rely on a web app, developers on an API, a CRM on a hidden subprocessor, a document assistant on a proprietary vector index, and an automation on tool-calling behaviour that exists only in one model. The exit plan must follow the workflow from input to outcome.

Inventory	Capture	Exit question
People	Users, owners, approvers, support, and shadow-AI use	Who stops working if access disappears?
Data	Prompts, files, personal information, IP, embeddings, logs, outputs	What must move, remain, or be deleted?
Application	SDK, endpoint, authentication, tools, schemas, streaming, rate limits	Which behaviours are genuinely portable?
Model	Quality, context, modalities, language, safety, failure modes	What minimum result must a replacement pass?
Operations	Monitoring, incidents, retention, vendor support, cost, recovery	Can the team operate the replacement?
Contract	Renewal, export, deletion, audit, subprocessors, governing law	What rights exist before the deadline?

The 30–60–90 day migration

Days 0–30: know what must survive

Inventory all AI use.
Include browser tools, APIs, embedded SaaS, automations, retrieval indexes, model gateways, and unofficial staff use.

Classify the data and business criticality.
Separate public, internal, confidential, personal, privileged, safety-relevant, and contract-restricted workloads.

Freeze a representative evaluation set.
Capture real, authorized examples with expected results and failure criteria. Remove or synthesize sensitive data where evaluation does not need it.

Set the control objective.
Decide whether the destination must be Canadian-hosted, Canadian-operated, on premises, air-gapped, model-origin constrained, or simply portable.

Days 31–60: prove a second path

Add a model-neutral application boundary.
Where practical, place prompts, policies, schemas, and routing behind an internal gateway instead of scattering vendor-specific calls through every application.

Benchmark candidates on your work.
Compare outcome quality, citations, language, tool use, latency, throughput, context, refusals, hallucinations, and cost. Record the exact checkpoint and settings.

Dual-run one bounded workflow.
Send a controlled sample to both paths, review differences, and keep the incumbent as rollback. Do not put sensitive data into a candidate until its boundary is approved.

Rebuild the knowledge layer portably.
Export source documents, permissions, chunking rules, embeddings where useful, and retrieval evaluation. A proprietary index can be a deeper lock-in than the model.

Days 61–90: move in slices

Cut over low-risk, high-volume work first.
Classification, extraction, drafting, summarization, internal search, and routine coding often make better first moves than rare frontier tasks.

Train operators and users.
Document capability differences, approved data, escalation, model selection, recovery, and when a human must decide.

Exercise failure and rollback.
Disable the primary route in a planned test. Confirm that authentication, capacity, DNS/routing, data access, and user instructions actually work.

Renegotiate from strength.
Once a replacement path works, reduce committed volume, improve exit and retention terms, or retire the incumbent where the evidence supports it.

What an exit-ready architecture keeps portable

Evaluation cases independent of one provider’s dashboard.
Prompts and policies versioned outside vendor-specific assistants where possible.
Application schemas and tool contracts with compatibility tests.
Source documents and access rules outside a non-exportable knowledge base.
Observability that can compare routes without retaining sensitive content unnecessarily.
Model and runtime inventory with licences, hashes, settings, quantization, and provenance.
Operator knowledge in your runbook rather than one vendor’s support queue.

Do not trade vendor lock-in for GPU lock-in

Self-hosting changes the dependency; it does not erase it. CUDA, drivers, firmware, model licences, serving runtimes, quantization formats, and the person who knows how the cluster works can each become a new choke point. Prefer standard APIs where they are real, preserve original source files, keep infrastructure documented, maintain more than one viable checkpoint, and test restore procedures.

D-Central can run the migration workstream

We can inventory the current dependency, build the evaluation harness, qualify open-weight candidates, design the Canadian-hosted or on-premises destination, dual-run a pilot, and hand over the operating plan.

Request a migration assessment

Frequently asked questions

Should we cancel our U.S. AI contracts now?

Usually not before a replacement is tested. Urgency should shorten the inventory and pilot cycle, not eliminate rollback. Immediate restrictions may be appropriate for unapproved sensitive data; contract termination is a separate decision.

Can an OpenAI-compatible endpoint make migration automatic?

It can reduce code changes for common chat and embedding calls. Tool use, structured outputs, tokenization, context, multimodal input, safety behaviour, and streaming still vary. Compatibility is a starting point, not an acceptance test.

What should we migrate first?

A repeatable workflow with clear success criteria, meaningful volume, manageable risk, and data that benefits from a stronger control boundary. Avoid choosing the most politically visible or technically exotic workload as the first proof.

How do we compare models fairly?

Use the same authorized examples, scoring rubric, system instructions, tools, retrieval sources, output limits, and review process. Record exact model versions and settings. Public leaderboards help shortlist candidates; your evaluation decides production fit.

Can a hybrid architecture still be sovereign?

Sovereignty is not all-or-nothing. A governed hybrid can keep sensitive and business-continuity work on a controlled route while using a frontier API for explicitly approved tasks. The key is that the foreign API is a choice, not the only way the business can function.

Supporting guidance: Canadian Centre for Cyber Security: Top 10 AI security actions; OSFI Guideline B-10: third-party risk management; D-Central cloud AI provider comparison.

Related products, repair, and setup paths

Last reviewed August 24, 2026.