Vendor Exit-Cost Checklist
Use this before selecting a vendor, renewing a contract, or embedding a managed service deeper into production. Unknown exit cost counts as high until tested.
Dependency Snapshot
Scoring
Score each area separately. The overall score is the worst unmitigated layer, not an average. One unknown critical layer is enough to treat the dependency as high exit cost.
Low
Replacement path is known, tested on a small slice, and bounded to local code or configuration changes.
Bounded
Migration is meaningful work, but data, interfaces, operations, and timing constraints are understood.
High
Migration touches multiple systems, owners, data models, contracts, or production procedures.
Unknown
No tested export, unclear contract clock, undocumented dependencies, or no named replacement path.
Checklist
| Done | Area | Question | Evidence | Score |
|---|---|---|---|---|
| Data exit | Can all required data be exported without vendor assistance, including history, deletes, metadata, attachments, and audit records? | Recent export test, reconciliation counts, documented gaps, throughput limits. | Low / Bounded / High / Unknown | |
| Data format | Does the export land in a neutral, documented format the team can load without the vendor platform? | Schema notes, sample files, import script, restore target. | Low / Bounded / High / Unknown | |
| Semantics | Which vendor concepts have become business concepts inside the domain model, reports, or customer-facing behavior? | Object mapping, state-machine mapping, known semantic mismatches. | Low / Bounded / High / Unknown | |
| Runtime | What code calls vendor APIs, SDKs, query dialects, webhooks, auth flows, or retry semantics directly? | Dependency search, service map, adapter inventory, direct-call exceptions. | Low / Bounded / High / Unknown | |
| Operations | Which runbooks, alerts, dashboards, backups, deployment procedures, and access reviews exist only inside the vendor control plane? | Runbook list, dashboard list, backup restore result, access-review evidence. | Low / Bounded / High / Unknown | |
| Reliability | Does the replacement need to preserve latency, consistency, durability, support, or compliance properties that are not obvious from the feature list? | SLOs, incident history, failure-mode notes, compliance obligations. | Low / Bounded / High / Unknown | |
| Skills | Which team knowledge is vendor-specific, and who can operate the replacement without external support? | Named owners, skill gaps, training plan, support model. | Low / Bounded / High / Unknown | |
| Contract | What renewal date, notice period, minimum commit, reserved capacity, export clause, or support cutoff controls the migration clock? | Contract excerpt, renewal calendar, termination-assistance terms. | Low / Bounded / High / Unknown | |
| Alternatives | What realistic replacement paths exist: open source, managed open source, competing vendor, self-hosted, or internal build? | Shortlist, rejected options, compatibility notes, cost range. | Low / Bounded / High / Unknown | |
| Rehearsal | Has one small exit slice been run: one tenant, one dashboard, one service, one backup, or one reporting cycle? | Rehearsal date, result, defects found, next test date. | Low / Bounded / High / Unknown |
Rule: Do not average away unknowns. If data exit, contract timing, or operational replacement is unknown, the dependency is high exit cost until proven otherwise.
Decision Note
Attach this summary to the architecture decision record, vendor-selection memo, or renewal review. It should be readable by engineering, procurement, security, and leadership.