From 12 January 2027, cloud providers may no longer impose switching charges on EU customers for moving to another provider or back on-premise, and that prohibition expressly includes egress fees. Standard service fees and proportionate early termination penalties sit outside the ban, but the toll on the exit road itself, the charge that has anchored every vendor lock-in conversation for a decade, is going. On paper, this looks like the end of cloud captivity. The numbers tell a different story. Gartner analysts have observed that egress typically accounts for 10 to 15 per cent of a total cloud bill, and IDC’s 2021 storage research found egress fees averaging 6 per cent of cloud storage costs specifically. If egress were really what kept workloads where they are, switching rates would not sit below 1 per cent annually, which is where the CMA’s market investigation found them. The cloud exit cost problem was never primarily about egress.
Most organisations respond to the Data Act in one of two ways, and both are wrong. The first group treats it as a legal compliance exercise: hand it to procurement, update the contract clauses, move on. The second group treats the egress fee ban as the removal of lock-in itself, and starts sketching migration plans on the assumption that leaving is about to become cheap. Both groups will discover the same thing at the worst possible moment: the transfer fee was always the smallest line item in an exit. The re-engineering cost of proprietary service coupling, the stranded value in committed spend agreements, the parallel running bill during cutover, and the retraining overhead dwarf it, often by an order of magnitude. When 37signals left AWS, the company’s own published figures showed cloud spend only collapsed once its reserved instance terms expired, not when the data moved.
What senior architects need instead is an exit cost audit: a structured, per-workload assessment of what leaving would actually cost, run before any negotiation or migration decision, and refreshed as the January 2027 deadline approaches. This post sets out a seven-component audit methodology, compares how AWS, Azure and Google Cloud have responded to the Data Act and to the UK’s parallel regulatory process (the differences are material), and works through verified migrations including Hermes Germany’s zero-downtime switch from AWS to Google Cloud, which cut infrastructure costs by 25 per cent. The Data Act does not make exits free. It makes exit costs legible, and legible costs are negotiable.
Why the Data Act Changes the Exit Calculation
The European cloud infrastructure market reached €61 billion in 2024, with AWS, Microsoft and Google accounting for around 70 per cent of regional spend and European providers collectively holding about 15 per cent, according to Synergy Research Group. In the UK, customers spent £10.5 billion on cloud infrastructure services in 2024, a figure that has grown nearly 30 per cent per year since 2020. Against that backdrop, the CMA’s cloud services market investigation concluded in July 2025 that competition is not working well, naming egress fees and technical barriers among the features harming it, and finding that fewer than 1 per cent of customers switch providers in any given year.
Regulation (EU) 2023/2854, the Data Act, is the EU’s structural answer. It entered into force on 11 January 2024 and its cloud switching provisions became applicable on 12 September 2025, with no grace period for existing contracts. The commercial significance is not the compliance burden. It is that, for the first time, providers are legally obliged to make exit terms explicit, capped, and eventually free of switching charges, which converts exit cost from an unknowable deterrent into a number you can put in a business case and a lever you can pull in a renewal negotiation. The window between now and January 2027 is a negotiation window, and the providers know it: all three hyperscalers made voluntary concessions ahead of the deadline, and in March 2026 the CMA accepted voluntary commitments from AWS and Microsoft on egress fees, switching windows and interoperability rather than opening a formal market status investigation into cloud infrastructure, while separately launching one into Microsoft’s wider software ecosystem in May 2026.
The strategic question for architecture teams is therefore not whether to leave a hyperscaler. Most will not, and for good reasons explored in our assessment of when not to go multi-cloud. The question is whether you know what leaving would cost, per workload, with enough precision to negotiate from strength and to invest in portability where the audit shows it pays.
The State of Cloud Switching in 2026
The switching landscape has moved faster in the last two years than in the previous ten. Google moved first, announcing free network data transfer for departing customers on 12 January 2024, the Data Act’s entry-into-force date. AWS followed on 5 March 2024 with a waiver of data transfer out to the internet for customers moving off the platform, noting that over 90 per cent of its customers already pay nothing for egress thanks to the 100 GB monthly free allowance. Microsoft completed the set in mid-March 2024 with free egress for customers leaving Azure. In September 2025, days before the Data Act’s applicability date, Google went further and launched Data Transfer Essentials, a service providing zero-cost ongoing multi-cloud transfers for eligible EU and UK intra-organisation traffic, going beyond the Act’s minimum requirement of at-cost pass-through for parallel use. And in 2026 the ground shifted again: AWS Interconnect for multicloud reached general availability in April with Google Cloud as its first partner, followed in May by a free 500 Mbps interconnect tier per region, with no per-gigabyte transfer charges on the connection at all.
The temptation is to read this sequence as the end of egress economics. It is not, for two reasons. First, the free-exit programmes are narrow: they cover one-time internet data transfer out for a genuine exit of the relevant services, executed inside a provider-defined window and process. Ongoing operational egress serving your own users, per-request charges, archive retrieval fees, cross-availability-zone transfer, NAT gateway processing and specialised connectivity all remain fully chargeable. Second, and more importantly, egress was never the dominant exit cost. The repatriation data makes the point: Flexera’s 2025 State of the Cloud report found 21 per cent of workloads had been repatriated from public cloud, yet net cloud growth continues and 84 per cent of respondents still name managing cloud spend as their top challenge. Organisations that actually execute exits, such as 37signals and Dropbox before it, consistently report that the engineering effort, not the transfer bill, defined the project.
A common misconception worth addressing directly: the Data Act does not mandate portability of proprietary services. Its functional equivalence obligation applies to IaaS only, and even there it requires “materially comparable outcomes” for features the source and destination services share. Nothing in the Act converts a DynamoDB dependency, a Step Functions workflow or a BigQuery estate into a portable asset. That work remains yours, and pricing it is the point of the audit.
What the Data Act Actually Requires
Understanding the Act’s mechanics matters because the obligations, and their limits, define what you can rely on contractually versus what you must architect for yourself.
The Act covers “data processing services”, a definition built on the NIST cloud model that encompasses IaaS, PaaS, SaaS and edge services supplied to customers in the EU. Purely on-premise software is out of scope. The practical test emerging from practitioner commentary is simple: if a component runs on the provider’s managed infrastructure, assume the switching rules apply to it.
The charge taxonomy is where architects should focus. The Act distinguishes switching charges from parallel-use egress. Switching charges are anything, beyond standard service fees or proportionate early termination penalties, that a provider levies for moving to another provider or on-premise, and the definition expressly includes egress charges. During the transition period that runs until 12 January 2027, providers may levy only reduced switching charges limited to costs directly incurred. From that date, switching charges are banned outright for EU customers. Egress for in-parallel use, meaning ongoing multi-cloud operation rather than an exit, is treated differently under Article 34: it remains permitted indefinitely, but only at cost, with no margin. That carve-out is why ongoing multi-cloud egress remains a live architectural concern after 2027, and why Google’s decision to zero-rate it through Data Transfer Essentials is commercially interesting rather than legally required.
The contractual obligations are equally concrete. Contracts must specify a maximum notice period of two months to initiate switching, a transitional period of up to 30 days (extendable to a maximum of seven months only where technical unfeasibility is demonstrated), an exhaustive list of exportable data categories and digital assets, good-faith cooperation duties on the source provider, and continuity of service during the switch. Providers must publish their switching charge information before contract signature. For IaaS specifically, the source provider must take all reasonable measures to help the customer achieve functional equivalence on the destination service. PaaS and SaaS providers carry a lighter duty: open interfaces and structured, machine-readable export formats. To support drafting, the European Commission published a draft Recommendation on non-binding Standard Contractual Clauses for cloud computing contracts on 19 November 2025, with modular clauses covering switching and exit, termination, and security and business continuity; the clauses remain voluntary and in draft, but they are the closest thing to pre-vetted Data Act contract language currently available.
Enforcement is where certainty ends. The Act delegates penalties and supervision to Member States, and implementation timing varies: Germany’s Data Act Implementation Act entered into force on 30 May 2026, designating the Bundesnetzagentur as the central enforcement authority with a tiered penalty regime, while the Netherlands has empowered the ACM and France enforces through its SREN law, each with jurisdiction-specific maximum fines that are not directly comparable across borders. Several Member States were still finalising implementing legislation into 2026. Where personal data is involved, GDPR authorities retain their existing powers. For architects, the message is that the contractual rights are solid but the enforcement backstop varies by jurisdiction, which strengthens the case for negotiating the Act’s requirements into contract terms explicitly rather than relying on the regulation alone.
The Seven Components of a Cloud Exit Cost Audit
The audit exists to answer one question per workload: what would it cost, in money and months, to run this somewhere else? Seven components, assessed in order, produce that answer.
Component one: data gravity and volume. Inventory total data per workload, split hot from archive, and record replication factors and regions. The per-gigabyte transfer maths is the easy part; the harder outputs are transfer duration at realistic throughput and the parallel-running window it implies. When 37signals moved almost 6 PB out of S3, the company estimated at least three weeks of continuous transfer on a dedicated 40 Gbps path once overheads were counted. Every day of transfer is a day of paying two providers. For very large estates, physical transfer services such as AWS Snowball sidestep network egress entirely and should be priced as an alternative.
Component two: archive tier retrieval. Free-exit programmes waive internet transfer, not retrieval. Data in S3 Glacier Flexible Retrieval costs $0.01 per GB at standard speed to retrieve (bulk retrieval is free but takes 5 to 12 hours), while Glacier Deep Archive standard retrieval runs at $0.02 per GB with a 12-hour wait, or $0.0025 per GB in bulk over 48 hours. Azure Archive requires rehydration to a warmer tier before data can move at all, and GCP’s Archive class carries both retrieval charges and early deletion penalties. Model retrieval cost and retrieval time separately: bulk tiers are cheap but can add weeks to an exit timeline for multi-petabyte archives. These are simplified estimates rather than complete migration quotations: request charges, temporary warmer-tier storage and minimum-duration penalties add to the real figure, and all rates quoted in this post are published US-region list prices that should be confirmed at the live calculators for your region before they go into a business case.
Component three: proprietary service coupling. This is almost always the largest number in the audit. Every workload consuming DynamoDB, Cosmos DB, BigQuery, Lambda, Azure Functions, Cloud Run, Step Functions, EventBridge or a proprietary machine learning service carries a re-engineering cost with no equivalent line on any invoice. When 37signals exited AWS, the engineering work meant replacing RDS with self-managed MySQL, ElastiCache with Redis, the managed Elasticsearch service with a self-hosted cluster, S3 with on-premise object storage, and AWS load balancers with HAProxy. Score each workload on a simple scale: portable (containers, open-source data stores, standard protocols), translatable (managed services with open-source engines underneath, such as RDS for PostgreSQL or Cloud SQL), and coupled (proprietary APIs with no drop-in equivalent). The coupled category is where exit cost lives, a theme we examined from the prevention side in our guide to breaking free from cloud vendor lock-in.
Component four: managed database export paths. Databases sit between translatable and coupled and deserve their own line. Same-engine moves (PostgreSQL to PostgreSQL) are tooling exercises using AWS DMS, Azure Database Migration Service or GCP’s Database Migration Service. Cross-engine moves (Aurora to Cloud SQL for a workload using Aurora-specific features, or anything leaving Cosmos DB) add schema translation, query rewrites and application regression testing. Record for each database the engine, the engine-specific features in use, the size, and the acceptable cutover downtime, because near-zero-downtime replication-based migration costs materially more in effort than a dump-and-restore window.
Component five: committed spend friction. The sleeper cost, and frequently the decisive one. Reserved instances, savings plans, committed use discounts and enterprise agreements (AWS EDPs, Microsoft MACCs, Google commit contracts) all carry minimums that do not evaporate because you left. An exit mid-commitment strands the remaining value or triggers shortfall clauses. The 37signals numbers illustrate the shape of the problem: monthly cloud spend fell from roughly $180,000 to under $80,000 only after reserved instance terms expired, months after the workloads had physically moved. Your audit should record every commitment’s end date, remaining value and transferability, and any exit plan should be timed against that calendar. The purchasing discipline that prevents this friction accumulating is covered in our reserved instance decision framework.
Component six: identity, observability and licensing re-integration. Three estates that must be rebuilt rather than transferred. IAM policies, Entra ID integrations and Cloud IAM bindings encode years of accumulated authorisation decisions and rarely map one-to-one across providers. Observability pipelines need re-pointing, and historical telemetry either moves (as chargeable data) or is abandoned. Licensing deserves particular scrutiny for Microsoft-heavy estates: the CMA found that Microsoft charges AWS and Google materially higher effective prices for key business software than it charges on Azure, a concern prominent enough that the CMA opened a formal investigation into Microsoft’s business software ecosystem in May 2026. The licensing delta is a recurring exit cost for any workload running Windows Server or SQL Server, in whichever direction you move.
Component seven: skills, parallel running and testing. The residual category that migration business cases most reliably underestimate. Retraining and hiring for the destination platform, dual-running both environments through cutover, and full functional, performance and failover validation on the destination side recur in every published migration account. Spotify’s move to Google Cloud, one of the best-documented large migrations, involved deliberately purchasing significant parallel on-premise capacity to de-risk the transition. These costs scale with workload criticality rather than data volume, which is why the audit is per-workload rather than per-account. The broader pattern of underestimated migration costs is one we have covered before in the hidden costs of cloud migration.
The audit’s output is a per-workload table: data volume and tier split, retrieval cost and time, coupling score, database path, commitment exposure and end dates, re-integration estimate, and a parallel-running window. Sum it and you have the real exit number. In most estates, egress will be a single-digit percentage of it.
How AWS, Azure and Google Cloud Compare on Exit Terms
The comparison is more layered than it was in 2024, because each provider now operates up to three overlapping regimes: a general worldwide free-exit programme, EU Data Act contractual terms, and UK-specific commitments made to the CMA in March 2026. The programmes and the statutory rights overlap but are not identical, and conflating them produces wrong answers.
AWS waives data transfer out to the internet for customers moving off the platform. Customers within the standard 100 GB monthly free allowance need do nothing; those above it contact AWS Support for credits, reviewed at account level. AWS’s published materials have referenced both 60-day and 90-day completion periods at different points, so the applicable window should be confirmed with support when the exit is scoped, and 37signals’ engineers have described negotiating a 90-day window for their 6 PB transfer. AWS does not require account closure to grant the waiver, although the programme expects the covered data and services to actually move off the platform and repeat applications attract additional scrutiny. For EU customers, Data Act switching runs through the AWS EU Data Act Addendum with the statutory notice and transition periods, and AWS’s UK commitments include a 180-day switching window alongside interoperability measures.
Azure’s general programme offers free egress for customers leaving the platform, with the first 100 GB monthly free as standard. Beyond that, the customer contacts Azure Support, and the credit is applied only after the transfer completes and all Azure subscriptions associated with the account are cancelled, inside a 60-day window; where services were purchased through a partner, the partner must request the credits. Only Azure Storage data transfer out is eligible, with ExpressRoute, VPN, Front Door and CDN excluded. The UK position is now materially better: under the UK Azure Services Switching and Multicloud Addendum, effective 1 June 2026, UK-billed customers moving data from UK-hosted workloads get up to 180 days, and the definition of a qualifying switch extends to exiting an individual Azure service rather than abandoning Azure entirely. Microsoft has also committed to at-cost egress on its global network for UK multi-cloud use, mirroring its September 2025 at-cost pricing for EU parallel-use cases under Article 34.
Google’s programme is service-specific by design: customers must end use of the relevant Google Cloud services being migrated, while other Google Cloud usage can continue. The process runs through an Exit Notice, a 14-day triage in which Google assigns a billing support agent and flags any technically justified extra time, a 30-day Initiation Period to begin the migration, and a Migration Period of at least 30 days, extendable where Google has identified technical need. Covered services are explicit (BigQuery, Bigtable, Cloud SQL, Cloud Storage, Datastore, Filestore, Spanner and Persistent Disk) and the programme applies to Premium Tier networking customers, with Google reserving audit rights. For ongoing multi-cloud traffic, Google’s Data Transfer Essentials remains the broadest no-cost public-internet programme, zero-rating eligible intra-organisation transfers for EU and UK customers, though it excludes traffic serving external users. AWS’s answer arrived in 2026 from a different direction: AWS Interconnect for multicloud, generally available since April 2026 with Google Cloud as launch partner (London and Frankfurt are among the region pairs), prices private cross-cloud connectivity by bandwidth with no per-gigabyte transfer fees, and since May 2026 includes one free 500 Mbps interconnect per region, enough for roughly 160 TB of monthly transfer. Microsoft’s equivalent Azure support for Interconnect is expected later in 2026, and its qualifying multi-cloud transfers are otherwise priced at cost.
| Dimension | AWS | Azure | Google Cloud |
|---|---|---|---|
| General free-exit programme | Support credits above 100 GB/month free tier; published windows have cited 60 and 90 days, confirm at scoping; no account closure required | Support credits above 100 GB/month free tier; 60 days; all subscriptions cancelled before credit; partner claims for CSP | Service-specific exit via Exit Notice; 14-day triage, 30-day initiation, 30-day-plus migration period with technical extensions |
| EU Data Act switching | EU Data Act Addendum; statutory notice and transition periods | Data Act-aligned switching terms; at-cost EU parallel-use egress since Sept 2025 | EU Data Act Terms in General Service Terms for EEA-billed customers |
| UK-specific position | 180-day switching window; UK addendum and interoperability commitments (March 2026) | 180 days for UK-billed, UK-hosted workloads; individual-service switch qualifies (Addendum, 1 June 2026) | Data Transfer Essentials covers eligible UK traffic |
| Ongoing multi-cloud transfer | Interconnect multicloud: bandwidth-priced, no per-GB fees; free 500 Mbps tier per region since May 2026 | At cost (EU and UK); Interconnect support expected later in 2026 | Zero cost via Data Transfer Essentials for eligible intra-organisation EU/UK traffic |
| Notable exclusions | Ongoing operational egress, per-request charges, Glacier retrieval | ExpressRoute, VPN, Front Door, CDN | Non-covered services, Standard Tier networking, external-user traffic under DTE |
Which provider carries the most exit friction depends on the workload, not the brand. Azure exit friction tends to be dominated by Microsoft licensing economics for Windows Server and SQL Server estates, a factor that follows the workload to any destination. AWS exit friction tends to concentrate in proprietary service coupling, given the depth of its service catalogue, although its exit process is the least prescriptive of the three. Google exit friction tends to concentrate in hard-to-translate data services such as BigQuery and Spanner, offset by the most generous ongoing transfer terms. These are patterns to test against your own audit scores rather than a ranking to inherit.
Real-World Case Studies
Company Name and Industry: Hermes Germany, Logistics and Parcel Delivery
Scale Context: Mission-critical Track and Trace application handling more than 2.5 million tracking requests
Challenge: Migrate a customer-facing, mission-critical application off AWS without downtime and reduce running costs.
Solution Implemented: Containerised services moved to Google Cloud Run with Apigee for API management; both clouds run in parallel during migration with cutover executed via DNS switch.
Measurable Outcomes:
- 25% reduction in infrastructure costs
- Zero downtime during the cloud-to-cloud migration
- Parallel-running architecture validated the portability approach end to end
Source: https://cloud.google.com/customers/hermes-germany
Company Name and Industry: Anzu, Advertising Technology
Scale Context: In-game advertising platform processing real-time bidding at scale
Challenge: Rising cloud costs, particularly data transfer, on its previous provider constrained growth economics.
Solution Implemented: Migrated the platform to AWS on Amazon EKS, redesigning for managed Kubernetes.
Measurable Outcomes:
- 50% reduction in monthly cloud costs, approximately $1 million saved in 2024, driven notably by data transfer savings
- 30% increase in daily bid requests handled
- 40% reduction in server count, delivering a 30% carbon reduction, with planning to production in 90 days
Source: https://aws.amazon.com/solutions/case-studies/anzu-case-study/
Company Name and Industry: CBI Health, Healthcare Services
Scale Context: National rehabilitation and community healthcare provider running a fragmented legacy estate
Challenge: Infrastructure split across another cloud provider, physical systems and legacy platforms, with high running costs and operational overhead.
Solution Implemented: Consolidated legacy and physical infrastructure onto AWS.
Measurable Outcomes:
- 60% cost reduction achieved, with a potential 90% identified
- 75% reduction in technology footprint
- Migration completed in 3 months, 40% faster than estimated
Source: https://aws.amazon.com/solutions/case-studies/cbi-health-case-study/
The Hermes case is the clearest architectural lesson of the three: its services were containerised and portable before the migration started, which is precisely what made parallel running and a DNS cutover with zero downtime possible. Anzu and CBI Health demonstrate that substantial, quantified savings are achievable in cloud-to-cloud and consolidation moves, but their vendor-published summaries do not decompose costs finely enough to establish whether egress, engineering effort or proprietary coupling dominated each migration, so they evidence the destination economics rather than the audit’s cost structure. The repatriation route fills that gap with first-party detail: 37signals’ published figures describe a cloud bill falling from a $3.2 million annual run rate to $1.3 million in 2024, an S3 exit moving almost 6 PB onto Pure Storage arrays with 18 PB of combined capacity, and AWS waiving what the company’s CTO described as a quarter-million-dollar egress bill under its public commitments, with the engineering substitution work, not the transfer, defining the project timeline.
Cost Analysis and ROI
Building the exit business case means separating three cost pools with different behaviours over a three to five year horizon.
The first pool is transfer and retrieval, the pool the Data Act and the free-exit programmes address. It was never as large as the headline rates suggest, because volume tiers apply: moving a representative 500 TB estate out over the internet at historical list prices would have cost roughly $28,000 to $29,000 on either AWS or Azure Zone 1 once their published tier bands (from $0.09 and $0.087 per GB at the first tier down to $0.05 per GB above 150 TB) are applied correctly, not the $45,000 a flat first-tier rate implies. All of that is now waivable in a genuine exit, leaving archive retrieval (around $2,000 at S3 Glacier standard rates for a 200 TB archived portion, more if expedited) and any cross-region consolidation transfer as the residual. This pool is small, predictable, and shrinking to near zero for EU customers by January 2027. It is worth noting that Azure Zone 2 and Zone 3 regions start at $0.12 and $0.181 per GB respectively, so estates in Asia-Pacific or South America face materially different transfer economics than the European figures suggest.
The second pool is re-engineering and re-integration, which the Act does not touch. Published accounts and analyst commentary consistently place this pool at an order of magnitude above transfer costs for estates with meaningful proprietary coupling. It behaves as a one-off capital cost, and the audit’s coupling scores are its estimating basis. The third pool is friction and overlap: stranded commitments, parallel running, and productivity loss during retraining. This pool is calendar-driven rather than volume-driven, which is why exit timing against commitment expiry dates changes the business case more than any pricing negotiation.
The return side depends on the destination, and published outcomes should calibrate scenarios rather than set expectations. Anzu’s 50 per cent monthly cost reduction and CBI Health’s 60 per cent reduction represent the favourable end of vendor-published results; 37signals projects roughly $10 million of savings over five years against a hardware investment of around $700,000 for compute plus $1.5 million for storage. For early scenario modelling, test illustrative run-rate reductions of 20, 30 and 40 per cent, then replace those assumptions with real destination quotations and pilot evidence, and calculate payback from the workload-specific audit rather than assuming an industry-standard period, because commitment stranding and parallel running can move payback by a year on their own. The optimisation alternative should always be priced alongside: where re-engineering costs exceed the plausible savings, portability refactoring in place, or a zero-egress storage hedge such as Cloudflare R2 (which charges nothing per gigabyte of egress at any volume) or Backblaze B2 for egress-heavy serving workloads, will usually beat a full exit on ROI. Validate the commercials and the compatibility at the point of decision: S3 compatibility on these platforms is close but not complete, with Object Lock support, lifecycle-to-archive tiers, event notifications and multipart ETag behaviour all differing, so budget application validation time rather than assuming a configuration-only swap.
The Decision Framework
Four thresholds convert the audit into a decision. They are practical starting points for internal decision-making, calibrated from the audit components above, not statutory tests or independently validated industry benchmarks; adjust them to your estate.
If egress exceeds 30 per cent of a workload’s bill, the problem is architectural rather than contractual: move the serving data to a zero-egress provider or restructure the delivery path now, regardless of any wider exit plans. If committed spend minimums exceed twelve months of forward runway, exit economics are dominated by stranded commitment; time any migration to commitment expiry and negotiate commitment portability at the next renewal rather than attempting an early exit. If proprietary re-engineering estimates exceed twice the annual run-rate saving, invest in portability in place: containerise, adopt PostgreSQL-compatible services at the next natural refresh, and standardise on multi-cloud infrastructure as code, a transition our Terraform to OpenTofu migration guide covers for teams also weighing the licensing dimension of their tooling. And if a workload is pure object storage behind an S3-compatible API, treat it as one of the cheapest realistic switches in the estate and use it as a live negotiating lever at every renewal, while still budgeting for the compatibility validation and transfer time a real move requires.
Choose a full provider exit only when at least two conditions hold: the run-rate saving is durable and independently verified against the destination’s real pricing, and the commitment calendar permits a move without material stranding. Choose the negotiation path, using the audit as evidence, when coupling is high but spend leverage is meaningful. Choose portability investment when the audit shows high coupling and the workload has a long remaining life. Choose to do nothing, deliberately and with the audit on file, when coupling is high, the workload is in run-down, and the saving is marginal.
Implementation Roadmap
Phase 1, Foundation (Months 1 to 3). Run the seven-component audit across the estate, starting with the ten highest-spend workloads. Build the per-workload lock-in scorecard and the commitment calendar, capturing every reservation, savings plan and enterprise agreement end date alongside contract notice periods, and check auto-renewal dates against January 2027 so no agreement rolls over into pre-Data-Act terms unexamined. Separate egress into a distinct, tagged billing line per service so it becomes a metric rather than an aggregate. Team requirement is modest: one architect and one FinOps practitioner part-time, with workload owners contributing inventory. The main cost is time; the deliverable is the audit table and scorecard.
Phase 2, Negotiation and Pilot (Months 4 to 9). Use the audit in renewal negotiations through 2026, the window in which providers are most motivated to concede terms ahead of the ban and, in the UK, while their CMA commitments are under six-month review. Insert Data Act-aligned clauses explicitly, drawing on the Commission’s draft standard contractual clauses where useful: the two-month notice cap, the 30-day transition period, the exhaustive exportable-asset list, deletion certification, and an express no-switching-fee provision effective from January 2027. In parallel, execute one real migration pilot on a workload the audit scored as translatable, using the relevant migration tooling (AWS DMS, Azure Migrate, or GCP Migration Center and Storage Transfer Service), because a pilot is the only reliable calibration of the audit’s re-engineering estimates. Budget for dual-running the pilot workload for its full validation period.
Phase 3, Maturity (Months 10 to 18). Apply the decision framework across the estate and execute the resulting portfolio: portability refactoring where it pays, zero-egress hedges for egress-heavy serving paths, timed exits where the business case cleared the thresholds, and documented deliberate inaction elsewhere. Institutionalise the audit as an annual exercise refreshed at every enterprise agreement renewal, and fold the lock-in scorecard into architecture review for new workloads so coupling becomes a priced decision at design time rather than a discovered cost at exit time.
Future Trends
Three developments will reshape this space before the decade ends. The first is enforcement taking shape: Germany’s implementation entered into force in May 2026 with the Bundesnetzagentur as enforcement authority, other Member States are following on their own timelines, and the first enforcement actions will define how aggressively the at-cost cap on parallel-use egress is policed and how “proportionate” early termination penalties are interpreted. The second is the interconnect race: AWS Interconnect’s open specification, already adopted by Google Cloud with Azure expected later in 2026, points towards commodity private multi-cloud connectivity, which erodes the network dimension of lock-in faster than regulation alone would. The third is AI gravity: model hosting, vector storage and GPU commitments are accumulating a new layer of proprietary coupling faster than the previous layer is being paid down, and generative AI services are the fastest-growing segment of the European market. An estate that scores as portable today can score as coupled in eighteen months of enthusiastic AI adoption, which is an argument for putting AI service selection through the same coupling scorecard now rather than auditing it retrospectively.
Strategic Recommendations
Run the audit now, before the negotiation window narrows. For most enterprise estates the recommendation hierarchy is clear: negotiate first, using audit evidence, because the run-up to January 2027 offers the best terms leverage the industry has seen; invest in portability second, targeting the workloads whose coupling scores and remaining life justify it; and execute full exits only where the thresholds clear, timed to the commitment calendar. Treat the free-exit programmes as real but narrow, covering the smallest of the three cost pools, and confirm the specific regime that applies to you, because EU, UK and general programme terms now differ on windows, scope and process. Treat estates carrying Microsoft licensing with particular care, since the licensing delta persists wherever the workload lands. The most common pitfall will be the mirror image of the last decade’s mistake: having spent years overweighting egress fees as a lock-in deterrent, organisations will now underweight the coupling and commitment costs that were the real barrier all along. The Data Act has made exit costs legible. Architects who quantify them will negotiate better, build more portable systems, and occasionally, with the numbers on their side, actually leave.
Useful Links
- Regulation (EU) 2023/2854 (Data Act), full text
- European Commission draft Standard Contractual Clauses for cloud computing contracts
- AWS: Free data transfer out to internet when moving off AWS
- Azure: Free egress for customers leaving Azure
- Google Cloud: Steps to exit with free data transfer
- Google Cloud: Data Transfer Essentials announcement
- CMA cloud services market investigation
- Hermes Germany customer story, Google Cloud
- Anzu case study, AWS
- CBI Health case study, AWS
