Cloud Lock-In in the UK: What the CMA’s Work Means for Your Costs
Your Cloud Bill Isn't Just a Price. It's a Position You're Locked Into.
When most UK organisations moved to the cloud, the conversation was about agility and speed. Few boards asked the question that matters most a few years later: what would it cost us to leave?
The UK’s competition regulator has been asking it for them. The Competition and Markets Authority (CMA) concluded its cloud services market investigation by finding that competition was not working well, and recommended strategic market status investigations into Amazon Web Services and Microsoft. In a speech on 7 September 2026, the CMA’s Will Hayter said that while issues like multi-cloud and egress fees “can seem technical or abstruse”, they affect billions of pounds of spending by UK private and public sector organisations. He confirmed a voluntary process is under way with Amazon and Microsoft on cloud. That cloud software licensing, the outstanding issue from the market investigation, is being considered as part of a wider investigation into Microsoft’s business software ecosystem.
Government is watching too. On 1 October, a minister spoke of the need for government to maintain “competitive tension” and reduce dependency on any single supplier across its cloud and software estate (PublicTechnology, 1 October 2026).
Regulators can change the rules. They cannot re-architect your systems. If your infrastructure is built so that moving any part of it is prohibitively expensive, that is an engineering problem, and it is one you can start solving now.
How lock-in actually costs you money
Lock-in rarely appears as a line item. It shows up in four quieter ways.
Exit and transfer costs. Egress fees and charges for moving data out of a provider make it expensive to shift workloads, run analytics elsewhere, or keep a copy of your data with another provider for resilience. Even as fees fall, they still shape decisions.
Licensing that punishes choice. Software licences that cost more on one cloud than another quietly steer you toward a single provider, regardless of what the infrastructure itself would cost. This is exactly the issue the CMA has carried into its Microsoft investigation.
Proprietary services you can’t easily replace. Managed databases, queues, serverless functions and AI services are productive, but each one built tightly into your application adds to the cost of ever moving that application.
Lost negotiating power. If your provider knows you cannot realistically leave, your renewal conversation is a formality. The most expensive part of lock-in is often the discount you never get.
Lock-in is a design choice, even when nobody chose it.
Most lock-in is not the result of a deliberate decision. It accumulates. A team under a deadline picks the provider’s native service because it is quickest. Another team builds on a proprietary feature. Infrastructure is configured by hand in a console rather than defined in code. Data lands in formats and locations that suit one platform. Five years later, the organisation is architecturally married to a supplier it never formally committed to.
The answer is not to avoid managed cloud services. They are often the right choice. The answer is to use them knowingly, with the cost of leaving understood and kept within limits the business has agreed to.
Engineering for optionality
Reducing lock-in does not mean building everything to run on every cloud. That is expensive and rarely worth it. It means making deliberate choices so that, when you need to move a workload, renegotiate a contract or adopt a better service, you can.
Map your dependencies. List every workload, the provider services it relies on, and the data it holds. Mark which dependencies would be hard to replace. Most organisations have never done this, and it underpins every other step.
Price the exit. For your most important workloads, estimate what it would cost in egress, re-engineering and licensing to move them. Put that number in front of the board alongside the annual cloud bill.
Define infrastructure as code. Infrastructure built and changed through code is documented, repeatable and far easier to recreate elsewhere than infrastructure configured by hand.
Containerise where it pays. Packaging applications in containers, with orchestration that runs on more than one platform, reduces the effort of moving compute between providers.
Keep data portable. Use open formats, avoid unnecessary proprietary data stores for core records, and keep data architecture clean enough that copying or migrating it is a project, not an ordeal.
Abstract the volatile parts. Where you use provider-specific services, such as AI APIs, isolate them behind your own interfaces so that swapping provider means changing one component, not rewriting the application.
Review licensing alongside architecture. Software licensing terms can outweigh infrastructure costs. Assess them together, not in separate silos.
Lock-in and cloud waste are the same conversation.
Organisations worried about lock-in are usually also paying for capacity they do not use. Oversized instances, forgotten environments, duplicated storage and services provisioned years ago and never reviewed. The work overlaps: you cannot price an exit without knowing what you run, and you cannot right-size without the same inventory. Addressed together, they turn cloud from a fixed cost you tolerate into an estate you actively manage.
Why senior engineering matters here
This is not work for a junior engineer working from a checklist. It requires people who have designed infrastructure across several generations of architecture, who can read a cloud bill and a codebase with equal fluency, and who can tell the difference between a dependency worth keeping and one that is quietly costing you leverage.
At Human, we provide senior infrastructure and data engineers to UK organisations, remotely and on demand, without a recruitment cycle or permanent overhead. We audit what you run, map dependencies and exit costs, and re-architect the parts that matter so your estate matches what you need today and keeps your options open for tomorrow. We can work as your technical partner or white-label, under your brand.
A practical next step
Ask your team one question: for our three most important systems, what would it cost and how long would it take to move each one to a different provider? If nobody can answer with confidence, you have found the first piece of work. The answer will shape your next renewal, your resilience planning and your cloud budget.
Frequently asked questions
What is cloud vendor lock-in?
It is the situation where moving workloads or data away from a cloud provider is so costly or complex that you are effectively tied to that provider, limiting your negotiating power and your ability to adopt better or cheaper services.
What has the CMA done about cloud competition in the UK?
The CMA’s cloud services market investigation found that competition was not working well and recommended strategic market status investigations into AWS and Microsoft. As of September 2026, the CMA said a voluntary process was underway with both on cloud, and that cloud licensing was being considered in its investigation into Microsoft’s business software ecosystem.
Are egress fees still a problem?
They remain a factor in the cost of moving or copying data between providers. Even where providers have reduced them, re-engineering and licensing costs often matter as much as the fees themselves.
Should we go multi-cloud to avoid lock-in?
Not necessarily. Running everything across several clouds is expensive. For most organisations, the better goal is portability where it matters: knowing your exit costs and designing key systems so they could move if needed.
How quickly can Human start?
Because we provide experienced senior engineers rather than recruiting, we can typically start much faster than a permanent hire, beginning with an audit of your estate and its dependencies.
Want to know what leaving would cost you, and how to reduce it?
Get in touch: david@designbyhuman.com.
tags:
News & Resources
