There is a reason some app shutdowns feel like a mild inconvenience and others feel like a hostage negotiation. The difference is vendor lock-in: the collection of technical, financial, and psychological mechanisms that make leaving an app expensive — so expensive that you stay even when you want to go, and so expensive that a shutdown becomes a crisis instead of a move. Understanding lock-in is understanding why shutdowns hurt.
This guide explains lock-in plainly: what it is, the five mechanisms companies use, how to spot it before you commit your data, and what to do when you are already locked in. For the acquisition-flavored version of this story, see When Apps Get Acquired: What Usually Happens to Users; for decoding the notices that start the whole ordeal, our How to Read a Shutdown Notice (and What to Do First) guide has you covered.
What vendor lock-in actually is
Vendor lock-in is the gap between the cost of staying and the cost of leaving. Every product has some switching cost — learning a new interface, moving your files — but lock-in is when that cost is artificially inflated by the vendor’s choices: proprietary formats you cannot take elsewhere, features that only work inside their ecosystem, pricing that punishes exit, or simply the absence of any export at all.
The key word is artificially. Some switching costs are natural and unavoidable; nobody can make learning a new tool free. Lock-in is the portion the company deliberately created or deliberately declined to remove. A notes app that exports to Markdown has natural switching costs. A notes app with no export has lock-in. The distinction matters because it tells you who built the wall — and walls built deliberately rarely get doors later.
Lock-in is not always malicious. Sometimes it emerges from genuine technical choices — a unique data model that genuinely does not map to standard formats — or from a small team’s limited resources. But intent does not change the effect on you: whether the wall was built with malice or neglect, you still have to climb it.
The five mechanisms of lock-in
1. Data lock-in: your data, their format
The most fundamental mechanism. If your data lives in a proprietary format that nothing else reads, leaving means abandoning your history or paying for a painful conversion. Data lock-in is why export formats are the single most important feature to check before adopting an app — it is the mechanism everything else rests on.
2. Workflow lock-in: your habits, their design
Over years, you shape your routines around an app’s specific features — its keyboard shortcuts, its automation system, its unique way of organizing. This is genuine value, but it is also a switching cost: the new app will do things differently, and relearning feels like loss. Workflow lock-in is natural rather than artificial, but it still keeps people in dying apps months longer than they should stay.
3. Ecosystem lock-in: the network around the app
Some apps become hubs: your calendar connects to your tasks, which connect to your notes, which connect to your sharing. Leaving the hub means rewiring the spokes. Ecosystem lock-in is the hardest to see coming because each individual integration felt like a good idea at the time — and each one was, right up until the hub started wobbling.
4. Financial lock-in: money already spent
Annual plans paid upfront, lifetime deals, years of subscription fees — sunk costs whisper that leaving wastes money. They are right, in a narrow sense, and wrong in the sense that matters: the money is gone whether you stay or go, and staying in a dying app to “get your money’s worth” just adds wasted time to wasted money. Recognize the sunk-cost voice and discount it.
5. Social lock-in: everyone you know is here
For collaborative and communication apps, the lock-in is other people. Leaving means convincing your team, your family, or your clients to move too — a coordination problem, not a technical one. Social lock-in is why messaging and collaboration apps are the stickiest software in existence, and why their shutdowns are the most disruptive.
How to spot lock-in before you commit
Run this five-minute check before adopting any app for important data. One: find the export feature and test it — no export, no adoption, no exceptions for critical data. Two: check the format — open standards mean freedom, proprietary means a future negotiation. Three: look at the pricing for exit penalties — annual-only plans, cancellation fees, data retrieval charges after cancellation. Four: assess the ecosystem — every integration you add is a future rewiring job, so integrate deliberately. Five: search for “leaving” or “alternative to” discussions — if long-time users describe exit as painful, believe them.
This check takes five minutes and saves five weekends. Make it a habit for every new signup, and teach it to anyone whose digital life you help manage. It is the highest-leverage preparedness habit in this entire guide.
Already locked in? The escape plan
If you are reading this with the sinking feeling of recognition, here is the escape sequence. First, stop deepening the lock-in: do not add more data, do not buy the annual plan, do not build new integrations. Freeze the footprint. Second, start a parallel export cadence — regular exports in the best available format, stored where you control them. Even a captive app usually permits some extraction; bank it continuously.
Third, choose the replacement using our companion framework for finding alternatives — deliberately, tested with your real data. Fourth, migrate in phases during a calm period, not under shutdown pressure; a planned escape is an order of magnitude cheaper than a forced one. Fifth, once migrated, leave a clean break: cancel, delete, revoke integrations. Lingering half-migrated states are where data goes to be forgotten.
The escape is never free — that is the nature of lock-in — but a planned escape on your schedule costs a fraction of a forced escape on a shutdown deadline. The best time to leave a locked-in app was before you depended on it; the second-best time is now, methodically.
Healthy dependence versus lock-in
Not all dependence is lock-in, and the distinction keeps this guide from becoming paranoia. Depending on an app with open formats, honest pricing, and a sustainable business is healthy — you stay because it is good, and you could leave if it stopped being good. That is a customer relationship. Lock-in is when you stay because leaving is punishing, regardless of quality. That is captivity.
The test is always the exit: can you take your data, in usable form, to a competitor, at a cost proportional to the genuine work of moving? If yes, you have a vendor. If no, you have a landlord. Choose vendors. And when a landlord’s building gets condemned — the shutdown notice — you will be glad your lease was always escapable.
The five-minute lock-in audit for apps you already use
For apps already in your life, run a quick lock-in audit per app: can you export everything that matters, in an open format, right now? Score each of the five mechanisms honestly. Data: full, partial, or no export? Workflow: could you do your core tasks in a competitor tomorrow? Ecosystem: how many integrations would break? Financial: how much prepaid money would you abandon? Social: who else must move with you?
Apps that score badly on three or more mechanisms are your lock-in risks — prioritize them in your next dependency audit and start the slow work of reducing exposure: regular exports, fewer new integrations, no annual renewals. You do not have to leave a high-lock-in app today; you just have to stop the lock-in from deepening while you plan a calm exit on your own schedule.
Frequently asked questions
Can I avoid lock-in entirely?
No — and you should not try. Some switching costs are the price of genuinely useful, distinctive software. The goal is not zero dependence; it is chosen dependence on vendors with open doors, rather than accidental captivity in walled gardens. Minimize artificial lock-in, accept natural switching costs, and keep exits affordable.
Are big ecosystems (Apple, Google) lock-in?
They contain lock-in mechanisms — proprietary services, ecosystem integrations — but they also offer the industry’s best export tools, which is the paradox: the walls are high but the doors are real and well-maintained. Judge each service individually by its export quality rather than by the logo on the door.
Is open source the answer to lock-in?
It is the strongest structural answer: open code and open formats mean no vendor can lock you in, because there is no vendor with exclusive control. The tradeoff is that open-source apps sometimes lag in polish and support. For the technically comfortable, it is the closest thing to a permanent solution; for others, it is one good option among several.
Do data-portability laws solve lock-in?
They help at the margins — they guarantee a baseline right to your data in many regions — but they do not solve format quality, workflow lock-in, or ecosystem effects. Laws set a floor, not a ceiling. Your own habits — the five-minute check, the export cadence — matter more than any regulation.
How do I tell if a company is deliberately creating lock-in?
Look at the asymmetry: is it easy to import but hard to export? Are the formats open on the way in and proprietary on the way out? Deliberate lock-in shows up as a one-way door. Companies confident in their product make both directions easy; companies afraid of comparison make exit hard. The door tells you everything about the room.
Vendor lock-in is the reason this site exists. Every guide here — exports, formats, migrations, audits — is ultimately a lock-in reduction strategy. Learn the five mechanisms, run the five-minute check, and keep your exits affordable. The apps will keep shutting down; with open doors, you will barely notice.