What the Data Act Means by a Cloud Service—and by Switching
This chapter defines the legal object behind the EU Data Act's cloud-switching rules. It asks two practical questions: what kind of service is being left, and who controls each step when a customer changes provider or moves to an on-premises environment? The payoff is a classification model that lets a customer read an exit commitment against the service they actually use, rather than against a reassuring label such as “cloud,” “platform,” or “SaaS.”
The legal object is a service with a particular operating model
The Data Act calls the regulated object a data processing service. In Article 2, that means a digital service provided to a customer that gives ubiquitous, on-demand network access to a shared pool of computing resources. Those resources must be configurable, scalable, and elastic; they must be capable of being provisioned and released rapidly, with minimal management effort or interaction from the provider.
Each part of that definition does practical work. “On-demand” points to a customer that can provision capacity through the network rather than negotiate every allocation manually. “Configurable” means the customer selects or changes aspects of the resources. “Scalable” means the provider can allocate more or fewer resources as demand changes. “Elastic” adds the ability to provision and release those resources according to changing demand. The resources may be centralized, distributed across networked systems, or highly distributed near where data is generated. The definition therefore reaches beyond a room full of rented servers.
The Regulation's recitals describe a broad family of services. Infrastructure as a Service, or IaaS, packages infrastructure such as servers, networks, storage, and virtual resources. Platform as a Service, or PaaS, can add development tools and managed runtime capabilities. Software as a Service, or SaaS, can provide applications and other services through the same on-demand model. Storage as a Service and Database as a Service are examples of more granular variants. The point is not to force every offering into one of three marketing boxes. It is to recognize a service that gives a customer access to a shared, rapidly adjustable pool of computing capability.
That functional test matters because a provider may describe a product in a way that conceals what the customer controls. A managed database may be marketed as an application feature, while its actual service gives a customer on-demand access to elastic storage and processing resources. Conversely, a hosted application that a person merely uses to listen to music or view a video may involve cloud infrastructure without making that person a customer using the data-processing service as such. The FAQ gives this distinction as an interpretive explanation, not as binding law; the definition in the Regulation and the facts of the relationship remain decisive.
The second important term is same service type. Article 2 describes this as a set of data-processing services that share a primary objective, a service model, and main functionalities. It is a narrower comparison than “both products run in the cloud,” but it is also more flexible than “both products have the same performance.” The Regulation recognizes that services of the same type may differ in performance, security, resilience, and quality of service. Those differences are part of what a customer must evaluate; they do not by themselves erase the possibility of switching.
Consider a company using a managed database to support its order system. A destination provider's managed database may serve the same primary objective and belong to the same service model, yet expose different backup behaviour or query performance. The customer may still be comparing services of the same general type, but the migration test cannot stop at whether the rows arrived. It must ask whether the shared functions the customer relied on produce materially acceptable outcomes in the new environment. By contrast, moving from a managed database to a raw virtual machine may be a valid business choice, but it changes the amount of work the customer takes on. The fact that both offerings are sold by cloud companies does not decide the classification or the engineering consequence.
The definition also tells us what the Data Act is not doing. It is not declaring every cloud product identical. It is not giving a customer a general right to demand the provider's internal technology or a competitor's proprietary service. It supplies a framework for removing obstacles to a change between relevant services, while leaving service design, performance choices, and much of the destination work to the parties that control them.
The customer is likewise a defined role: a natural or legal person that has entered into a contractual relationship with a provider to use one or more data-processing services. That contractual relationship is the anchor for the switching rights and duties. A casual end user may benefit from a cloud-backed application without being the customer who can invoke the provider-facing switching process. An enterprise that contracts for the underlying service is in a different position. In a real procurement review, identifying the contracting entity and the service actually purchased is therefore an early control, not legal housekeeping.
Switching is a relationship among actors, not a button
The Data Act defines switching as a process involving a source provider, a customer, and, where relevant, a destination provider. The customer changes from one data-processing service to another service of the same type, moves to an on-premises ICT infrastructure, or otherwise changes the provider relationship in a way that includes extracting, transforming, and uploading data. The definition captures a sequence of work rather than a single export event.
The source provider is the provider the customer is leaving. The destination provider is the provider whose service will receive the workload. The destination can also be the customer's own on-premises infrastructure, owned, rented, or leased and operated by the customer or by a third party. A customer may authorize another organization to manage the switch. These roles matter because control of the work is divided. The source has the data and the mechanisms that expose it. The customer owns the business decision and the acceptance criteria. The destination controls the environment into which the material must be restored.
Extraction is the movement of data out of the source environment. Transformation changes the structure or schema so that the material can be used at the target. Upload places it in the destination. Recital 85 makes the responsibility boundary unusually clear: the source provider is responsible for extracting data into a machine-readable format, while the customer and destination provider generally upload it to the new environment, unless the customer has obtained a separate professional transition service. This does not mean that transformation is always a simple customer script. It means that the law does not silently assign the destination rebuild to the source provider.
The distinction becomes important when a customer assumes that a provider's exit assistance includes recreating the complete application. Article 24 limits the technical responsibilities in Articles 23, 25, 29, 30, and 34 to the source provider's own services, contracts, and commercial practices. Recital 92 explains the consequence: the source provider does not have access to, or insight into, the destination provider's environment. The source must take reasonable measures within its power—such as providing capabilities, information, documentation, technical support, and appropriate tools—but need not develop a new category of service on the other provider's infrastructure or rebuild the service there.
That boundary is not an excuse for either side to disengage. Article 27 requires all parties involved, including the destination provider, to cooperate in good faith to make switching effective, transfer data on time, and maintain service continuity. The source provider's responsibility is to make the exit surface and the source-side process usable. The destination provider's responsibility is not to accept anything without question, but to participate in a process that can result in a timely and effective transfer. The customer's responsibility is to state what the service must do after the move and to coordinate the work that neither provider can infer.
The diagram shows a relationship that is easy to lose in ordinary cloud discussions. The customer does not simply hand a workload from one provider to another. They are the link between the source and destination, and they may choose an on-premises destination instead. The thing moving is not a provider's entire platform. It is the exportable material and any digital assets the customer has the right to use, carried through a process that must be coordinated with the service's ongoing operation.
A second distinction is essential: switching is not the same as in-parallel use. If the customer ends the source relationship and moves to another service, the event is a switch. If the customer retains the source service and asks another provider to operate a complementary service at the same time, the arrangement is in-parallel use. A customer can use parallel operation as part of a staged migration, but the legal and operational states are not identical. A migration that temporarily runs old and new environments together may eventually become a switch; until then, it has an ongoing interoperability and data-movement problem.
The Data Act expressly addresses both situations. Article 23 requires providers to remove obstacles that inhibit switching, porting, functional equivalence where relevant, and technically feasible unbundling. Its opening also recognizes using several providers at the same time. Article 34 then applies selected switching and interoperability requirements to in-parallel use. The difference affects cost as well as architecture: continuing data egress between parallel services can be an ongoing activity, unlike the one-off transfer expected in a switch. The later analysis of charges must therefore ask which state the customer is actually operating in, not apply the word “migration” to every data transfer.
A practical classification exercise can now be stated without pretending that it resolves every borderline case. First identify the contracting customer and the provider-facing service. Then describe the resources the service exposes, how they are provisioned, and what the service is primarily for. Next identify the proposed destination: another provider's service of the same type, a different service that changes the customer's operating model, or on-premises infrastructure. Finally state whether the source contract is ending, remaining in parallel, or being unbundled. Each answer changes the questions that follow about portable data, digital assets, interfaces, functional outcomes, and charges.
Suppose the order company keeps its managed database with the source provider but moves its analytics workload to a second provider. That is not automatically a complete switch of the database service. It may be in-parallel use, and its success will depend on what data must cross the boundary continuously and whether the two services can use the data consistently. If the company later terminates the source database contract and restores the database elsewhere, the extraction, transformation, upload, continuity, and validation sequence becomes the central switch. The same organizations may participate in both arrangements, but the trigger and the evidence of success differ.
The source-provider boundary also prevents a different mistake: assuming that “same service type” means “same user experience.” A destination can offer the same broad service model while requiring a different application configuration or a different operational response. The Data Act's switching framework is designed to lower the obstacles to making that comparison and carrying out the move. It does not eliminate the customer's need to decide whether the destination meets its business and technical requirements.
That is why classification is the first engineering control. If a team begins by copying a provider's product name into a migration plan, it may overlook who has the contract, which resource is actually being purchased, whether the target is comparable, and whether the customer is switching or merely adding a second service. If it begins with the service's operating model and the parties' control, the next questions become concrete: what material belongs to the customer, what can be exported, which rights travel with it, and what time-bound process must keep the service safe while the destination is proven.
The word “cloud” is therefore only an entry point. The Data Act's real object is a defined relationship with a data-processing service, and switching is a coordinated change in that relationship. Once the parties and the service type are named, the portability question can be made precise. The next step is to separate the data and digital assets that can support a new environment from the provider material that the law and the contract do not turn into customer property.