EU Data Act Cloud Switching: The 30-Day Exit Clock Arrives January 2027

Your contract renewal is probably the last one you will sign before the EU Data Act cloud switching rules bite. On 12 January 2027 providers lose the right to charge you anything for leaving, and your contract has to promise an exit inside 30 calendar days. Most of the teams we work with could not move a production estate in 30 days if the building were on fire. The fee ban is the easy half of the law. The clock is the half that turns a legal deadline into an engineering backlog, and there are about fifteen weeks left to work through it.

What actually changes on 12 January 2027

Article 29(1) of the Data Act is one sentence: "From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process." Today we are in the transitional window that Article 29(2) opens, running from 11 January 2024, where reduced charges are allowed but under Article 29(3) they "shall not exceed the costs incurred by the provider of data processing services that are directly linked to the switching process concerned." Read the article text rather than a vendor summary of it.

Two things sound like they are covered and are not.

The ban applies to the switching process. Your day-to-day egress bill for serving users, replicating across regions, and pulling backups to another provider for ordinary operational reasons is untouched. If you were hoping January 2027 deletes a line item from your monthly invoice, it does not.

It also does not force a provider to run your workload for you somewhere else. Article 29(5) explicitly contemplates services "that involve highly complex or costly switching or for which it is impossible to switch without significant interference in the data, digital assets or service architecture." The provider has to tell you when you are buying one. The rewrite is still yours.

The clock nobody has costed

Article 25 is where the engineering work hides. The contractual terms it mandates set a series of caps that together define your exit SLA:

| Article 25 term | Cap | What it means for you | |---|---|---| | Notice to start switching | "shall not exceed two months" | Your provider cannot stall you past 60 days | | Mandatory maximum transitional period | "30 calendar days" | The contract has to promise the move completes in a month | | Provider claims it is unfeasible | "within 14 working days of the making of the switching request" | They must say so fast, in writing, with justification | | Alternative transitional period | "shall not exceed seven months" | The escape hatch, and it is the provider's to invoke, not yours | | Data retrieval after termination | "at least 30 calendar days" | Your last window to pull anything you forgot |

Thirty calendar days, in the contract. We have never seen an enterprise estate that could do it cold. The binding constraint is almost never bandwidth. It is that nobody has an inventory of which managed services have no equivalent on the other side, and the discovery phase alone eats the month.

Here is the uncomfortable framing for a board conversation. If your contract promises a 30-day switch and your architecture needs nine months, you are not non-compliant, your provider is fine, and you have simply written down a capability you do not have. The first time anyone tests it will be during an incident, a price shock, or an acquisition.

What the three hyperscalers already give you

All three large providers moved ahead of the deadline in early 2024, and all three attached conditions that survive into 2026. We checked each programme against the vendor's own page while writing this.

| Provider | Programme | The condition people miss | |---|---|---| | AWS | Free data transfer out when moving off AWS, announced 5 March 2024 | A 30 September 2025 update to that post states "Eligible customers will have 90 days to complete their move off of AWS." You open a support case first. | | Azure | Free egress for customers leaving, on the bandwidth pricing page | Claimed as a credit above the standard 100 GB monthly free tier, and only for data leaving to another provider or to your own data centre | | Google Cloud | Data Transfer Essentials, "initially offered at no charge when used according to the guidance provided in the documentation" | It is for multicloud, not exit. It "doesn't extend to applications that serve end users" on other providers, and that traffic bills at default rates. |

Credit where it is due to AWS on one point: the blog is explicit that "We don't require you to close your account or change your relationship with AWS in any way." That matters for partial exits, which is what most real migrations are.

The pattern across all three is the same. The money is waived, the process is gated behind a support ticket, and the window is measured in weeks. None of that is a problem if you have rehearsed. All of it is a problem if your first contact with the programme is the week you decide to leave.

The egress bill was never the lock-in

Run the arithmetic before you let the fee ban into a business case. Take a 50 TB one-time export out of Azure from a North America or Europe region, using 1 TB = 1,000 GB and the tiers published on the bandwidth pricing page: the first 100 GB is free, the next 10,000 GB bills at $0.087 per GB for $870, and the remaining 39,900 GB bills at $0.083 per GB for $3,311.70. Total: roughly $4,182.

Four thousand dollars. That is not what has kept anyone on a cloud provider. What keeps them is the sixty places where their application calls a managed service that has no equivalent next door, and the eighteen months of engineering to replace them. The Data Act removes a toll booth from a road you have not built.

