COURSE 25L1100% FREE
Verified 2026-08-14

Exit plans and portability

How to avoid lock-in: export data, abstract vendors, keep eval harnesses portable, and practice failover. Service terms and product SKUs change; portability is risk management, not paranoia. <!-- IMAGE: app → interface → provider A/B wit...

What it is

How to avoid lock-in: export data, abstract vendors, keep eval harnesses portable, and practice failover. Service terms and product SKUs change; portability is risk management, not paranoia.

<!-- IMAGE: app → interface → provider A/B with shared eval harness -->

MEDIUM PRIORITYFLOWCHART
◷ IN PRODUCTION

Visual Spec & Architecture Diagram

Exit plan flowchart: export data → re-embed → alternate vendor/self-host → cutover drill. Lock-in risk icons.

Educational Focus: Portability as risk management.

Why it matters

Vendors change prices, regions, retention defaults, and indemnity wording. API terms (OpenAI, Gemini, AWS Bedrock sections, Microsoft product terms) are living documents—dates matter. An exit plan turns a surprise into a drill.

How it works (plain)

  1. Store prompts/evals in git.
  2. Wrap providers behind interfaces.
  3. Keep export paths for corpora and logs you own.
  4. Quarterly: run golden sets on a second provider or open-weights path.
  5. Re-read current primary terms before renewals.

Everyday example

Keeping a spare tire and knowing how to change it—not only carrying the manufacturer’s phone number.

Try it

Write a one-page exit plan for your primary model vendor: data export, prompt portability, eval pass criteria, and who owns the cutover.

Myths

⚠️ Myth: Contracts alone are an exit plan.
✓ Reality: You need technical portability drills.
⚠️ Myth: “OpenAI-compatible” means identical behavior.
✓ Reality: Compatibility is partial; evals must prove parity.

Sources