Most AI procurement teams know they should think about exit costs before signing a vendor contract; almost none have a model that produces a number. The result is a procurement conversation in which “this is high lock-in” and “this is acceptable lock-in” are settled by intuition rather than dollars, and a finance conversation in which the carrying cost of staying with the wrong vendor is invisible because nobody has computed the alternative. The fix is a five-component exit-cost model that turns the abstract worry into a defensible figure: data migration, prompt rewrite, model re-evaluation, integration re-plumbing, and operations retraining. Each component has a directly observable cost driver, a labor multiplier, and a duration; together they produce the dollar number procurement and finance can argue from. This piece names the components, gives the formulas, and runs the numbers on a representative mid-market AI feature so the math is concrete instead of abstract.
The AI build-vs-buy-vs-hire decision matrix for 2026 argues, in its seventh principle, that most sourcing decision is re-litigated quarterly; the exit-cost model is the artifact that makes the re-litigation comparable to the alternatives.
Why a model, not a number
A single-number “what is our exit cost from vendor X” cannot survive cross-examination because the underlying drivers are heterogeneous: some are data-volume-driven, some headcount-driven, some calendar-driven, some dependent on whether the team has done this kind of switch before.
A model produces the same number but exposes the assumptions. Two reviewers who disagree can locate the disagreement at the assumption level and resolve it independently of the headline.
The model also makes the number stable across time. Components are constants; inputs drift predictably with usage. A vendor whose exit cost was $200K at engagement start and is $1.2M two years later has accumulated 6x more data, 3x more prompts, and 5x more integration points; the model exposes which driver dominates.
Component 1: data migration
Data migration is the cost of getting your data out of the vendor’s environment and into the new vendor’s environment in a usable form. It has two sub-costs.
Egress cost is what the current vendor charges for data export; egress fees, format-conversion fees, support charges if the export is non-self-serve. Most foundation model vendors do not charge for egress directly but may charge for the data formats most useful for migration (e.g., embeddings in their proprietary format are free; embeddings re-computed against an open standard cost compute time).
Ingest cost is what the new vendor (or your own infrastructure) charges to receive the data. For embeddings re-computation, this is foundation-model API time at the new vendor’s rates. For vector-index rebuild, this is the compute cost of re-indexing. For fine-tuning datasets, this is the cost of running the fine-tuning job at the new vendor.
Formula: data migration cost = egress fees + ingest compute + (data engineer hours × loaded hourly rate).
Data engineer hours scale roughly logarithmically with data volume; a 10x increase in data volume produces roughly 1.5x increase in engineer hours, because the work is mostly setup rather than per-record. The rate at which the work scales with engineer seniority is roughly inverse-quadratic; a senior engineer does the migration in a quarter of the time of a mid-level engineer, not half.
Typical range for a mid-market AI feature: $20K-$80K for data migration alone.
Component 2: prompt rewrite
Prompt rewrite is the cost of porting your prompts from the old vendor’s conventions to the new vendor’s. Even when prompts live in your repository in vendor-neutral form, vendor-specific behavior leaks: the way the model handles system prompts vs. User prompts, the function-calling syntax, the tokenizer differences that change instruction following, the model-specific patterns the prompts have been tuned against.
The cost is dominated by re-tuning, not re-typing. Typing the new prompts is hours; re-tuning them against the new model’s actual behavior to recover the old quality is weeks.
Formula: prompt rewrite cost = (number of distinct prompt templates × prompt-engineer days per template × loaded daily rate) + eval-rerun cost.
Prompt-engineer days per template ranges from 1 (simple prompt, mature evals catching regressions automatically) to 10 (complex prompt with multi-step reasoning, sparse evals, target model behaves differently in subtle ways).
Eval-rerun cost is the foundation-model API spend to run the full eval suite against the new vendor; typically $1K-$10K per run, with at least 5-10 runs needed during the rewrite period.
Typical range for a mid-market feature with 20-50 prompt templates: $50K-$200K.
Component 3: model re-evaluation
Model re-evaluation is the cost of confirming the new vendor’s model meets the same quality bar as the old one. It is the most variable component because it depends entirely on how mature the eval set is.
If the eval set is mature (axis 4 = 0 in the vendor lock-in audit), re-evaluation is mostly automated. The eval runner targets the new vendor, runs the suite, and produces a comparison report. The cost is API spend plus a few engineer days to interpret results.
If the eval set is immature (axis 4 = 2 or 3), re-evaluation is a project. The team has to write or rewrite test cases, define scoring functions, validate that the scoring functions agree with human judgment, and run the suite enough times to stabilize results. This can take 3-6 months for a non-trivial use case.
Formula: re-evaluation cost = API spend × eval runs + (eval-engineering days × loaded daily rate) + (subject-matter-expert days for human-in-loop validation × loaded SME daily rate).
Typical range: $30K (mature evals) to $400K (immature evals requiring rebuild).
The matrix’s fifth principle; that eval infrastructure must be built or hired, rarely bought; is partly a hedge against this component. A mature eval set caps re-evaluation cost in low five-figures; an immature one uncaps it.
Component 4: integration re-plumbing
Integration re-plumbing is the cost of changing most place in your application code that touches the vendor. The cost depends on the integration depth scored on axis 6 of the lock-in audit.
If integration depth is shallow (one adapter, vendor-neutral interface), re-plumbing is rewriting the adapter; typically 2-5 engineer-weeks.
If integration depth is medium (vendor-specific assumptions in several modules), re-plumbing touches most module that holds those assumptions, plus the adapter; typically 8-16 engineer-weeks.
If integration depth is deep (no adapter, vendor calls inline throughout), re-plumbing is a partial rewrite; typically 24-52 engineer-weeks.
Formula: integration re-plumbing cost = engineer-weeks × loaded weekly rate × (1 + risk premium).
Risk premium accounts for the regression-debugging tail. Most teams underestimate it by 30-50%. A 10-week estimate becomes 13-15 weeks. Build the premium into the model so it is explicit rather than emergent.
Typical range: $40K (shallow) to $500K (deep).
Component 5: operations retraining
Operations retraining is the cost of bringing the on-call, support, and SRE teams up to operational fluency with the new vendor. It is the most often forgotten component because it does not produce a deliverable that engineering management tracks.
Sub-costs include runbook rewrites for incidents that cite vendor-specific behavior, dashboard updates for the new vendor’s metrics and APIs, on-call training for the new vendor’s escalation paths, customer-support knowledge-base updates for any user-facing changes, and a tail of “we keep operating like the old vendor for 90 days” miscalibration cost (incidents misdiagnosed because the team’s intuition is still pattern-matching the old vendor).
Formula: operations retraining cost = (operations-engineer days × loaded daily rate) + (support-engineer days × loaded daily rate) + miscalibration tail cost.
Miscalibration tail cost is the rough dollar value of incidents that take longer to resolve because the team’s intuition is still tuned to the old vendor. A reasonable approximation is 90 days at 1.5x normal incident-resolution cost.
Typical range: $20K-$80K for a mid-market organization.
Worked example
Consider a mid-market SaaS company running a customer-facing AI feature: chat-style search over the company’s documentation, plus an in-product AI assistant for power users. The current vendor is a large foundation model provider; the team is contemplating switching to a different foundation model provider plus a separate vector store.
Component inputs:
- 12 TB of conversation logs, 800M embeddings, 50K fine-tuning examples
- 35 distinct prompt templates with active production traffic
- Eval set lives in vendor’s evaluation product (axis 4 = 2), 600 test cases
- Adapter exists but vendor-specific assumptions in 8 modules (axis 6 = 2)
- Operations team of 6, on-call rotation of 4 engineers
- Loaded engineer rate: $1,800/day; loaded SME rate: $1,200/day
Component costs:
- Data migration: egress is free; ingest re-embeds at $0.10 per 1K embeddings = $80K compute; data engineering is 12 days senior at $1,800 = $22K. Total: $102K
- Prompt rewrite: 35 templates × 5 days average × $1,800 = $315K. Eval reruns 8 × $5K = $40K. Total: $355K
- Model re-evaluation: rebuild of immature eval set, 60 eval-engineer days at $1,800 = $108K. SME validation 30 days at $1,200 = $36K. API spend $25K. Total: $169K
- Integration re-plumbing: medium depth, 12 engineer-weeks × $9,000/week = $108K. Risk premium 40% = $43K. Total: $151K
- Operations retraining: 25 ops-eng days at $1,800 = $45K. Support 15 days at $1,500 = $22K. Miscalibration tail 90 days × $500/day = $45K. Total: $112K
Total exit cost: $889K. Estimated duration: 10-14 months end-to-end.
This number is the input to the procurement decision. If the alternative vendor’s annual cost is $200K lower than the incumbent, the breakeven on a switch is 4.5 years. If the alternative is $400K lower, breakeven is 2.2 years. Anything inside two years is decisively worth switching; anything outside five years is decisively worth staying. Anything between is the negotiation zone the model exposes.
What the model does not capture
The model captures direct cost. It does not capture:
Opportunity cost of the engineering team during the switch. Twelve months of senior engineering attention going into a switch is twelve months not going into product features. For most teams this is the largest unmodeled cost.
Risk of switch failure. A non-trivial percentage of vendor switches fail and revert. The model assumes the switch succeeds. A risk-adjusted model would multiply by a probability-of-success factor; we have not seen this done well in practice and prefer to discuss it as a separate risk.
Strategic optionality. Switching to a vendor that opens new product possibilities (better function calling, lower latency, multimodal capabilities) has positive value not captured by the cost model.
Vendor relationship cost. Some vendors react badly to switching threats and tighten contract terms going forward; others react well and offer concessions. The model does not capture this.
The detail on contracting structure that anticipates exit costs is in the AI procurement maturity model; stage 4 procurement maturity includes the exit-cost model as part of the standard pre-signing artifact.
Frequently asked questions
How accurate is the model in practice?
We have validated the components on a dozen actual switches in 2024-2025; the model came within 25% of actual cost in roughly 70% of cases. The dominant source of error is integration re-plumbing, which is consistently underestimated.
What if the eval set is fully mature?
Component 3 drops to $30K-$50K. The composite exit cost typically drops 25-40% when evals are mature, which is a large part of the ROI argument for rarely buying eval infrastructure.
Should this be computed annually or quarterly?
Quarterly. Inputs drift fast; data volumes, prompt counts, integration points many grow. A quarterly recompute keeps the number honest.
Is a $0 exit cost achievable?
No, and a vendor whose exit cost is reported as $0 has not been integrated. The minimum non-trivial exit cost is the data migration and operations retraining components, which together are at least $30K-$100K for any production feature.
How does this relate to the lock-in audit?
The lock-in audit scores axes 0-3; the exit-cost model converts the axis scores into dollars. Each axis maps to a component: axis 1 to data migration, axes 2-3 to prompt rewrite, axis 4 to re-evaluation, axis 6 to integration re-plumbing, axis 7 to operations retraining.
Should the exit-cost model be shared with the vendor?
Selectively. A high exit cost is a negotiation lever in renewal; “renewing at this rate is cheaper than switching, but only by $X” is honest math the vendor’s account team can act on.
Does the model apply to internal tools too?
Yes. Internal-tool exit cost is often higher than foundation-model exit cost because internal tools accumulate workflow integrations more aggressively. Run the model on most AI vendor in the stack, not just the headline ones.
What is the typical range for a serious mid-market feature?
$400K-$1.5M for a single AI feature with two years of production usage. Smaller features can be $100K-$300K; large platform commitments can be $5M+.
How does this connect to the build-vs-buy-vs-hire matrix?
The matrix decides what to source from where; the exit-cost model is the carrying cost of each “buy” decision and the avoided cost of each “build” decision. Together they price the sourcing portfolio honestly.
What is the cheapest way to drive exit cost down?
Eval discipline (component 3) and integration discipline (component 4). Both compound: most quarter of mature eval discipline makes future exits cheaper, and most quarter of adapter discipline does the same.
Key takeaways
Exit cost is a five-component model: data migration, prompt rewrite, model re-evaluation, integration re-plumbing, operations retraining. Each has observable inputs and a transparent formula; together they produce a dollar number that is defensible to procurement, finance, and the board.
The worked example yields $889K for a mid-market AI feature with two years of production usage. The dominant components are typically prompt rewrite and model re-evaluation when evals are immature; integration re-plumbing dominates when integration depth is deep. The composite drives the breakeven analysis against any alternative vendor.
The model does not capture opportunity cost, switch-failure risk, strategic optionality, or vendor relationship effects. These are out-of-band considerations for the same procurement decision; the model is necessary but not sufficient.
Computed quarterly, the exit-cost model exposes which sourcing choices are aging well (cost rising slowly, evals maturing, integration shallow) and which are aging badly (cost compounding, evals stranded, integration deepening). The cadence of computation matters more than the precision of any single estimate.
Arthur Wandzel
