Glossary
Vendor lock in
Vendor lock in is the accumulated difficulty of moving off a product once you depend on it, built from data you cannot easily extract, work rebuilt around its shape, and habits nobody wants to change.
In plain terms
Nothing about it is sinister and most of it is not even deliberate. You choose a tool, your content goes into it, your processes take its shape, your team learns its habits, and a year later moving would mean redoing all of that. The tool did not trap you. Dependence accumulated while everybody was busy getting value out of it, which is the ordinary way it happens and the reason it is worth noticing early.
Why it matters
Because the cost of leaving is invisible at exactly the moment you can still do something about it. On the day you choose, alternatives are live and switching costs nothing; two years later the alternatives are theoretical and switching is a project nobody has budget for. That asymmetry is not an argument against committing to anything, which would be its own kind of paralysis. It is an argument for knowing what you are committing to, so the price of leaving is one you accepted rather than one you discovered.
How it works
Content is the first thing to accumulate. Documents, prompts, configurations, saved assistants and the history of what has been asked all build up inside the product. The question worth asking early is not whether an export exists but what the export actually contains, because a file you cannot load anywhere else is an export in name only.
Process takes the tool's shape, and that is usually the deeper hold. Teams reorganise how they work around what the product does well, so moving means changing the work rather than only the software. This is the part that rarely appears in a migration estimate and reliably dominates it.
Integrations multiply the surface. Every connection to another system is a thread that has to be rebuilt somewhere else, and they accumulate quietly because each one is individually small and obviously worthwhile at the time.
Skill and habit are real costs even when nothing technical is stuck. A team that is fluent in one product is slower in any other for a period, and that dip is a genuine expense that gets left out of comparisons because it feels like something other than money.
Some lock-in is a fair trade and should be taken deliberately. Depth usually comes from a product knowing your context, which is the same thing as dependence. The distinction that matters is not whether you have any but whether you priced it, and whether you would make the same choice knowing the exit cost.
How hard would leaving be?
Seen in the wild
Check what an export actually produces from a workspace where the team's documents and saved assistants live, rather than assuming the button is enough.
Notion AIRoute requests through a layer that can address several models, so changing the underlying one is a configuration change rather than a rebuild.
OpenRouterRun an open-weight model on your own hardware, where the dependence moves from a vendor to your own operating capability.
Ollama
Common misconceptions
People assume
An export button means we are not locked in.
In fact
Export answers where the data can go, not whether it can be used when it arrives. What usually cannot be exported is the shape: the configurations, the connections, the accumulated tuning, and the way your process now assumes this product exists. Ask what a competitor could actually ingest.
People assume
Using an open model removes it.
In fact
It removes one kind and substitutes another. You are no longer dependent on a vendor's pricing or roadmap, and you are now dependent on your own capacity to run, update and support the thing. That can be an excellent trade, particularly where data cannot leave, and it is a trade rather than an escape.
Telling them apart
Vendor lock in vs Total cost of ownership
Vendor lock in
What leaving would cost, which is only paid if you go.
What staying costs, which is paid every year whether or not you leave.
One is a contingent cost you can influence now; the other is a running cost you can measure now.
Questions
- How do we assess it before committing?
- Ask what an export contains, not whether one exists, and try loading it somewhere else. Then count integrations, and ask how much of the process would have to change rather than only the software. That last question is the one that separates a weekend migration from a quarter of work.
- Is it always worth avoiding?
- No, and a strategy of avoiding it entirely usually means choosing shallow tools that do less. Depth comes from a product understanding your context, which is dependence by another name. The aim is to take it knowingly on the things that matter and avoid acquiring it by accident on the things that do not.
- Where does it accumulate fastest with AI tools specifically?
- In accumulated configuration rather than in raw data: the prompts, saved assistants, tuned instructions and connections that make the tool useful for your work. Documents usually move; the layer that made them useful usually does not, and it is the layer nobody thinks to inventory before signing.
- Does a short contract protect us?
- It limits the commercial commitment and does nothing about the operational one. If the process has taken the tool's shape, the contract ending simply means the migration happens on a deadline you did not choose. Contract length and switching cost are separate questions and are often confused for one another.
Key takeaways
- Lock in accumulates through ordinary use rather than through anything a vendor does to you.
- Ask what an export contains and whether anything else can load it, not whether one exists.
- Process reshaping is usually the deepest hold and the least estimated.
- Open models move the dependence to your own operating capacity rather than removing it.
- The aim is lock in you priced, not lock in you acquired.
Tools that use this
- Notion AI
Where content, saved assistants and configuration accumulate together.
- OpenRouter
Addressing several models through one layer, so swapping is configuration.
- Ollama
Dependence moved from a vendor to your own hardware and operating time.
Last checked July 2026