So treat 12 January 2027 as a forcing function for portability work you were going to defer, not as a discount. The teams who benefit are the ones who use the deadline to get a real number for their exit cost. The teams who do not will discover in 2028 that the fees went away and nothing else did.

An exit-readiness test you can run this week

Start with what you would actually have to move. The commands below are real; the bucket name is fake.

# Illustrative: substitute your own bucket and account details.
# How much S3 data would a switch have to carry?
aws cloudwatch get-metric-statistics \
  --namespace AWS/S3 \
  --metric-name BucketSizeBytes \
  --dimensions Name=BucketName,Value=acme-prod-data \
               Name=StorageType,Value=StandardStorage \
  --start-time 2026-09-18T00:00:00Z \
  --end-time 2026-09-25T00:00:00Z \
  --period 86400 \
  --statistics Maximum

# Which managed services have no drop-in equivalent elsewhere?
terraform state list \
  | grep -E 'aws_(dynamodb|kinesis|sqs|sns|glue|athena|redshift|elasticache|opensearch|sfn)_'

That second command is the one that generates the real conversation. Every line it prints is either a service with a portable equivalent, a service with a painful equivalent, or a rewrite. Sort them into those three buckets and you have an exit cost estimate that a CFO can read, which is more than most organisations have today.

Then do the part everyone skips: pick one non-critical service and actually move it. A week of one engineer's time on a real cutover tells you more about your 30-day claim than a quarter of architecture review. It also surfaces the things no inventory catches, like the IAM trust relationships and the DNS TTLs nobody has touched since 2021. If your Terraform is the kind that makes this hard, our notes on managing Terraform at scale across multi-cloud cover the state decomposition that has to come first.

The contract clauses to fix at your next renewal

The second half of 2026 is the strongest negotiating position you will ever have on this, because the provider knows the charges disappear anyway in January. Ask for the concession now and it costs them a few months of revenue they were losing regardless.

Four asks follow, in order of how often we see them refused.

Write the Article 25 exit terms into the contract explicitly rather than relying on the statute to imply them. A named process with a named contact beats a legal right you have to enforce during an outage.

Get the Article 29(4) pre-contract disclosure in writing. The provider has to give you "clear information on the standard service fees and early termination penalties that might be imposed," and under Article 29(6) publish it "via a dedicated section of their website." Ask for the link during procurement and keep a copy.

Require the Article 29(5) complexity notice per service, not per contract. You want to know which specific components your provider considers hard to switch, because that list is their own assessment of where you are locked in.

Cap the seven-month alternative transitional period contractually at something shorter. It is the provider's escape hatch and the statute sets only an upper bound.

For the broader question of whether a second provider is worth running at all, we set out the cost and complexity trade-offs in the CTO's guide to multi-cloud architecture. The Data Act changes the price of leaving. It does not change the maths on whether you should.

What we would do with the next fifteen weeks

Do not try to become portable by January. Try to become honest by January.

| Weeks | Work | Output | |---|---|---| | 1 to 3 | Inventory managed-service dependencies per workload | A three-bucket list: portable, painful, rewrite | | 4 to 6 | Size the data and measure real transfer throughput | Hours to move each dataset, not terabytes | | 7 to 10 | Rehearse one non-critical service cutover end to end | A tested runbook and a list of surprises | | 11 to 13 | Redline the Article 25 and 29 terms for renewal | Contract asks agreed while the provider still has something to concede | | 14 to 15 | Write the exit cost into the risk register | A board-legible number and an owner |

The deliverable at the end is not a migration. It is a defensible answer to the question "how long would it take us to leave, and what would it cost," backed by one rehearsal rather than one spreadsheet. Once you have a number, it belongs in the same conversation as the rest of your cloud economics, which we cover in building a FinOps practice.

Our view, stated plainly: most organisations should not switch providers in 2027. They should spend 2026 getting to the point where switching is a decision rather than a fantasy, and then carry that credibility into every renewal for the next decade. A provider who believes you could leave writes you better terms than one who knows you cannot.

When to Get Help

If you have a renewal landing between now and January, or a board that has started asking what the Data Act means for your contracts, the inventory and rehearsal work above is a four to six week engagement rather than a programme. We have run cloud exit assessments for teams who needed a number for a risk register and for teams who genuinely intended to move, and the first three weeks look identical either way.

Talk to us about a cloud exit readiness assessment and we will tell you within a call whether your 30-day clause is credible.