Vendor lock-in is not something you either have or you don’t. It sits on a spectrum.
So the rational goal isn’t zero dependency, it’s reversibility at an acceptable cost.
In this article I’ll show you how to decide, workflow by workflow, how much dependency makes sense, and how to work your way out of the dependencies you already have without putting your business at risk.
I’m Miki, Managing Director of DECODE’s German office in Düsseldorf. I’m writing this for the CTOs, VPs of Engineering, and architects who have this exact question on their desk.
You won’t find scaremongering here. What you’ll find is a clear-eyed look at the economics behind vendor dependency.
Key takeaways
Vendor lock-in means that switching providers becomes so expensive or risky that you’re effectively tied in, even once the pricing, terms, or performance no longer stack up.
Vendor lock-in has three dimensions: technical dependency (your code is bound to proprietary APIs and formats), contractual dependency (terms and minimum spend make leaving costly), and human dependency (your team only knows one stack).
The most expensive lock-in is invisible: multi-cloud alone won’t protect you. The deepest tie-in sits in proprietary managed services, closed data formats, and AI APIs, not in raw compute.
The way out is gradual: a big-bang migration is the biggest risk. The strangler-fig pattern unwinds dependencies piece by piece without disrupting day-to-day operations.
The fees you’d pay to leave are the smallest part of the cost.
The real cost of vendor lock-in is structural: lost negotiating power, narrowed technical options, and a business risk that compounds every year.
Once a vendor knows that leaving would cost you months and millions, you’re no longer negotiating as equals.
Price hikes, changed licensing terms, and deprecated features all become your problem, not theirs.
100+ projects delivered. We’re ready for yours. Let’s talk →
You’ll be talking with our technology experts.
The same dependency leaves you exposed when something breaks. Rely on one vendor for a critical system, and their outage is your outage.
According to the Uptime Institute, significant outages cost 54% of organizations more than $100,000, and for one in five they’re over $1 million.
If you depend entirely on a single vendor, you have no plan B the day that vendor goes down.
Vendor lock-in has three dimensions, and the technical one is only the first. The other two are the ones most teams overlook:
Human dependency is the hardest to measure and often the most stubborn.
You can migrate to a different tech stack. But changing your team’s mindset doesn’t happen overnight.
Accepting some lock-in is often the right call. Managed services do work you’d otherwise need to hire whole teams for.
That convenience has genuine value.
The mistake isn’t the dependency itself. The mistake is walking into it blind.
Choosing a proprietary database because it solves the problem best is a good decision, as long as you know and accept the cost upfront.
That’s the whole point: choose every dependency deliberately.
Vendor lock-in grows out of many small, convenient decisions that add up over the years.
And here’s a common misconception: that running multi-cloud automatically makes you independent. It doesn’t.
Organizations use 2.4 public cloud providers on average, but the real lock-in isn’t in raw compute.
It’s in the proprietary managed services sitting on top of it.
The deepest dependency comes from proprietary managed services, not from virtual machines.
Raw compute is much the same everywhere and can be moved in days.
A proprietary managed database, a vendor-specific serverless architecture, or a closed messaging system is a different story.
Each anchors you deep inside one vendor’s ecosystem. Your code is written against their APIs, and every line raises the cost of leaving.
Proprietary file formats are a great example. When only one tool can read your data, that data effectively belongs to the tool.
The newest and most underestimated lock-in is in AI and data.
Proprietary AI and ML APIs are especially tricky, because you shape your prompts, your fine-tuning, and your entire integration logic around a model that only one vendor hosts.
If that vendor changes the model, the pricing, or the terms, you suffer the consequences.
Switching means more than new code. It often means you have to re-test behavior from scratch.
With data, market concentration adds to the problem. The three largest providers control roughly 68% of cloud infrastructure worldwide.
The more data you keep there, the more expensive migrating away from them becomes.
Look at every workflow on its own and ask yourself three questions:
Run each workflow through those three questions and one of three answers comes back.
If it’s cheap to move and the proprietary service is pulling its weight, stay where you are and don’t feel bad about it.
If losing the ability to switch would hurt your business, spend the effort now to keep it portable.
The workflows that are both costly to leave and critical to run are the ones that should worry you. Start there.
Going through this takes an afternoon per workflow. Skipping it can cost you years tied to a vendor you’d rather leave.
The way out of lock-in is made up of many small steps. A big-bang approach is the riskiest thing you can do, because it stakes everything on a single cutover date.
The proven route is the strangler-fig pattern: you build new, portable components around the old system and reroute traffic piece by piece. The old system shrinks until it disappears.
That keeps your business running throughout the entire migration. Each step is small enough to roll back if something goes wrong.
The first step is an honest inventory. Capture every relevant dependency and rank it with the framework above, by exit cost and business criticality.
That gives you a priority list. At the top sit the dependencies that are expensive and critical at the same time, because that’s where your risk is greatest.
Resist the temptation to start with the easy ones. Quick wins feel good, but they rarely solve the real problem.
Migrate one dependency at a time, with clear points of no return kept short. Each step should deliver a measurable gain in reversibility and stand on its own as a finished project.
This is exactly how we worked with Norfolk Southern: legacy modernization with no operational downtime, delivering a capacity-planning platform that handles more than 400,000 reservations a day and has saved over $100 million in operating costs.
Numbers like that don’t come from a bold leap. They come from disciplined, incremental work that never puts the running business at risk.
A realistic timeline for critical systems is measured in quarters, not weeks. Accept that, and you migrate safely. Refuse it, and you produce the very outage you set out to avoid.
Reversibility is a design choice. You either build it in early, or you go without it the day you need to move.
The idea is simple. Put a clear boundary between your own business logic and any vendor’s proprietary services.
Keep what’s hard to replace on one side and what you might replace on the other.
With that boundary in place, leaving a vendor is a planned migration. Without it, it’s a crisis.
An abstraction layer sits between your application and the infrastructure beneath it.
Your code talks to a stable interface you control, not to a vendor’s APIs. Change what’s underneath, and the application stays the same.
Kubernetes is the clearest example.
It’s an open CNCF standard, so a containerized application runs much the same on any cloud. Containers and open standards bring your switching costs down.
Don’t overdo it, though. Every layer adds complexity and maintenance. Add one where reversibility matters, and skip it everywhere else.
Portable data starts with the format.
Store it in open, documented formats and it stays yours, no matter which system happens to be reading it.
Before you commit to a new service, check how you can export your data. Can you export all of it, cleanly structured, without special terms?
If that isn’t clear, you have your answer. A service with no clean way out is betting on your dependence.
Use multi-cloud and hybrid-cloud when you have a specific reason, not by default.
They carry a real cost.
Flexera reports that 84% of organizations name managing cloud spend as their biggest challenge, and the same report puts wasted spend at 27%.
Every extra vendor is another thing to run.
So use them where the payoff is clear, like resilience or negotiating power, and only on the workflows that warrant it.
Interoperability is worth having, but it always costs something. Choose it deliberately.
Regulation is now strengthening your position. The EU Data Act shifts the economics of switching noticeably in your favor.
The EU Data Act has been in effect since 12 September 2025.
Until 12 January 2027, providers can only charge the actual direct costs of switching. From 12 January 2027, switching charges, including the notorious egress fees, are banned outright.
The major hyperscalers have already responded. AWS, Azure, and Google dropped egress fees for full exits back in 2024, ahead of the regulation.
The Digital Operational Resilience Act (DORA) adds to this for the financial sector.
It’s in effect since 17 January 2025 and targets concentration risk among ICT providers. Since late 2025, the major cloud providers have been under direct EU oversight as critical third parties.
For you, that means digital sovereignty has become a regulator-backed, commercially sensible standard.
No, and that shouldn’t be the goal.
Every technology decision you make ties you to something, whether it’s a platform, a language, or a provider.
Chasing zero dependency just trades one cost for another, usually a slower, more expensive build.
The goal that actually holds up is reversibility at an acceptable cost: knowing what it would take to leave and keeping that number sensible.
No. Running on more than one cloud spreads your compute around, but it does nothing about the proprietary managed services sitting on top of it.
That’s where the real lock-in happens: in the databases, queues, and platform features you’ve wired your code into. If those stay tied to one provider, you’re still locked in, you’re just paying two bills.
Real portability comes from how you design the system, not from how many vendors you sign up with.
In the proprietary managed services you lean on most: managed databases, vendor-specific serverless offerings, and closed AI and ML APIs. These shape your data model and your application logic, so unpicking them means real rework, not a config change.
Raw compute is the opposite. It moves in days, because one virtual machine is much like another.
When you map your dependencies, weight them by how hard they’d be to replace, and these come out right at the top.
If you’ve read this far, there’s probably a specific reason: a dependency that keeps growing, a cloud contract up for renewal, or a legacy system you can’t easily move off.
That’s the moment to weigh reversibility, while you still have room to act and before exit costs climb.
We modernize complex systems for a living, and we do it without interrupting the business that runs on them.
Our senior engineers design portable architectures on open standards, keep your data yours, and make each dependency a deliberate choice with the exit cost on the table from the start.
We’re an EU-based company with offices in Zagreb and Düsseldorf, so digital sovereignty isn’t an abstract idea to us.
It’s how European teams we work with think about risk, cost, and control every day.
When you’re ready to map your most critical dependencies and see the realistic options, we’re the best team to have in the room.
Miki leads our German branch, DECODE Services GmbH. He was born in Croatia, grew up in Germany, and brings a unique blend of both cultures to his work. With 30+ years of experience in both hardware and software, Miki’s built everything from early Android apps to enterprise-grade IoT systems. He’s one of the original contributors to Android’s developer community and has spoken at - and helped organize - droidcon conferences across Europe. These days, he’s deep into AI and IoT, working closely with industry leaders and helping them build innovative solutions. When he’s not working, you’ll probably find him hiking, mountain biking, or cooking a delicious meal with his family.
Achieve digital sovereignty: concrete steps for cloud strategy, data management, software architecture, and AI. The practical guide for IT decision-makers.
Digital sovereignty and data sovereignty are often used interchangeably. Here's the difference, and why data control alone isn't enough.
How dependent is your company on cloud providers and software vendors? This self-test for CTOs shows your risk level for digital sovereignty.