Data Act: switching clouds becomes a right

July 16, 2026 · 4 min read · SOVALYX Technologies

Since 12 September 2025, the European Data Act has applied — and with it a new principle: switching cloud providers is no longer just a clause to fight for in negotiation, it is a regulated right. Migration assistance, phased removal of transfer and exit fees, contractual requirements: the balance of power between customer and provider is shifting. Provided you know how to use it — and have an architecture able to follow.

What the Data Act requires from cloud providers

The Data Act is a broad text on data sharing and access, but its most concrete chapter for an IT department concerns switching between data processing services — in practice, the cloud. Three obligations structure it:

• Migration assistance. The outgoing provider must cooperate and assist its customer in transferring to another provider or to the customer's own infrastructure, instead of leaving the customer alone with its exports.
• Phased removal of transfer and exit fees. Charges billed for leaving a provider — including the notorious egress fees on outbound data — are set to disappear progressively. The cost of leaving stops being a retention instrument.
• Contractual requirements. Contracts must address the terms of switching in black and white: procedures, reasonable timeframes, formats, what is returned and how. The topic moves out of the technical annex and into the contract itself.

A necessary note: this article is an information summary, not legal advice. The exact scope of the obligations under your contract and provider should be confirmed with your advisors.

The end of exit fees: a commercial lock is removed

Exit fees have long been the cloud's most effective lock-in device: barely visible at signature, they turned any thought of leaving into a deterrent budget line — especially for volumes accumulated over the years. Their scheduled removal changes three things:

• Costing a departure becomes honest. Comparing "stay" versus "leave" finally happens on real migration costs, not on a toll penalty. Our FinOps analyses show how much these fees used to distort the trade-offs.
• The threat of leaving becomes credible again. A customer who can genuinely leave negotiates renewals differently — pricing, service commitments, data location.
• Fallback scenarios become fundable. Repatriating part of your workloads, as described in our article on cloud repatriation, or moving to a private cloud, is no longer weighed down by the cost of extracting your own data.

What the law does not do: your architecture remains your problem

The Data Act removes commercial and contractual obstacles. It does not make your applications portable. Three forms of stickiness survive any regulation:

• Proprietary managed services. An application built on provider-specific services — in-house managed databases, proprietary serverless functions, exclusive queuing systems — must be partly rewritten before it can move, whatever the legal framework says.
• Formats and data. An export in a format unusable elsewhere is a paper restitution. Real portability demands open, documented formats, for data and configuration alike.
• Operational knowledge. Migrating without an up-to-date inventory, without infrastructure described as code and without restore tests means discovering your dependencies at the worst possible moment.

In other words: the regulation gives you the right to leave, the architecture gives you the ability. The two are separate workstreams, and the second one takes longer.

In practice: negotiate now, architect continuously

On the contract side, the text provides immediate leverage:

• reread existing cloud contracts in light of the new requirements: switching clauses, exit fees, assistance provided, restitution formats;
• put the topic on the table at every renewal — the moment the provider wants to keep you is when reversibility negotiates best;
• require a reversibility plan annexed to the contract: scope returned, formats, assistance, and the data deletion procedure at the outgoing provider.

On the architecture side, the principles are well known: favour standard technologies (containers, open orchestrators, widely used databases), describe infrastructure as code, keep backups in formats restorable elsewhere, and above all test reversibility the way you test a disaster recovery plan: an exit plan never exercised is a hypothesis, not an insurance policy. That is the philosophy SOVALYX applies on its private cloud: the exit is prepared at the entrance.

Reversibility checklist: where do you stand?

• Our cloud contracts have been reread since the Data Act became applicable.
• Exit fees and restitution terms are identified contract by contract.
• A written reversibility plan exists for every critical provider.
• Restitution formats (data, configurations, logs) are usable outside the provider.
• Dependencies on proprietary managed services are mapped and classified.
• Infrastructure is described as code, versioned and replayable elsewhere.
• A representative extraction has been tested, timed and documented.
• Data deletion at the outgoing provider is contractual and verifiable.
• The fallback scenario (another provider, private cloud, hybrid) is costed and kept up to date.

The Data Act rebalances the negotiation; portability, however, has to be built. If your exit plan rests on an intention, a conversation with an architect can turn it into a tested procedure — before you need it.

🧰 The companion tool: Are you ready for the AI Act? — free · 2 minutes.

Reviewed and optimised by AI.