Cloud Portability Has a Postcode

Summary

• Cloud exit and multicloud transfer are becoming different contractual products rather than variations of one network tariff. A complete switch, a switch away from one service while retaining others, and continuing in-parallel use across clouds can carry different rights even at the same provider. AWS, Microsoft Azure and Google Cloud now distinguish among these cases through combinations of free switching periods, at-cost parallel transfer, service eligibility rules, account or billing geography, source-region conditions, destination verification and network-path requirements.

• The UK Competition and Markets Authority has helped push these distinctions into more concrete rights. Its March 2026 actions paper recorded 180-day switching periods, single-service switching, lower ongoing multicloud egress, contractual changes and direct-interconnect work by AWS and Microsoft. But the CMA also said further steps were required and planned a six-month progress review. As of 22 August 2026 that review point had not arrived. These measures therefore matter as present contractual and technical options, not yet as evidence that switching rates rose, competitive concentration fell or customers became materially more mobile.

• Egress remains important without being the universal explanation for cloud lock-in. The CMA found mixed customer evidence: recurring cross-cloud synchronization and data-intensive architectures can make transfer charges consequential, while technical differentiation, PaaS and serverless dependence, committed-spend arrangements and migration work can be equally important or larger obstacles. Lowering the network price can make an exit economically credible; it does not automatically make an application portable.

One provider, several meanings of “leave”

The useful starting point is to separate three transactions that cloud contracts increasingly treat differently.

A complete switch means leaving the relevant provider footprint within the contractual scope. A service switch means ceasing to use an individual eligible service while continuing to buy others from the same provider. In-parallel multicloud use is not an exit at all: the customer continues using both environments and transfers data between them as part of an ongoing architecture.

That distinction matters because the economic shape of the traffic is different. A switch can be a concentrated migration event. A highly integrated multicloud application may move data every hour for years. The CMA's 2025 investigation made precisely this distinction: the effect of egress charges depends on how much data moves and how frequently it moves. Synchronizing large datasets across clouds can therefore create a recurring cost exposure that a one-off migration does not.

This is also why “free egress” is an increasingly inadequate procurement question. Free for what? From which region? For how long? Over which network? To whose infrastructure? Must the source service be terminated? Can the rest of the account remain? Does the destination belong to the same organisation? Does a support ticket have to precede the first byte?

Those questions now determine the usable right.

The CMA changed the bargaining surface

The CMA's final cloud-services report concluded that technical and commercial barriers restrict customers' ability to switch and use multiple clouds. Its customer evidence did not support a simple claim that egress charges dominate every decision. Some customers regarded them as material, especially where architectures required large or frequent transfers. Others pointed to committed spending, migration effort or dependence on more abstract services such as PaaS and serverless.

That mixed evidence is economically important. It prevents a category error in which removing one charge is treated as equivalent to making a workload portable.

In March 2026, however, the CMA recorded substantial movement in the UK. AWS and Microsoft had taken or committed to steps including switching periods of at least 180 days, the ability to switch an individual service, lower ongoing egress charges for multicloud use and work on direct connections between cloud environments. The CMA described these changes as potentially beneficial but explicitly left their effectiveness open, saying more was needed and that progress would be reviewed after six months.

That timing matters. On 22 August, the market has more concrete rights than it had when the CMA completed its investigation, but not yet the regulator's six-month assessment of how they work in practice. There is no evidence basis here for claiming that the measures have produced a particular change in adoption, churn, market share or customer savings.

The more defensible conclusion is narrower: the competitive bargaining surface has changed. Portability is moving from a general promise toward a set of specified transactions that customers can attempt to price and contract for.

AWS: global exit and a more specific UK right

AWS illustrates the geography particularly clearly.

Its global free-exit programme is available across customers and AWS Regions through a Support request. The current transfer period is 90 days, and using the programme does not require the AWS account itself to be closed. EU arrangements are distinct.

For UK customers, the contractual geometry becomes more precise. The AWS UK Customer Switching and Portability Addendum defines an Eligible Account by its UK Account Country. It requires a switching request at least two months before the planned start and provides a 180-calendar-day transition. That framework covers both a complete switch and a switch away from an individual eligible service.

The same addendum separately addresses ongoing multicloud use. When eligible AWS services are used alongside a destination provider rather than as part of a switch, eligible outbound transfer can be priced no higher than AWS's costs. But the purpose matters: the transfer must be for the customer's internal use of the destination provider's eligible services. Traffic to end users, customers or other third parties is outside that benefit. A customer must also request the treatment through Support before the planned start.

