EU Data Act switching rights give customers of cloud and other data processing services a legal route out of a provider, with deadlines and, from 2027, without switching charges. The Data Act, Regulation (EU) 2023/2854, has applied for the most part since 12 September 2025. Its switching chapter targets the commercial, contractual and technical obstacles that keep customers with a provider they would otherwise leave. For storage, where the volume of data is itself an obstacle, the rules change the economics of an exit but not the physics.
This post summarizes the switching rules, explains what they do and do not solve for large data sets and sets out what makes stored data portable in practice. It is a general overview and not legal advice.
What the switching rules say
The rules apply to providers of data processing services, a term that covers infrastructure, platform and software services delivered on demand from shared, scalable resources, including storage offered as a service. A customer can switch to another provider of the same service type or move the workload to its own on-premises infrastructure. The provider must not stand in the way and must actively assist.
| Topic | What the Data Act provides | Storage reading |
|---|---|---|
| Notice period | At most two months | The clock for planning the transfer starts with the notice |
| Transition period | 30 days after the notice period, extendable where switching in that time is technically unfeasible | Large data sets are the typical case for an extension |
| Switching charges | Limited to the provider's direct costs until 12 January 2027, then abolished | Charges for moving data out on exit can no longer be a deterrent |
| Early termination | Penalties for ending a fixed term early remain permitted | Committed-term discounts still carry an exit cost |
| Functional equivalence | Infrastructure providers must take reasonable measures so the customer reaches equivalent function at the destination | Applies to basic compute, storage and network services |
| Open interfaces | Other services must offer open interfaces free of charge and support common specifications | Data export in documented, machine-readable formats |
| Transparency | Providers keep an online register of data structures, formats and interoperability specifications | A reference for what can be exported and how |
What the rules do not change
The regulation removes charges and sets deadlines. It does not make a petabyte move faster. Transfer time is governed by network bandwidth, by the request rate both systems can sustain and by the number of objects, since many small objects move far more slowly than the same volume in large ones. A data set that takes four months to copy still takes four months, and the customer pays for the destination and for running two systems in parallel during the move.
The rules also do not cover everything a customer pays to leave. Early termination penalties on fixed-term contracts remain lawful. Charges for ordinary data transfer during normal operation, as opposed to transfer for the purpose of switching, are treated separately. The concept is explained under egress fees. And the obligation to assist does not oblige the old provider to rebuild the customer's application for the new environment.
Functional equivalence and the S3 interface
For infrastructure services the Act expects that a customer can reach equivalent function after switching. For object storage, the practical basis for equivalence is the interface. Data written through the S3 API can be read and rewritten through the same API on another system, with the same bucket and key structure, without format conversion. What varies is how completely each system implements the features an application relies on: versioning, Object Lock, lifecycle rules, multipart behavior, event notifications.
That makes a feature inventory the first step of any exit plan. The post on S3-native versus S3-compatible object storage describes the differences that matter, and S3 migration covers the mechanics of the transfer, including how to preserve metadata, versions and retention settings.
Data that is easy to forget
Switching covers exportable data and digital assets, and the list is longer than the objects themselves. Object metadata and tags, access policies, lifecycle configurations, encryption keys held in the provider's key service, access logs needed for audit, and retention locks all have to be accounted for. Objects under a compliance-mode lock cannot be deleted at the source until the lock expires, so the old contract may need to run on for those objects even after everything has been copied. The post on metadata residency explains why metadata deserves its own line in the plan.
Does the Data Act apply to on-premises storage?
The switching chapter is aimed at services consumed on demand from a provider's shared resources. Storage software that an organization licenses and runs on its own hardware is not what the definition describes, and legal commentary advises providers to assess hybrid and on-premises offerings case by case. For the customer the distinction matters less than it seems, because on-premises infrastructure is named in the Act as a legitimate destination: the right to switch includes the right to bring data back in-house. The post on hybrid cloud and data sovereignty discusses how organizations divide data between the two.
Portability as a design property
A legal right to leave is only as useful as the technical ability to do so. Three design choices decide how portable stored data is. Using a standard interface keeps applications independent of one provider. Keeping data in open, documented formats keeps it readable by other tools. And holding at least one complete copy on infrastructure the organization controls means an exit never starts from zero. These are the same choices that reduce vendor lock-in in general, and the post on cloud exit planning turns them into a plan with durations and costs.
Where Scality RING fits
Scality RING is software-defined object and file storage that runs on standard x86 servers in the organization's own facilities. It exposes an S3 interface, so data moved out of an S3-based cloud service keeps its bucket and key structure, and applications address it with the same API. RING supports versioning and S3 Object Lock, which allows retention settings to be carried over for data that must stay protected.
RING scales from petabytes upward, and nodes can be added to a live system without taking the namespace offline, so capacity can grow as data arrives during a migration. It spans hardware generations without a forklift migration, which keeps the destination itself from becoming the next exit problem. Erasure coding and replication are selectable per policy, and the system can span multiple sites.
A storage portability checklist
- How long would a full copy of the data take at realistic bandwidth and request rates?
- Which S3 features do applications depend on, and does the destination support each one?
- Are metadata, policies, keys and logs included in the export plan?
- Which objects are under retention locks that outlast the planned exit date?
- Does the contract contain early termination penalties that the Data Act leaves in place?
The Data Act removes one of the commercial reasons organizations stayed where they were. The technical work of moving large volumes of data remains, and it is easiest for organizations that designed for portability before they needed it.