AI Applications
Vendor Lock-In Examples: 12 Real Cases, From AWS Egress Fees to CUDA
A concrete list of vendor lock-in examples across cloud, enterprise software, hardware and AI, including the price hikes that turned theoretical lock-in into real invoices. Explains the five mechanisms that create lock-in, the AI-specific versions now showing up in production systems, and a practical exit-cost test you can run on any vendor before you sign.
CSEWhy ·
A concrete list of vendor lock-in examples across cloud, enterprise software, hardware and AI, including the price hikes that turned theoretical lock-in into real invoices. Explains the five mechanisms that create lock-in, the AI-specific versions now showing up in production systems, and a practical exit-cost test you can run on any vendor before you sign.
Twelve vendor lock-in examples, plainly listed
Vendor lock-in is when leaving a supplier costs more than staying, even after the supplier raises prices or gets worse. The textbook examples are AWS charging you to move your data out, Oracle databases full of PL/SQL that runs nowhere else, SAP implementations that took three years to configure, and Nvidia's CUDA, which is why a shop full of CUDA code does not casually switch to AMD. Below are twelve, with the specific thing that creates the trap in each case.
Notice how few of them involve a contract. Most lock-in is technical or organisational, built quietly over years by your own team.
| Example | What creates the lock-in | What leaving actually costs |
|---|---|---|
| AWS, Azure, GCP | Data egress fees, proprietary managed services like DynamoDB and Lambda | Re-architecting applications plus a large one-time bill to move petabytes out |
| Oracle Database | PL/SQL, proprietary extensions, licensing audits | Rewriting stored procedures and revalidating every report |
| SAP ERP | Years of custom configuration and process design baked into the system | Multi-year migration projects that routinely overrun |
| Salesforce | Apex code, workflow logic and years of CRM history living inside the platform | Data export is easy, rebuilding the logic is not |
| Nvidia CUDA | Kernels, libraries and an entire ML toolchain written against one vendor's API | Porting to ROCm or another stack, then re-benchmarking everything |
| Adobe Creative Cloud | PSD, AI and INDD files that only open properly in Adobe tools | Your entire back catalogue becomes partially unreadable |
| Microsoft 365 | Teams, SharePoint, Entra ID identity and Excel macros used by every department | Retraining thousands of people and rebuilding identity management |
| Tally (Indian SMEs) | Years of books, a proprietary data format, and an accountant who only knows Tally | Your CA's comfort is a switching cost nobody puts on a spreadsheet |
| Printer ink and cartridges | Chipped cartridges and firmware that rejects third-party refills | Cheap printer, expensive forever |
| WhatsApp Business API via a BSP | Phone number, templates and chat history held by the solution provider | Migration is possible but messy, and often quietly discouraged |
| OpenAI API in production | Prompts tuned to one model, function-calling formats, fine-tuned weights you cannot export | Re-tuning and re-testing every prompt against a new model |
| Vector databases and embeddings | Embeddings generated by one model, stored at one dimension count | Re-embedding the whole corpus, which costs compute and time |
The five mechanisms behind all of them
Different industries, same handful of tricks. Once you can name the mechanism, you can spot lock-in in a sales demo instead of two years later.
Contractual lock-in is the least dangerous of the five, because at least it has an end date printed on it.
- Data gravity: your data is large, sensitive or expensive to move, so everything else drifts towards where it already sits.
- Format lock-in: files, schemas or model weights that only one vendor's software can read properly.
- Skills lock-in: your team knows this tool. Switching means retraining people and losing months of speed.
- Integration depth: forty other systems now call this vendor's API, and each one is a separate migration.
- Contract and licensing: multi-year commitments, committed spend discounts, and audit clauses that punish you for shrinking.
When lock-in stops being theoretical: four price hikes that proved the point
The argument for tolerating lock-in is always that the vendor is reasonable. Then ownership changes, or the board wants margin.
In 2018, Google Maps restructured its Platform pricing and some businesses saw API bills jump by an order of magnitude, with no practical alternative embedded in their apps. Unity announced a per-install Runtime Fee in September 2023, aimed at games already shipped and built on years of Unity-specific code. Twitter ended free API access in early 2023 and priced the replacement tiers high enough to shut down a generation of third-party apps overnight. And after Broadcom acquired VMware in late 2023, perpetual licences were discontinued in favour of subscription bundles, and a lot of enterprises discovered exactly how long a hypervisor migration takes.
None of those customers were stupid. They made sensible decisions with the information they had, and the exit cost simply grew faster than anyone tracked it.
The AI versions are newer and sneakier
AI lock-in does not look like a contract. It looks like a working system.
Say you built a retrieval setup last year using one provider's embedding model at 1536 dimensions. Every document in your knowledge base is now encoded in that model's particular way of representing meaning. Switching embedding models is not a config change, it is re-embedding the entire corpus, rebuilding the index, and re-testing retrieval quality from scratch. Fine-tuning is worse: you pay to train a model on your data and the weights stay with the vendor. Then there are prompts, which quietly become model-specific artefacts because your team spent six weeks tuning them around one model's quirks.
The defence is boring and it works. Keep your source data and your prompt logic in your own systems, put a thin abstraction between your application and whichever model you call, and run an evaluation set you own so you can swap models and measure what changed. Teams building this properly usually need someone who has done it before, which is the point of AI Automations work with startups and MSMEs, where the automation gets designed around your process and your data rather than around one vendor's dashboard. If your team wants to learn the pattern rather than outsource it, the shorter AI Masterclass format covers the same implementation thinking.
Run the exit-cost test before you sign anything
Do not ask whether a vendor locks you in. Every vendor does, to some degree. Ask how much leaving would cost on a specific Tuesday eighteen months from now.
Write down four numbers: how many days to export all your data in a usable format, how many other systems call this vendor's API, how many people would need retraining, and what the contract says about exit. If you cannot answer any of them in an hour, that is your answer. Then decide deliberately. Sometimes the locked-in option is genuinely the right call, because the alternative is six months of integration work you do not have. Lock-in is not a moral failing, it is a price. The mistake is paying it without noticing.
FAQs
1. Is vendor lock-in illegal?
No. Lock-in is a normal outcome of building on someone else's platform, and most of it is created by your own technical choices rather than by contract terms. Competition regulators only get involved when a dominant vendor uses lock-in to block rivals, which is why cloud egress fees have drawn scrutiny from the EU and the UK's CMA.
2. What is the difference between vendor lock-in and switching costs?
Switching costs are the total effort of moving to a different supplier. Vendor lock-in is what happens when those costs get so high that switching stops being a realistic option, even when the vendor raises prices.
3. Does using open source eliminate vendor lock-in?
It reduces it but does not remove it. You can still be locked into a managed open source service, a specific distribution, or a single company's release cadence, and skills lock-in applies to open tools exactly as it does to proprietary ones.
4. How do companies reduce cloud vendor lock-in?
The common tactics are keeping data in portable formats, preferring containers and standard databases over proprietary managed services, and running at least one workload somewhere else so the migration path is tested rather than theoretical. Full multi-cloud is expensive, so most teams aim for portability rather than parity.
5. Which AI providers have the least lock-in right now?
Anything you can run yourself, such as open-weight models from Meta, Mistral or Qwen, gives you the most portability because the weights sit on infrastructure you control. Among hosted APIs, providers that follow the widely used OpenAI-compatible request format are easier to swap, since the change is mostly an endpoint and a key.
6. Can small businesses in India realistically avoid lock-in?
Partly. Small teams should not over-engineer for portability, but they should insist on clean data exports, avoid storing critical business logic inside a single SaaS tool, and keep customer data in a system they own even when the workflow runs elsewhere.