That is a useful example of portability acquiring contractual coordinates. The account's country matters. The customer's purpose matters. Destination ownership matters. Procedure matters. Two transfers that look identical to a router can therefore have different commercial treatment.

AWS Interconnect – multicloud adds another model. AWS says there is no per-gigabyte AWS data-transfer charge on the product, and a customer may create one free 500 Mbps interconnect per cloud service provider per AWS Region. Yet the other cloud provider determines and bills its side independently.

The result is not universally free cross-cloud networking. It is a different cost architecture: AWS's per-gigabyte charge falls away on that path, while capacity, topology and the other provider's terms still matter.

Azure: billing geography meets network geography

Microsoft Azure draws similar distinctions, but along somewhat different lines.

Its global exit-credit procedure covers Internet egress for a customer leaving Azure for up to 60 days. Once the migration is complete, the procedure requires cancellation of all subscriptions associated with the account. Ordinary Azure service charges remain, and specialist transfer routes including ExpressRoute, VPN, Azure Front Door and CDN are not covered by the exit credit.

UK treatment is broader in important respects. Customers with a UK billing address transferring from UK datacentres can receive up to 180 days and may exit individual Azure services rather than the entire Azure relationship. Under documented conditions, eligible treatment also reaches the Microsoft Premium Global Network.

That creates two layers of geography. Billing address helps determine whether the customer is in the relevant contractual class, while the location from which data is transferred can determine whether the broader UK treatment applies.

Azure's continuing multicloud treatment adds further coordinates. Organisations with billing addresses in the EEA, EFTA or UK can request at-cost transfer, subject to where their Customer Data is stored. The process calls for a Support request containing the subscription ID, the destination autonomous system number and an estimate of the traffic to be transferred.

The destination also has to perform data processing for the same organisation. CDN delivery and transfers to endpoints belonging to different customers are outside the documented scope. Whether traffic uses the Internet or Microsoft's premium network can alter eligibility, and the UK rules attach additional significance to transfers originating from UK datacentres.

For a network engineer, an ASN is routing information. Under these arrangements it also becomes part of a commercial proof: evidence that traffic is going where the customer says it is going.

Google: exit is not the same product as parallel use

Google Cloud makes the separation between exit and continuing multicloud use especially visible.

Its Exit Cloud programme is organised through notice, initiation, migration and completion stages. Eligible Internet data transfer is credited when the customer leaves the relevant Google Cloud service. The customer can continue using other Google Cloud services, so an exit need not mean abandoning the entire provider relationship.

But leaving only part of the relevant service while continuing to operate it is a different case. For European partial or parallel use, Google points customers toward Data Transfer Essentials.

Data Transfer Essentials is initially offered at no charge for qualifying cross-cloud traffic between services of the same organisation. Eligibility depends on supported Google services, network tiers and European regions. The traffic must use external IP connectivity, and the customer configures destination IP addresses associated with recognised ASNs.

Again, purpose is a boundary. Data Transfer Essentials is intended for intra-organisation workloads spread across providers, not applications delivering traffic to third-party end users. Google may validate the destination. An endpoint that does not satisfy the criteria can fall back to ordinary Internet billing.

There is another important limitation: Data Transfer Essentials itself carries no service-level agreement. And a service already enrolled in Google's exit programme cannot simultaneously use Essentials.

That last rule demonstrates why buyers need to classify the transaction before they calculate its price. Exit and parallel operation are not merely two billing codes attached to an interchangeable stream of packets. They create mutually relevant contractual states.

Europe separates switching from interoperability

The EU Data Act gives these commercial changes a broader legal frame.

The Act has applied since 12 September 2025. Article 25 establishes contractual switching duties and timing rules, requiring switching rights to be set out in the contract and creating obligations around assistance, continuity and portability.

Article 29 governs switching charges. During the transition, charges associated with switching may not exceed costs directly linked to the switching process. From 12 January 2027, providers may no longer impose switching charges on the customer for that process.

That is not a rule making every form of cross-cloud data movement free.

Article 34 deals separately with in-parallel use. When data-processing services are being used alongside one another, providers may impose data-egress charges for the purpose of passing through the costs they incur, provided those charges do not exceed those costs.

The distinction is fundamental. European policy is moving towards zero switching charges for the act of changing provider while allowing cost recovery for continuing interoperability between providers. A buyer planning a migration therefore faces a different entitlement from one designing a permanently synchronized multicloud application.

The market should resist collapsing those cases into a single slogan about egress.

Price is only one layer of portability

The CMA evidence is most valuable where it resists monocausal explanations.

