A software team can copy its data to another cloud and still have most of the move ahead of it. The application needs permissions, monitoring, a working database and someone willing to answer the support call when an overnight job fails. Removing the charge for taking data out helps with one line of the budget. It does not price the rest of that work.
That distinction matters when judging the businesses behind Amazon Web Services, Microsoft Azure and Google Cloud. Easier switching can give customers more bargaining power and competing suppliers a route into an account. Whether it changes revenue or margins depends on what customers actually move, how long deployment takes and what they pay afterwards.
The relevant listed parents are Amazon.com (Nasdaq: AMZN), Microsoft (Nasdaq: MSFT) and Alphabet (Nasdaq: GOOGL, Class A). Their transfer policies are evidence about commercial terms, rather than evidence that a particular customer has completed a profitable migration. The policies below were checked on 20 October 2026.
Fact: an exit credit has a defined boundary
AWS’s EC2 exit-transfer guidance says its free internet data-transfer-out programme covers moving all data off AWS across eligible accounts, or all data off a particular AWS service across those accounts. Eligibility and the specified process matter.
Google Cloud’s exit programme similarly requires ending all use of the relevant service, while allowing other Google Cloud services to continue. Customers submit an exit notice and follow migration and completion steps. The eligible transfer cost is credited on the final invoices. That is a narrower promise than making every ongoing data movement free.
Microsoft’s Azure exit guidance specifies advance notice, a transfer period and a request for invoice-level credit. Its general window is 60 days; UK-billed customers transferring from UK datacentres have a 180-day window and can leave individual services. Standard Azure service charges and specified specialist-network transfers are excluded from the credit offer.
Azure · exit policy
Qualifying UK exit window
Days of eligible egress
UK billing · UK datacentres
These windows describe the credit policy, not a promise about how quickly a team can finish its migration. Eligibility needs checking against the actual service and contract before treating a quoted transfer saving as available cash.
Running in two places is another product decision
Some customers want to keep an application in one cloud while using a service in another. Google’s separate Data Transfer Essentials documentation describes supported cross-cloud traffic within the same organisation, with service, tier and region limits. It explicitly distinguishes that traffic from applications serving end users on other clouds, which retain default transfer pricing. An exit programme and a multi-cloud pricing arrangement should therefore be assessed separately.
The regulatory backdrop also goes beyond the transfer bill. In its 31 March 2026 announcement, the UK Competition and Markets Authority described actions by Amazon and Microsoft on egress fees and interoperability, while saying further steps were required. That dated announcement explains the policy pressure; it is not a claim here about the outcome of any subsequent regulatory decision.
Interpretation: follow the application through the move
Consider an explicitly hypothetical reporting application. Its stored records can be exported, but its jobs also rely on a managed database, scheduled tasks and staff access rules. Moving the files completes one task. The replacement deployment still needs to produce the right report, restrict access correctly and recover when a job stops halfway through.
That produces three different economic questions. What does the team pay once to move? What does it pay while both systems run? What does the finished service cost each month? A transfer credit affects the first question. Duplicate environments can affect the second. Compute, storage, support and the architecture of the replacement affect the third.
A useful business comparison holds the output constant: the same completed work, required availability and security controls. Comparing a discounted storage rate with an old bill containing several managed services will not establish a saving. Equally, assuming every dependency needs a complete rewrite can exaggerate the cost of leaving. The application inventory has to settle that distinction.
The timing of a credit matters to cash planning, too. A later invoice adjustment can reduce the eventual expense while leaving a temporary funding requirement during migration. The accounting description and the payment schedule deserve separate rows in the model. Neither tells us, by itself, whether the original cloud supplier will lose the customer at its next renewal.
Who could benefit?
Conditional interpretation: Alphabet could gain Google Cloud consumption if customers can move a suitable workload into it, or connect an existing application to its services at an acceptable total cost. Google’s documented cross-cloud offering supplies a concrete route for some architectures. The business test over subsequent quarters would be sustained paid usage after migration support and discounts, with enough contribution to cover delivery costs. A transfer policy alone supplies no estimate of that contribution.
Amazon and Microsoft can also be destination providers. Their own exit programmes do not establish that traffic flows only outwards. A customer leaving a rival could bring recurring compute and storage demand into AWS or Azure if the replacement deployment meets its operational and financial requirements. The opportunity is workload-specific; none of the cited policies measures net customer gains.
Who’s at risk?
Conditional interpretation: Amazon, Microsoft and Alphabet each face the reverse mechanism when they are the incumbent. A lower practical cost of leaving could make a competing bid credible, producing either lost consumption or a concession at renewal. That risk becomes more material if it affects a broad set of valuable workloads, rather than a small data export.
The margin effect is unresolved. A supplier might retain usage with lower prices, win new usage that needs costly support, or lose low-contribution business. Revenue retention and profit retention are different tests. These diversified parents also have businesses beyond the cloud services discussed here, so no parent-wide earnings sensitivity can be calculated from these policies.
Speculation: what would change the assessment?
A plausible scenario is that cheaper transfers improve negotiating power more quickly than they generate completed moves. Another is that a growing set of portable applications makes switching routine enough to change where recurring consumption lands. Neither outcome is demonstrated by a free-exit announcement.
The missing evidence is specific: completed migrations, the time and support required, recurring bills after introductory offers and comparable customer-retention data. This article has not tested a migration or estimated company-specific savings. Contract terms, geography and technical dependencies limit generalisation. A working application with a lower continuing bill would be stronger evidence than a waived transfer fee on its own.
Financial information and analysis, not a recommendation to buy, sell or hold any security.
Photo by Sergei Starostin on Pexels. Cables connected to network equipment.