Switching cloud providers in the EU: what is known and what to check

The European Union’s Data Act includes measures intended to make it easier for users to switch cloud service providers or use several services. The European Commission says that the law began to apply in the EU on 12 September 2025 and provides for the possibility of switching between cloud providers. This is a relevant starting point, but it is not a guarantee of an automatic migration, a migration without costs, or one without interruptions. Those are separate practical questions that cannot be answered just by pointing to the existence of the law.

The documentation gathered for this guide does not substantiate a new announcement, an additional date on which the law enters into force, or an independent assessment of how these obligations are being implemented in practice. The subject is therefore presented as a cautious explanation of a framework that is already applicable, not as a newly announced development. The distinction matters: a law can establish rights and duties, while its implementation also depends on the services concerned, the contracts in place and the procedures available to users. The formal framework and the experience of carrying out a particular migration are not identical.

Nor should this topic be confused with a general explanation of what cloud computing is. The question here is more specific: what legal and technical tools may help transfer data and applications from one provider to another, and what still needs to be checked in each individual case. The existence of a European rule does not, by itself, show that a workload is fully portable or that switching will be straightforward. A user still needs to establish what the service actually makes available and what moving it would involve.

The Commission describes the Data Act as a regulation that establishes rules for switching and portability between data-processing services, with interoperability as a central element. In a publication about an interoperability study, it says that Article 35 of the law concerns open and harmonised standards and specifications. According to that explanation, these should make it easier for services of the same type to work together and for data and applications to be transferred without compromising security. The stated aim is interoperability between comparable kinds of services, not a general assurance that every product can be substituted for every other product.

The study published by the Commission on 23 February 2026 has a specific purpose: to help establish a Union repository and prepare an initial set of open specifications and harmonised standards that meet the requirements of the Data Act. The Commission also explains that it may adopt common specifications through implementing acts if standards are insufficient, and may ask European standardisation organisations to develop standards to address gaps. These are described as ways to support the development of the framework, rather than as evidence that all technical questions have already been resolved.

This places interoperability within technical and regulatory work that is still being developed, not within a promise of universal compatibility that has already been fulfilled. The material consulted does not identify which specific specifications have already been adopted, which services are covered by each one, or what detailed timetable each provider must follow. It is important to distinguish the confirmed legal framework from the status of each technical mechanism. A broad policy objective should not be read as proof that every service has already implemented the same switching process.

The official information cited confirms the aim of facilitating switching and portability, but it is not enough to establish a cost figure, a uniform migration timetable or a single process that applies to every service. Nor does it support a claim that all data, applications, configurations or software dependencies can be transferred without modification. Those details may vary according to the type of service and the architecture being used. A migration plan therefore needs to be based on the actual service, rather than an assumption drawn from the general term “cloud”.

The term “cloud” covers services with different functions. A ready-to-use application, a platform for deploying software and a computing infrastructure do not necessarily provide the same export or replacement options. The Commission’s description refers to data-processing services and interoperability between services of the same type; it should not be interpreted as proof that products in different categories are interchangeable. A move between two comparable services may raise different questions from a move between services built for different roles.

We have also been unable to verify, from the sources gathered, the details of legal exceptions, the application of possible charges at each stage, or the consequences of a particular contractual clause. It would not be responsible to turn those gaps into a general statement about what a provider may charge or refuse. To make a decision, users need to consult the applicable text of the law, the contract currently in force and the technical documentation for the specific service. Without those checks, a general claim about an individual migration would go beyond what the available information supports.

For a business or an individual user, the first practical check is to identify what is to be moved and in what form it can be exported. A copy of files does not necessarily include databases, permissions, logs, backups, configurations or the relationships between components. Data portability and the ability to run an application in another environment are related, but they are not the same thing. It is useful to consider separately what can be extracted and whether the destination can use it as intended.

Before starting the process, it is worth asking the provider for specific information in writing. An initial checklist can include the following points. It is a way to frame questions about the individual service, not a claim that the same answers or procedure apply to every provider:

• Which data and components can be exported, in what formats and using which tools.
• What costs, time limits, volume limits and access conditions are set by the contract.
• Which technical dependencies or proprietary features could require changes in the destination service.
• How data integrity, security and continuity will be checked during the transfer.
• What steps allow the previous service to be closed and any copies that remain there to be managed, subject to applicable obligations.

The Commission presents interoperability as a way for services of the same type to work together and to make software and data more portable without reducing security. That wording describes the regulatory objective. It does not, by itself, provide test results for specific providers, metrics on successful migrations or independent evidence of the level of compliance across the market. The distinction between an objective and evidence of its implementation is important when assessing what a particular user can expect.

In the available research, the European study is an institutional source on the development of standards and specifications. There are also independent legal analyses of the switching framework and provider commentary on cloud services, but no verifiable data on real-world deployments are provided here that would establish how every migration is handled. This limitation matters: the intention of the law should not be confused with a documented user experience for every provider. General commentary cannot substitute for service-specific information about the steps a customer would actually take.

The useful conclusion is limited. The EU has a framework that covers switching between data-processing service providers, and the Commission identifies interoperability as a central part of it. To find out what a particular user can do—and at what cost, within what time, or with what risk—it is necessary to check the service, the contract and the technical specifications that apply to it. Until that evidence is available, it is more accurate to speak of regulatory rights and objectives than to promise an easy or friction-free exit.