A database that must remain continuously synchronized across two clouds is unusually sensitive to recurring transfer economics. A relatively self-contained workload with modest transfer volumes may not be. A serverless application deeply bound to one provider's event model can have cheap networking and still be expensive to recreate elsewhere. A customer with a large committed-spend obligation may possess technical exit options but weak financial incentives to exercise them before the commitment expires.

Migration work sits across all of these cases. Data has to be identified, extracted, moved, validated and implemented in the destination. Network and security policy must be rebuilt or adapted. Dependencies have to be discovered. Operations teams need to know whether the new system produces comparable behaviour under load and failure.

Free bytes do not perform that work.

This does not make egress reform trivial. Lower transfer costs can alter whether an exit is credible, particularly for data-heavy designs. They can also make it less expensive to preserve optionality by maintaining selected workloads across providers. What they cannot do is transform proprietary application dependencies into portable ones.

The competitive test is therefore whether the customer has a usable alternative, not whether one line on the price sheet reaches zero.

The new procurement entity is a map

For procurement teams, cloud portability is becoming something that should be mapped before the architecture is fixed.

The map needs at least seven coordinates: the legal or billing geography of the account; the source region of the data; the service being left or retained; whether the transaction is a complete switch, service switch or continuing parallel use; the permitted network path; the identity or ownership of the destination; and the notice, support or validation procedure required to activate the benefit.

Committed-spend terms then sit over that map as a separate economic layer. A workload may possess a free or at-cost path outward while the organisation still has strong reasons to consume prepaid or committed capacity where it already resides.

Architecture adds another layer. The buyer needs to know what must be rewritten, not merely what can be copied.

This is where geography should organise service without disappearing into an opaque source of control. It is reasonable for a provider to distinguish a switch from delivery to millions of external users. It is reasonable to verify a destination when a preferential tariff is restricted to intra-company traffic. The coordination required to do that should be thin, explicit and verifiable: enough to classify the transaction, not so elaborate that the classification mechanism itself becomes a new switching barrier.

A good cloud provider should ultimately retain customers because its service is better for their workload, not because the customer cannot confidently determine the price or procedure for leaving.

Cloud portability therefore does not need one universal global zero price to become more competitive. It needs rights that can be read, compared and modelled before the consequential decisions are made. By the time an enterprise has standardized on proprietary services, concentrated its data, accepted long committed-spend terms and built operating procedures around one control plane, the formal existence of an exit programme may be much less valuable.

The postcode needs to be visible while the buyer can still choose where to build.

Sources

1. UK Competition and Markets Authority — Cloud services market investigation https://www.gov.uk/cma-cases/cloud-services-market-investigation

2. Competition and Markets Authority — Cloud Infrastructure Services: Final decision report https://assets.publishing.service.gov.uk/media/688b8891fdde2b8f73469544/final_decision_report.pdf

3. Competition and Markets Authority — Appendix N: Egress fees — free switching programmes https://assets.publishing.service.gov.uk/media/688b8169fc784fa12a089071/Appendix_N_-_Egress_fees___free_switching_programmes.pdf

4. Competition and Markets Authority — Appendix O: Customer views on egress fees https://assets.publishing.service.gov.uk/media/688b817cfc784fa12a089072/Appendix_O_-_Customer_views_on_egress_fees.pdf

5. Competition and Markets Authority — Actions on cloud and business software through the UK digital markets competition regime https://assets.publishing.service.gov.uk/media/69cbb8d52d120d9d5ec0f311/Actions_on_cloud_and_business_software_through_the_UK_digital_markets_competition_regime.pdf

6. AWS — Free data transfer out to internet when moving out of AWS https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/

7. AWS — UK Customer Switching and Portability Addendum https://d1.awsstatic.com/onedam/marketing-channels/website/aws/en_US/legal/approved/aws-uk-customer-switching-addendum.pdf

8. AWS — Interconnect – multicloud pricing https://aws.amazon.com/interconnect/multicloud/pricing/

9. Microsoft Azure — Cancel and delete your Azure subscription https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/cancel-azure-subscription

10. Microsoft Azure — Data transfer fees https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/data-transfer-fees

11. Google Cloud — Exit Cloud https://cloud.google.com/exit-cloud

12. Google Cloud — Data portability and switching procedures https://cloud.google.com/terms/data-portability

13. Google Cloud — Data Transfer Essentials overview https://docs.cloud.google.com/data-transfer-essentials/docs/overview

14. Google Cloud — Data Transfer Essentials supported services and regions https://docs.cloud.google.com/data-transfer-essentials/docs/services

15. European Union — Regulation (EU) 2023/2854, Data Act https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R2854

16. European Commission — Data Act explained https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained