Moving to the cloud can happen one application at a time. Leaving, however, may require a business to untangle years of data growth, service integrations, security policies and operational habits. What looks like a straightforward cloud migration at AWS or Azure can quickly become a large transformation programme with significant cost and risk.
That problem is receiving renewed attention following scrutiny announced by the UK Competition and Markets Authority on October 16, 2026. The development builds on the regulator’s cloud services market investigation, which examined whether technical barriers, data-transfer charges, commercial arrangements and software licensing practices restrict competition and customer choice.
The issue is not that Amazon Web Services or Microsoft Azure are inherently bad choices. Both offer mature infrastructure, global coverage and extensive managed services. The concern is that the deeper an organisation integrates with one provider’s technology, the harder switching cloud providers can become. Understanding that dependency is essential before deciding whether to stay, migrate or adopt a multi-cloud strategy.
What the CMA’s cloud market scrutiny means
The CMA’s cloud work must be described carefully. Its market investigation identified competition concerns rather than declaring that every AWS or Azure contract is unlawful. The independent inquiry group’s findings highlighted a concentrated UK cloud infrastructure market and barriers that can make switching or using multiple providers more difficult. These included technical obstacles, cloud egress fees, committed-spend arrangements and aspects of Microsoft software licensing.
The inquiry recommended using the UK’s digital markets framework to consider targeted scrutiny of AWS and Microsoft. The October 16 announcement represents a regulatory step, not a final legal determination that either company has breached competition law. An investigation, recommendation or proposed designation is distinct from a final Strategic Market Status decision, enforceable conduct requirement or infringement ruling.
Businesses should consult the CMA’s official cloud services market investigation record for the exact scope, published findings and current procedural status. This distinction matters because possible remedies depend on later decisions and consultation. They could include measures addressing cloud portability, interoperability, pricing transparency or restrictive licensing, but regulatory scrutiny alone does not automatically change an existing customer contract.
Why cloud provider lock-in is difficult to see
Cloud provider lock-in rarely comes from one contractual clause. It accumulates as applications adopt convenient platform features. A team may begin with virtual machines and object storage, then add a proprietary database, identity service, event bus, monitoring platform, serverless functions and provider-specific security controls.
Each service can improve development speed. Together, they create cloud vendor dependency across several layers:
- Applications may call provider-specific APIs or software development kits.
- Managed databases can use proprietary extensions, replication methods or backup formats.
- Identity and access policies may be embedded throughout deployment pipelines.
- Data can be distributed across storage, analytics, logging and disaster-recovery services.
- Networking may depend on private endpoints, load balancers, DNS services and firewall rules unique to the platform.
- Operational teams may be trained and certified primarily in one cloud ecosystem.
Consequently, moving data is only one part of an AWS to Azure migration or Azure to AWS migration. The organisation may need to redesign applications, translate policies, rebuild observability, retest security controls and retrain employees before production traffic can move safely.
Data transfer and egress charges
Cloud data transfer costs attract attention because providers commonly charge for data sent to the public internet, another region or another cloud. At the time of publication, standard list pricing varies by geography and transfer volume. Illustrative US or European internet-transfer tiers can place roughly 10 TB of outbound data in the region of several hundred dollars, approaching about $900 before discounts, taxes or architecture-specific charges.
The invoice can include more than the headline cloud egress fee. Database export operations, object retrieval charges, API requests, inter-region replication, NAT processing, dedicated connectivity and temporary duplicate environments may all add cost. Moving petabytes can also take weeks over existing network capacity.
Pricing policies contain important exceptions. AWS documentation describes free data transfer out for eligible customers permanently moving all data off AWS, subject to conditions and engagement with AWS Support. Microsoft likewise has an Azure data-transfer-out policy for qualifying customers leaving the platform, with notice, cancellation and eligibility requirements. Azure’s current bandwidth pricing and policy details are available on its official pricing page.
Businesses should therefore model their actual services and confirm eligibility rather than multiplying stored terabytes by a public rate. A waiver for qualifying internet egress may not remove migration engineering, retrieval, connectivity or parallel-running costs.
Application redesign and staff expertise
Amazon Web Services lock-in can arise through services such as Lambda, DynamoDB, IAM policies or provider-specific analytics pipelines. Microsoft Azure vendor lock-in may develop through Azure Functions, Cosmos DB, Entra ID integrations, Azure-native management tools or dependencies involving Microsoft software.
Equivalent services are not necessarily interchangeable. Event formats, consistency models, identity concepts and automation interfaces differ. Teams also need knowledge of the destination provider. Hiring specialists, training employees and operating two platforms during transition can exceed the direct data-transfer bill.
Downtime and business risk
A migration must preserve data consistency while users continue creating transactions. Cutover plans may require replication, reconciliation, performance testing and rollback procedures. Systems with strict recovery objectives or regulatory obligations cannot simply be switched off while terabytes are copied. The cost of downtime, failed transactions or an incomplete audit trail may dwarf cloud infrastructure costs for businesses.
AWS vs Microsoft Azure: a practical comparison
The AWS vs Microsoft Azure decision should reflect workload requirements rather than a universal ranking. AWS offers a broad service catalogue, extensive infrastructure coverage and a mature cloud-native ecosystem. Azure can be especially attractive to organisations already using Microsoft identity, Windows Server, SQL Server, Microsoft 365 and enterprise licensing arrangements.
Those strengths can also deepen dependency. AWS customers may build extensively around its proprietary managed services. Azure customers may combine infrastructure, identity and Microsoft licensing so closely that the commercial and technical relationships become difficult to separate.
A practical evaluation should compare:
- Total cost at realistic usage levels, including support, networking and discounts.
- Availability in the regions required for latency, resilience and data residency.
- Compatibility with existing identity, security and software estates.
- Portability of data, deployment definitions, backups and application components.
- Quality of managed services relative to the engineering effort needed to remain portable.
- Contract terms covering committed spend, price changes and termination.
A business receiving strong value from either provider may rationally stay. Avoiding every proprietary service can create unnecessary engineering work and prevent teams from using valuable capabilities. The objective is to make dependency visible and intentional.
Switching providers is not the same as multi-cloud
Switching means moving a workload from one provider to another and retiring the original environment. A multi-cloud strategy means deliberately using services from two or more providers at the same time. For example, a business might run customer applications on AWS while using Azure for Microsoft-integrated workloads, or maintain a recovery environment on a second platform.
Multi-cloud can reduce concentration risk, improve negotiating leverage and provide access to specialised services. It can also support resilience when applications are genuinely designed and tested to fail over between clouds.
However, multi-cloud vs single-cloud is not a simple choice between resilience and lock-in. Operating multiple platforms can duplicate security tooling, network connections, support contracts, monitoring systems and specialist teams. Data synchronisation between clouds may create new transfer costs and consistency risks. An untested secondary deployment is not reliable disaster recovery.
For many organisations, selective distribution is more practical than making every workload portable across every cloud. Workloads can be assigned according to business value, risk and technical fit while common governance standards apply across the estate.
How to avoid cloud vendor lock-in
Complete independence is rarely economical, but businesses can preserve realistic options through disciplined architecture and governance.
- Document dependencies. Maintain an inventory showing which applications rely on each database, identity platform, API, network component and managed service.
- Use open standards where appropriate. Standard protocols, common data formats and widely supported database engines can improve cloud interoperability.
- Adopt portable architectures selectively. Containers can make application packaging more consistent, although Kubernetes or containers do not automatically make databases, networking and identity portable.
- Use infrastructure as code. Tools and modular templates create repeatable environments and expose provider-specific resources that require redesign.
- Test backups and exports. Confirm that data can be exported in usable formats, restored outside the original account and reconciled successfully.
- Estimate exit costs. Include egress, retrieval, engineering, dual running, testing, consultants, training and downtime.
- Review commitments before renewal. Large discounts may be valuable, but long commitments can reduce flexibility if demand or strategy changes.
- Maintain a cloud exit strategy. Define triggers, owners, recovery objectives, contract steps and a realistic migration sequence.
A framework for deciding whether to stay, migrate or distribute
1. Establish the business objective
Identify whether the concern is cost, resilience, regulation, performance, negotiating leverage or access to better services. A migration without a measurable objective can exchange one form of dependency for another.
2. Map workloads and dependencies
Classify data volumes, sensitivity, uptime requirements and application connections. Identify proprietary components and calculate how much redevelopment each would require.
3. Calculate the full economic case
Compare three-to-five-year costs for staying, migrating and distributing workloads. Include committed-spend discounts, cloud egress fees, personnel, licences, parallel environments and risk-adjusted downtime.
4. Test portability with a representative workload
Run a limited proof of concept using real deployment automation, security controls and anonymised or approved data. Measure performance, export duration, operational effort and unexpected incompatibilities.
5. Choose a workload-level strategy
Keep workloads that benefit substantially from the current provider. Migrate those with a clear financial, technical or compliance case. Distribute workloads when resilience or specialised capabilities justify multi-cloud complexity.
6. Build and rehearse the exit plan
Set migration waves, acceptance criteria, rollback points and accountable owners. Test exports and restoration regularly. Revisit the plan after major architecture, pricing or regulatory changes.
How regulation could change the cloud market
UK cloud computing regulation could eventually improve pricing transparency, interoperability and customer choice. Potential interventions might address technical barriers, licensing restrictions, egress policies or the information customers receive before entering long commitments. The AWS Azure competition debate may also encourage providers to simplify migration assistance voluntarily.
Regulation cannot make complex applications instantly portable, however. Even with lower transfer charges, businesses must still redesign proprietary integrations, validate data and build destination expertise. Organisations should monitor the CMA process while improving their own readiness rather than assuming a future remedy will remove every cloud migration challenge.
Frequently asked questions
Is it always expensive to move data out of AWS or Azure?
No. Cost depends on data volume, services, region, architecture and eligibility for provider exit policies. Small, portable workloads may move relatively easily. Large data platforms with proprietary dependencies can be expensive even when qualifying egress is waived.
Does multi-cloud eliminate cloud provider lock-in?
Not automatically. Multi-cloud can diversify dependency, but each workload may remain tied to a particular provider. Genuine cloud portability requires tested deployment, data, identity and recovery processes.
Should businesses stop using proprietary managed services?
No. Managed services can provide substantial security, reliability and productivity benefits. Businesses should assess whether those benefits justify the switching cost and document an alternative for critical systems.
What should a cloud exit strategy include?
It should identify dependencies, data-export methods, migration costs, contractual notice requirements, destination options, staffing needs, cutover steps, rollback procedures and tests proving that backups can be restored elsewhere.
Cloud choice depends on maintaining credible options
Moving away from AWS or Azure is difficult because modern cloud computing combines technology, data, skills and commercial commitments into one operating model. Egress fees matter, but they are only one part of the challenge.
The right response is not an automatic move away from a major provider. It is to understand dependencies, price the exit path and decide where portability is worth the investment. Businesses with documented architectures, tested exports and a realistic cloud exit plan can continue using powerful managed services without surrendering control over their future choices.
