Cloud Exit Is No Longer Just a Contract Clause
Regulation (EU) 2023/2854—the EU Data Act—is the subject of this series, and this opening asks what its cloud-switching rules change in practice. The question matters because a customer can be entitled to leave a provider yet still be unable to restore a working service without its state, configuration, interfaces, and operating assumptions. The useful judgment is therefore not simply “Can we download our data?” but “Can we move the service, preserve what matters, and prove that the destination works?”
When “download everything” still leaves you stuck
Imagine a mid-sized distributor running order management on a cloud platform. Its records are stored there, but so are the arrangements that make those records useful: the way applications communicate, the settings that govern access, and the assumptions that keep the service available while demand changes. The distributor can receive a large export and still face a difficult reconstruction. A file can be intact while the service that reads it is absent, differently configured, or unable to produce the same result.
That gap is the practical meaning of cloud lock-in. It is not only that a provider might charge a high price to move bytes out. Dependence can sit in the contract, the data structures, the interfaces, the configuration, the supporting assets, and the continuity arrangements. It appears at the moment of change, when a customer must extract data from one environment, transform it for another, upload it, and keep the existing service dependable while the new one is tested. A migration that begins with an emergency termination is already late: the customer is asking the old environment to explain itself at the same time as they are trying to replace it.
The Data Act treats that failure as more than an unfortunate procurement outcome. It names facilitating switching between data-processing services as one of the Regulation's subjects and connects it to interoperability. Its concern is not a fantasy in which all clouds become interchangeable. It is the narrower and more consequential idea that a customer should not be blocked by obstacles that a provider can reasonably remove.
This is why “we have backups” is not the same statement as “we have an exit.” A backup answers one question about recovery of data. An exit also asks whether the customer can use that data in a different service environment, whether the relevant assets may be used there, whether the provider will supply the necessary information and assistance, and whether the service remains secure and available during the change. The Data Act does not answer every technical question for the customer. It changes which questions the provider must help answer and which obstacles cannot simply be imposed as part of the commercial relationship.
Why the EU regulates the exit path
The Regulation's stated rationale has three connected parts. First, effective switching lowers the barrier for a customer to choose a different provider. If a customer can leave without losing the practical use of their data or paying charges unrelated to the work of switching, a new provider has a better chance to compete for that customer. Second, the ability to change providers contributes to resilience. A service that cannot be moved, or cannot coexist with another service without disproportionate friction, creates a concentrated dependency. Third, interoperability lets the market compete on services rather than on the difficulty of escape.
Recital 78 describes the desired condition in operational terms: customers should be able to move between services while maintaining a minimum functionality and avoiding service downtime, or use several providers at once without undue obstacles and data-transfer costs. Recital 79 supplies the policy diagnosis. Earlier self-regulatory efforts encouraged switching practices, but uptake was limited and open standards and interfaces were generally unavailable. The Regulation therefore adds minimum obligations instead of relying only on goodwill or model contracts.
That does not make the Data Act a guarantee of a perfect clone. A new service may have different performance, security, resilience, or quality-of-service characteristics. The legal idea of switching is compatible with those differences. What matters is whether the provider has removed the obstacles within its responsibility, supplied the portable material the rules cover, and supported the customer through the change in the manner required for the service. The engineering question remains whether the customer's workload can meet its own functional and operational needs in the destination.
This distinction between a right and a capability is the central lens for the series. A right to switch is a rule about what the customer may demand and what the provider may not obstruct. An exit capability is a maintained relationship among a workload, its data, its assets, its interfaces, its contracts, and the people who operate it. The first can exist on paper while the second fails during a cutover. The Data Act matters precisely because it makes parts of that capability visible before termination: the customer must be able to learn what can be ported, how it can be exported, what restrictions are known, and what assistance and continuity commitments apply.
The scope also matters. The Regulation applies its cloud-switching rules to providers of data-processing services that serve customers in the Union, regardless of where those providers are established. “Data processing service” is a defined legal term, not a synonym for every hosted feature. The definition points to on-demand network access to a shared pool of configurable, scalable, and elastic computing resources that can be provisioned and released with minimal management effort or provider interaction. Later analysis must therefore look at what a service actually does, not just whether its marketing page calls it cloud, platform, or software.
The parties in a real switch
A switch has at least three possible participants and two possible destinations. The customer is the person or organisation with the contract to use the service. The source provider is the provider the customer is leaving. The destination provider is the provider receiving the workload. The customer may instead move to on-premises ICT infrastructure—an environment owned, rented, or leased by the customer and operated by the customer or a third party. The Regulation also recognizes that a customer may authorize another party to manage the switching work.
These names are useful because they prevent a common error: assigning every migration task to the provider being left. Switching is defined as a process that includes extracting, transforming, and uploading data. The source provider has a role in making extraction possible and in supplying a machine-readable result. The customer and destination provider generally carry the responsibility for uploading the material into the new environment, unless the customer separately obtains a professional transition service. The destination provider must also cooperate in good faith; a customer cannot turn the old provider's obligations into a promise that a competitor will accept any workload in any form.
The same division appears in the limit on source-provider responsibility. The provider's duties to remove obstacles and facilitate switching apply to the services, contracts, and commercial practices that the source provider offers. They do not require that provider to design a new category of service for a competitor's infrastructure or rebuild the customer's service inside the destination environment. The source provider can provide capabilities, information, documentation, technical support, and, where appropriate, tools. The customer still has to decide what outcome matters, authorize the move, coordinate the target, and validate the result.
Consider the distributor again. Before choosing a destination, its team needs to answer several connected questions. What is the actual service being switched, and is the proposed replacement the same service type? Which records and metadata were generated by the customer's use? Which applications or other digital assets can the customer lawfully use after leaving? Which provider-owned or third-party material is protected and therefore outside the export? What notice and transition period apply? What must remain available while the transfer occurs? Which test will show that the destination provides the required result rather than merely accepting a file?
Those questions are not a demand for an enormous document inventory. They are the minimum shape of an honest exit decision. If the customer cannot name the service, the portable surface, the destination owner, and the evidence of continuity, the phrase “portable” hides more than it explains. If the customer can name them, the remaining work becomes visible: some of it belongs to the source provider, some to the destination and customer, and some to a joint operating plan.
The first discipline is therefore to name the object, not the marketing category. A contract may say “cloud service,” while the legal analysis asks whether the offering meets the definition of a data-processing service and whether the proposed move concerns a service of the same type, an on-premises environment, or simultaneous use of multiple services. That scope decision determines which parts of the exit map apply. Before asking what must be exported or how long the transition may take, the next question is what the Data Act actually means by a cloud service—and by switching.