Vendor lock-in in the public cloud: where it comes from, what leaving costs and how to limit it

WebDisk Blog · category: Cloud · reading time: ~8 minutes

In short:- Vendor lock-in (dependency on a provider) is a situation in which changing providers costs so much – in money, time and risk – that it stops being a real option. It arises from closed services, proprietary formats and fees for moving data out.- Lock-in is not always a mistake: it can be a deliberate trade-off in exchange for convenience. The dangerous kind is the unrecognized one – discovered only at the first attempt to leave.- The vaccine that works is open standards: S3 API, Kubernetes, open formats and open source software. We built WebDisk Cloud on this philosophy – with Apache CloudStack and Ceph at its foundation.

A scenario familiar to more than one company: the infrastructure works, the team is experienced, the invoices are predictable. Until one day the provider announces a change to its licensing model, raises prices or discontinues the product that half of your processes run on. You start calculating the cost of moving – and it turns out that the migration means long months of work, and until it is finished you pay according to the new price list. That is what vendor lock-in, or dependency on a provider, looks like from the inside. Recent years have supplied high-profile examples – from licensing changes at well-known virtualization platforms in the hands of new owners to the pricing policies of database giants – but the mechanism itself is older than the cloud and applies to every layer of IT.

In this article we take it apart: where it comes from, what the bill for leaving consists of, when lock-in can be a deliberate and rational decision – and how to limit the risk with open standards. We are writing for everyone who makes infrastructure decisions: from the sysadmin to the board that watches the IT budget.

Why does dependency on a provider begin with convenience?

Let us say one thing honestly: every commercial product is designed to be as indispensable as possible. That is not an accusation – this is how the market works, and we too want our services to matter to our customers. The problem starts where features that make an organization's work easier are built specifically to make the software hard to drop or swap out for something else.

Plenty of companies know the effects firsthand: the rising cost of extending support, the need to adapt to the vendor's suddenly shifting policy or vision, and in the end – a parting that consumes the budget and months of work. The line between "this product is useful" and "we cannot function without it" can be thin, and it is easy to cross it without noticing. That is why it is worth understanding the mechanisms that keep us on the wrong side of that line.

Where does vendor lock-in come from?

Closed managed services. The largest public cloud providers offer sprawling platforms on which you can build anything without a single server of your own. "Why would you need a machine – just send us your code" is the essence of the PaaS model (Platform as a Service – a platform in which the provider manages the entire runtime environment). And it is genuinely convenient. But code written for closed services – message queues, serverless functions, proprietary databases – talks to interfaces that exist only at that one provider. Leaving then means not moving the application, but rewriting it.

Proprietary formats and interfaces. The second source of dependency is data stored in formats that only one vendor's software can read: machine images that only its hypervisor will boot, backups that only its system will restore, configuration that cannot be exported in any usable form. As long as everything works, nobody thinks about it – the format becomes a problem exactly on the day you want to leave.

The economics of transfer. Bringing data into the cloud is usually free; taking it out is charged by the gigabyte. These are the so-called egress fees (charges for outbound traffic). Combined with the natural growth of data, this works like gravity: the more you accumulate, the more expensive and the slower it becomes to take it away – and more services settle around the data, because processing it where it already sits is cheaper than processing it elsewhere. The law is moving in a good direction here: the EU Data Act, applicable since 12 September 2025, caps switching fees at the provider's actual costs, and from 12 January 2027 bans them entirely. It is worth dispelling the most common misunderstanding right away: the rule covers fees for the switch itself to another provider, not ordinary outbound traffic during normal use of the service – that can still carry a charge. Regardless of regulation, since 2024 the largest players have pledged free transfer for customers leaving their cloud entirely – usually on request and under specific conditions. The direction is good, but it does not change the rule: the cost of transfer is the easiest item on the exit bill to calculate, yet rarely the largest.

And a fourth, quieter source: people. Your team's skills, certifications, existing automation and operational habits also tie you to the platform. None of it shows up on the invoice, but during a migration all of it has to be rebuilt from scratch.

What does leaving really cost?

The bill for parting with a provider consists of several items – and it is worth drawing it up before you enter, not on the way out:

• rewriting integrations – every piece of code using closed interfaces requires changes and retesting,
• maintaining two environments in parallel – for the duration of the migration you pay for the old and the new one at the same time,
• data transfer and verification – not just the traffic fees, but the time spent copying and verifying that nothing was lost along the way,
• training the team and rebuilding the automations,
• the risk of downtime – the hardest to price, and the most painful.

The longer the relationship with the provider lasts and the deeper its services have grown into your processes, the larger each of these items becomes. That is exactly why lock-in works: at every single moment it is cheaper to stay – even when the terms are getting worse.

Is vendor lock-in always a mistake?

Not every lock-in is a mistake, and we are not urging anyone to build everything themselves on their own servers. A closed managed service buys you time: the team works on the product, not on the infrastructure. If a particular provider's unique service gives a real advantage – deliberately tying yourself to it can be a rational business decision.

The key word is deliberately. Before you make a critical process dependent on a single vendor, answer three questions:

1. What exactly will stop working if we have to leave – and what does it cost to build it somewhere else?
2. In what format will we get our data back, and have we tested the export in practice, not just in a salesperson's promises?
3. Who will make the decision to leave and on what basis – do we even have a written exit plan?

