From 12 January 2027, cloud providers serving EU customers can no longer charge you to leave. The EU Data Act bans switching charges outright, after three years in which providers could only pass them through at cost (Latham & Watkins). In the UK, under scrutiny from the competition regulator, Microsoft has committed to extend its free-egress window for UK customers leaving Azure from 60 to 180 days, and to count leaving a single service as a switch (The Register).
That sounds like the end of vendor lock-in. It isn't, because the fee was always the cheapest part of it.
What the regulator actually found
The UK Competition and Markets Authority has investigated the cloud market in depth. Its final decision, published in July 2025, found that fewer than 1% of UK cloud customers switch provider in a given year (CMA).
Egress fees were one reason. But the CMA also named technical barriers: services with different features and interfaces that are hard to swap or combine, latency between clouds, and a lack of staff skills that transfer from one platform to another. Many customers, it found, simply believe the cost of switching outweighs the benefit. It also found that Microsoft's licensing makes some of its software more expensive to run on AWS or Google than on Azure, and in 2026 it announced a separate investigation into exactly that.
The Data Act does more than ban the fee. Customers can trigger a switch on no more than two months' notice, and the move should be completed within 30 days, extendable where that's technically unfeasible. Infrastructure providers must take reasonable steps to help customers reach equivalent functionality on the new service, and other providers must offer free, open interfaces (Latham & Watkins, same). Those are real improvements. But "functionally equivalent infrastructure" is not the same as an application that runs unchanged on another platform.
So the regulator's own list has one item that a law can delete with a date, and several that no law touches. Commentary on the Data Act makes the same point: the fee ban doesn't address proprietary APIs, vendor-specific data formats or identity systems tied to one provider, and your existing contract terms won't update themselves (cloudmagazin).
Lock-in rarely looks like lock-in
Nobody signs a contract that says "you can never leave." The decision that creates lock-in usually looks like a sensible shortcut at the time.
A managed queue that saves a sprint. A database feature that only exists on one platform. A serverless setup wired into one provider's identity system. A licensing bundle that's cheaper if everything stays in one place. A team that gets very good at one ecosystem because that's where all the work is. Each one is reasonable. Together they decide, years later, what leaving will cost.
VMware customers are living through what happens when that bill changes after the fact. In a survey published last week, nine in ten VMware customers said higher licensing costs since Broadcom's acquisition are pushing them to consider alternatives (The Register). That survey was sponsored by Rimini Street, a third-party support provider with an interest in customers leaving, so read it as a direction rather than a measurement. But look at what respondents said stands in their way: operational complexity (40%), managing multiple vendors (38%), a larger attack surface (37%) and team skills (37%). None of those is a fee.
Concern is close to universal. In a separate survey of 540 IT professionals, sponsored by Parallels, 94% said they were concerned about vendor lock-in (Parallels). Nearly half (49%) said they were considering or planning a move back to on-premises or hybrid setups.
Concern doesn't change much when the decisions that cause lock-in are made one convenient shortcut at a time.
A composite scenario
Picture a mid-market company that moved to the cloud five years ago. This is a composite of a common pattern, not a specific client.
The migration went well because the team leaned into the platform: a proprietary database service, the provider's event bus, functions triggered by its storage, permissions defined in its identity system. Delivery was fast. Then the renewal comes in higher, or a licensing change lands, or the business wants a second provider for resilience.
The egress bill to move the data is, by then, almost a rounding error. The real cost is rewriting the parts that only work on that platform, re-creating the permissions model, retraining a team that knows one ecosystem, and running both environments in parallel while it happens. None of that was on the original business case, because at the time leaving wasn't the plan.
What to do about it
The goal isn't to avoid managed services. Most are worth using. The goal is to know what you're buying into.
Price the exit when you make the decision. For each major service, write down what it would take to move off it: what's proprietary, what would need rewriting, roughly how long. If nobody can answer, that's the risk.
Keep a seam between your code and the platform. Put provider-specific services behind your own interfaces where it's cheap to do so, so a future move changes an adapter rather than the whole application.
Check your contracts before the law does it for you. Auto-renewals, termination terms and egress thresholds don't change automatically when the Data Act applies. Read them now.
Watch the licensing as closely as the infrastructure. Some of the largest switching costs come from software licenses that are priced differently depending on where they run.
Don't let skills become the lock-in. If only one person, or one partner, can run your platform, you're locked in to them too. Document it and spread the knowledge.
Write an exit plan you never intend to use. It's the cheapest insurance in the budget.
We build on-premise and in the cloud with no vendor lock-in, and the architecture belongs to the client. If you're about to commit to a platform, or wondering what it would take to leave one, let's talk.