Lock-in is a number, and most companies have never calculated theirs
The useful definition is unglamorous: lock-in is the cost in money and calendar time to move to your next-best alternative. That is all it is. It is not a moral failing of the vendor, it is not something you avoid by reading the contract more carefully, and it is not binary. Every system you depend on has a switching cost. The problem is not that the number is high. The problem is that in most companies nobody has ever estimated it, and an unmeasured switching cost behaves exactly like an infinite one, because no board approves a migration whose cost nobody can state.
Procurement is built to examine the contract, and the contract is the cheapest kind of lock-in there is. Term length, auto-renewal, minimum commitments and early-termination fees are all visible, all negotiable, and all measured in money you can name. The expensive kinds are invisible at purchase because they do not exist yet. They are created, month by month, by your own team doing good work.
Five kinds, in ascending order of what they cost to unwind.
Contractual. Term, auto-renew windows, notice periods, minimum spend, termination fees. Read it, negotiate it, calendar the notice date. Genuinely the easy one, and the one most attention goes to.
Data. Your data sits in someone else's schema. There is an export button and it will not do what you hope. It typically gives you current-state rows: not the change history, not the derived and calculated fields, not the audit trail, not the attachments, not the configuration that makes the rows mean anything. And the API endpoint that would give you everything is frequently paginated and rate-limited such that a full extract of a large account takes weeks of careful scripting.
Operational. Your team's habits, your runbooks, your training material, your reports, the forty-step automation somebody built to bridge this tool to two others, the integrations that six departments now assume. This is real accumulated value and it does not transfer.
Architectural. You built on a proprietary primitive with no equivalent elsewhere. This is where cloud lock-in actually lives — not in compute, which is portable, but in the managed service whose specific behavior your code now depends on: the identity model, the queue's exactly-once semantics, the serverless function's execution contract, the database's particular consistency guarantees.
Knowledge. Nobody is left who knows why any of it was configured this way. This is the same failure as an unmanaged contractor handoff, and it converts every other kind of lock-in into a bigger number, because a migration you understand is a project and a migration you do not is an archaeology expedition.
You are probably here because
- A renewal quote came in far above last year's and leaving does not feel like an option
- You are choosing a platform and want to know what you are actually committing to
- Someone asked what it would take to switch and the honest answer was “we don't know”
- You want to move to a cheaper model and cannot prove the cheaper one is good enough
The table prices each kind. The AI section covers dependencies being created right now that nobody is tracking. The export test at the end gives you your real number in about a week.
What each kind costs to unwind
| Kind | What it looks like in practice | Typical time to unwind |
|---|---|---|
| Contractual | Auto-renew with a 90-day notice window nobody diaried | One renewal cycle, plus whatever the exit fee is |
| Data | Export gives current rows, no history, no attachments, no derived fields | Weeks to months, and some of it is simply not recoverable |
| Operational | Reports, integrations, automations and trained habits across several teams | One to two quarters of part-time work across the business, not IT alone |
| Architectural | Code written against a proprietary service with no equivalent elsewhere | A rewrite of the coupled components. Quarters, occasionally longer |
| Knowledge | Nobody remembers why the configuration is the way it is | Adds 30–100% on top of whichever of the above you are doing |
| Evaluation | No owned test set, so no way to prove a replacement is as good | Indefinite. This is the one that stops migrations before they start |
That last row is not a traditional category and it is the one we would put first if the table were ordered by how often it decides the outcome. It gets a section of its own below.
The AI dependencies being created this year
Everything above predates the current wave. What is new is a set of dependencies that feel like implementation details while they are being created and turn out to be the whole switching cost.
Prompts tuned to one model family. A prompt that has been refined over months against one model is not portable in the way source code is portable. It carries hundreds of small accommodations to that model's habits. Moving it to another family usually means re-tuning from something close to scratch, and the work is empirical rather than mechanical — you cannot review it, you have to test it.
Embeddings tied to one embedding model. This is the sharpest one and the least understood outside engineering. Every stored vector was produced by a specific model, and vectors from different models are not comparable at all. Change the embedding model and every vector you hold becomes meaningless in one step. Re-embedding a large corpus is a real project with real compute cost, and it must be done atomically against a live search index.
Fine-tuned weights you cannot export. Several hosted platforms let you fine-tune and never let you take the artifact away. What you own is an account with a name in it.
Managed retrieval and agent frameworks. The document processing, chunking, index and orchestration are the interesting engineering. When all of it is a managed feature of one platform, switching means rebuilding all of it.
The evaluation set you never built. Covered below, because it is the one that matters most.
The one thing most worth owning: an evaluation set
Ask why an organization stayed on a model or a vendor it had outgrown, and the answer is almost never technical difficulty. It is that nobody could demonstrate the alternative was good enough. Without a shared, trusted measure, replacing a working system is a judgment call an executive has to underwrite personally, and executives correctly decline to do that.
An evaluation set fixes that, and it is startlingly cheap. A few hundred real inputs from your own operation, with the correct answers agreed by the people who do the work, stored somewhere you own, in a plain format. Two hundred well-chosen examples change the conversation permanently. Then a swap becomes an afternoon of running both systems over the same set and comparing, and the decision moves from politics to arithmetic.
Build it while the incumbent is working well, for three reasons. You have time. You have goodwill. And you get a baseline of what “good” currently means, which is the number you will want when the renewal quote arrives. Every month you delay makes it harder, because the set should reflect the cases the system actually sees and you have to reconstruct that history later.
Where the switching cost really sits — our ranking
Our judgment of what actually blocks a migration, not a survey. The bottom row gets the most procurement attention and causes the least trouble.
Sometimes lock-in is the right trade, and pretending otherwise is worse
An article that treats all dependency as danger produces a bad decision in the other direction: shallow integration, a portability abstraction over every service, and a system that is worse at its job in exchange for an option nobody exercises. Depth of integration is frequently where the value is. Writing your own layer to keep three databases interchangeable means you get the features of none of them and maintain a translation layer forever.
Being tied to a mature open-source database is a dependency almost nobody regrets, because the exit exists, several vendors support it, and the knowledge is industry-wide. Being tied to a proprietary workflow engine with one supplier and a niche query language is a different trade entirely, even if the software is better on the day you choose it.
Three questions make this concrete. Is the switching cost proportional to the value received? Deep dependency on something that runs your business is a fair trade; the same dependency for a convenience is not. Does anyone know the number? An estimate that is roughly right beats a shrug, because it can be compared with a renewal quote. Is there a second supplier or an open standard underneath? The presence of an alternative disciplines pricing whether or not you ever use it, and its absence is what turns a renewal into an ultimatum.
Run the export test in month one
The single most useful exercise in this article takes about a week and nearly nobody does it, because it feels like distrust at the moment a relationship is starting. Do it anyway, and frame it plainly: it is a business continuity exercise, and a good vendor will help.
Export everything, for real. Not a sample. The full dataset for one meaningful account or business unit, through whatever mechanism the vendor offers, timed honestly. Note what the export does not contain: change history, deleted records, attachments, comments, audit logs, permissions, calculated fields, configuration.
Restore it somewhere else. Into a database, a spreadsheet, anything. The question is not whether a file downloaded. It is whether the exported data still means what it meant inside the product. This is where teams discover that the export has identifiers with no lookup table, or dates without timezones, or that the useful field was computed by the vendor and does not appear at all.
Write down the elapsed time and what was missing. One page. That page is your switching cost estimate, and it is worth more than any clause in the contract.
Do it in month one, not month thirty-six. In month one you have goodwill, a support team eager to help a new customer, and no emotional stake in the answer. In month thirty-six you are angry, the account manager has changed twice, and the request reads as a threat — which is exactly when responsiveness drops. Then repeat it annually. Exports degrade quietly as data models evolve, and an export that worked in year one is not evidence about year three.
Pricing your exit in one week
Keep the page and re-date it each year. It is the document that turns a renewal negotiation from a feeling into a comparison, and it is the only thing that lets a finance team judge whether an increase is worth accepting.
What to ask before you sign
Six asks, all reasonable, all much easier before signature than after. A vendor confident in their product agrees to most of these without discussion, and their reaction to the list is itself information.
A documented, complete export in an open format — and the right to run it whenever you like, not once at termination. Ask specifically whether it includes history, attachments, audit trail and computed fields, and get the answer in writing.
A defined termination assistance period. Thirty to ninety days of continued access at agreed rates after termination, with an obligation to assist a migration. Priced in advance, this is cheap. Requested during a dispute, it is whatever they say.
Data model documentation. Not the API reference — what the entities are and how they relate. Without it an export is a pile of tables with unexplained keys.
Accounts in your name. Cloud accounts, domains, repositories and third-party services under your organization, with the vendor holding access rather than ownership. This is the same rule that governs contractor engagements and it applies identically to platforms.
Renewal and price-increase terms. A cap on annual increases is a normal ask. Without one, your switching cost is the vendor's pricing power, and they know your number better than you do.
Deletion and retention on exit. What happens to your data after termination, how long they keep it, and what evidence of deletion you get. Increasingly a question your own customers will ask you.
The mistakes we are called in to fix
- The first export attempt happens the week the decision to leave is made
- No evaluation set, so no alternative can be shown to be good enough
- Auto-renewal notice windows in nobody's calendar, discovered eleven days late
- Business logic written into a proprietary workflow tool instead of into code you own
- A vector index and its embedding model treated as an implementation detail
- Cloud and third-party accounts owned by the vendor, so leaving means recreating identity
- Integrations built by people who have since left, with no inventory of what depends on what
- Portability abstractions over everything, buying an unused option at the price of a worse system
Before you sign, and again every year
- You have run a full export and restored it somewhere else
- You have written down what the export does not include
- An evaluation set of real cases with agreed answers lives in your own storage
- Notice and renewal dates are in a calendar with an owner
- A termination assistance period exists at a stated rate
- Cloud, domain and third-party accounts are in your organization
- Proprietary primitives your code depends on are listed by name
- Annual price increases are capped, or you know your number and they know you know it
- Data deletion on exit is defined, with evidence provided
- Someone currently employed can explain why the configuration is what it is
Bottom line
Lock-in is not something to avoid; it is something to price. Every dependency worth having costs something to exit, and the question is only whether that cost is proportional to what you get and whether anyone in the building can state it. The measurement is a week of work, and it changes negotiations permanently — because the vendor already knows the number and you are the only party who does not. If you do one thing from this article, run a real export in the first month and keep an evaluation set of your own. Those two artifacts cost very little and they are what convert a renewal from an ultimatum into a decision.
Frequently asked questions
Estimate the money and calendar time to move to the next-best alternative. Concretely: run a full export and time it, restore it somewhere else and list what did not survive, inventory the integrations and reports that depend on the system, and name the proprietary services your own code calls. One page, about a week. An approximate number is enormously more useful than the shrug most organizations currently have.
Both, depending on the layer. Ordinary compute and storage are fairly portable and the fear around them is overstated. The real dependency is on managed services with no equivalent elsewhere — identity models, proprietary queues and event routers, serverless execution contracts, specialized databases. Code that calls those is coupled to that provider in a way that a virtual machine never is. Choose those deliberately and know which ones you have chosen.
Three things that have no analogue in ordinary software. Prompts refined against one model family do not transfer cleanly and must be re-tuned empirically. Stored embeddings are tied to the exact model that produced them, so changing that model invalidates every vector at once. And fine-tuned artifacts are frequently non-exportable, meaning what you own is an account rather than a model. None of it appears in a contract review.
No, and trying usually produces a worse system. Abstraction layers that keep every component swappable give you the features of none of them plus a translation layer to maintain forever. Deep integration is often where the value is. The discipline is not avoidance — it is knowing the switching cost, keeping it proportional to the value, and preferring dependencies with a second supplier or an open standard underneath.
In the first month, and annually after that. In month one you have goodwill and a support team motivated to help a new customer, and no emotional stake in the result. In month thirty-six the request reads as a threat and gets slow-walked. Annual repetition matters because exports quietly degrade as data models change, and last year's successful test says nothing about this year's.