If there are no answers to these questions, the trade-off stops being a trade-off – it becomes a belief that the provider will never change its price list, its license or its owner. Market experience suggests that this belief is overconfident.

How to limit the risk of vendor lock-in?

Better protection than any provider's declarations is an architecture that makes leaving technically simple:

• S3 API for object storage. The S3 API (the standard interface for writing and reading objects, originating from the Amazon S3 service) has become the de facto market standard – data written via S3 can be moved with any of dozens of tools, to any compatible storage. That is how Object Storage in WebDisk works, built on open-source Ceph storage.
• Kubernetes for running applications. Kubernetes (an open system for running and scaling applications in containers) means that an application packaged into containers and described by its manifests moves between clouds without rewriting – the cluster operator changes, not the architecture. We help with this as part of our Kubernetes technical support services.
• Open data and image formats. Backups and machine images in formats that more than one vendor can read are the difference between a migration and rebuilding the world from scratch.
• Infrastructure as code and a regular export test. Configuration kept in a repository instead of clicked together in a control panel can be reproduced at another operator. And a data export that has never been rehearsed should be treated like a backup that has never been restored – that is, as an unverified hypothesis.

One caveat for balance: open standards reduce the cost of leaving, but they do not bring it to zero. A migration is always work – competencies, integrations and the data transfer itself remain on your side. The difference is that with an open architecture it is you who decides when to carry it out, and not the provider – with its price list.

The WebDisk philosophy: a cloud you can leave

At WebDisk we have made it a point of honor that the problem described above will affect neither us nor our customers. We started with ourselves: the core of our platform is open source software – cloud orchestration is handled by Apache CloudStack, and data is stored by the distributed Ceph storage. These are projects that anyone can download, examine and run in their own server room; nobody can retroactively change the license of the released versions of that foundation for us – or, indirectly, for our customers – and open code can always be developed further independently. We also use commercial solutions – but we keep them away from the foundation. Orchestration and data storage are open, so replacing a tool above them does not mean replacing the platform.

We give our customers the same choice:

• Open standards where we keep your data – object storage compatible with the S3 API, virtual machines on an open virtualization platform, and Kubernetes clusters that we run and maintain for customers. We build on open standards precisely so that data can be moved in both directions.
• Transfer without a trap – in WebDisk VM and the public cloud we do not charge for outbound or inbound traffic; in Object Storage transfer is part of the plan, not a separate penalty for taking your data away.
• A way back without surprises. You can download the data in Object Storage yourself, via the S3 API, with any tool – in the same way as you uploaded it. For the remaining resources, arrange an export with us before the subscription ends. We will be sorry to see you go, but we will not stand in your way.

A good test of any provider's credibility: ask not how easy it is to move in, but what the way back looks like. A provider that eagerly helps with a migration to itself – for example from VMware – and says nothing about leaving has just answered your question. We answer directly: a customer who stays by choice is worth more to us than a customer held hostage. This is, incidentally, a natural consequence of the approach we described more broadly in the article on European cloud computing – data sovereignty starts with being able to take your data with you at any time.

Frequently asked questions

What is vendor lock-in in the cloud? Vendor lock-in (dependency on a provider) is a situation in which changing providers costs so much – in money, time and risk – that it stops being a real option. It arises from four sources: closed managed services, proprietary data formats, fees for outbound traffic, and a team's competencies tied to a single platform. The mechanism itself is older than the cloud and applies to every layer of IT.

Does open source guarantee the absence of lock-in? No – and we do not claim that it does. Operational lock-in (the team's competencies, integrations, the migration effort itself) exists with every technology, open ones included. Open source licenses are also sometimes changed – recent years have brought several high-profile changes of this kind – but they cover future versions. Nobody will retroactively change your terms of use for code you already have; the development of an open project can be continued independently, and a platform based on it can be run at another operator or on your own premises.

Is using a closed PaaS always a mistake? No. It is a trade of flexibility for time – often worthwhile, especially at an early stage of a product. The risk can be limited by architecture: keep the business logic in portable code, and fence off closed services with a thin layer of your own interfaces, which in the event of a migration is replaced in one place instead of across the whole application.

How to assess the risk of dependency before signing a contract? Four questions for the provider: in what format and by what mechanism will I export all of my data; how much does outbound traffic cost; which of the interfaces I use are market standards and which are proprietary; can I carry out a test migration of a data sample before deciding. Evasive answers are an answer too.

Will egress fees disappear on their own, thanks to regulation? Partly – and only in one specific place. The EU Data Act, applicable since 12 September 2025, caps the fees for the switch itself at the provider's actual costs, and from 12 January 2027 abolishes them entirely. The distinction matters: the rule covers fees for changing providers, not ordinary outbound traffic when you are simply using the service – that can still carry a charge. Nor will regulation rewrite for you an application entangled with closed services: technical portability still depends on the architectural decisions you make today.

Summary

Vendor lock-in does not come from ill will, but from the sum of small conveniences, each of which makes sense on its own. The defense does not require heroism either: open standards wherever possible, a deliberately calculated trade-off where a closed service really pays off, and a rehearsed exit plan – before it is needed. And if you are weighing the choice between a global giant and a local provider, we take that dilemma apart separately in the article hyperscaler or Polish cloud. If you would like to talk about an architecture you can leave if need be – or about moving your current infrastructure to a cloud built on open standards – write to us.