What Actually Leaves the Cloud?
This chapter follows the EU Data Act's portable surface and exit clock. It asks what a customer can carry from a data-processing service, what the provider may legitimately withhold, and how notice, transition, retrieval, continuity, and erasure fit together. The practical result is a rights-aware inventory and a timeline that can be tested before a customer begins a high-pressure migration.
The portable surface is larger than a database export
The Data Act uses two related but different ideas: exportable data and digital assets. Treating them as one bucket creates two opposite errors. A customer may ask for too little and lose the material needed to make a new environment useful, or ask for everything and mistake provider-owned or protected material for something the law requires to be transferred.
For the switching provisions, exportable data includes the input and output data generated by the customer's use of the service, together with metadata directly or indirectly generated or co-generated by that use. This is a meaningful minimum. It reaches beyond the visible records in an application to the information needed to interpret what went in and what came out. It does not, however, turn the provider's entire service into customer data.
A useful inventory begins by asking how the customer uses the service. Which data does the customer submit? Which data does the service return? Which metadata is generated as part of that use and helps describe or operate those inputs and outputs? The answer should be recorded by category and by intended use at the destination, not as an assumption that every object stored in the provider's systems belongs in the export.
Digital assets answer a different question: what elements in digital form can the customer use independently of the contract with the provider they are leaving? The legal definition includes applications for which the customer has that independent right of use. The Regulation's recital gives a wider practical picture, including configuration metadata, information about security and access or control rights, and manifestations of virtualization technologies such as virtual machines and containers. Those assets can be essential to using the customer's data and applications after the move.
The phrase “right of use” is the control point. A customer may have uploaded an application without owning the licence needed to run it elsewhere. A configuration may describe a provider-specific service rather than an asset the customer can lawfully take. A virtual machine image may be useful only if its operating system, software, and associated rights permit deployment in the destination. These are not merely technical questions. The inventory must connect each asset to the customer's legal right to use it after leaving.
That distinction changes how a team evaluates a proposed export. The data inventory might say that order records and the metadata needed to interpret them are available. The digital-asset inventory might separately identify an application, a set of customer-controlled deployment artifacts, and configuration or access information. It should also say what is absent, why it is absent, and whether the absence requires redesign. A file list without those relationships can be complete in volume and incomplete in meaning.
The law also draws boundaries around material that cannot simply be demanded. Exportable data excludes assets or data protected by the intellectual-property rights or trade secrets of the provider or a third party. Recital 82 adds service-integrity and security concerns: data related to the integrity and security of a service may be excluded where export would expose the provider to cybersecurity vulnerabilities. But the same recital makes an important qualification. An exemption must not impede or delay the switching process.
That balance rejects two simplistic positions. “Everything is portable” ignores the rights and security of other parties. “Anything internal is secret” would let a provider hide the customer's practical exit surface behind an undefined internal category. Article 25 therefore requires the written contract to specify, exhaustively, the categories of data and digital assets that can be ported, including at least all exportable data, and to identify categories tied to the provider's internal functioning that are exempted because of a risk to trade secrets. The exemption is a boundary to manage, not a blank cheque to make the exit unknowable.
Personal data introduces another boundary. The Data Act covers personal and non-personal data, but it does not displace the General Data Protection Regulation or privacy and confidentiality rules. Where there is a conflict, the applicable data-protection or privacy law prevails. A customer cannot use a switching request as a substitute for a lawful basis, proper access controls, or a reasoned decision about which individuals' data can be transferred. At the same time, privacy cannot be used as a general reason to avoid defining the portable surface. The migration design must classify the data, minimize what moves, protect it in transit and at rest, and document the legal basis and safeguards relevant to the actual workload.
The supplied FAQ explains these distinctions, but it expressly says that it is non-authoritative and cannot add to the legislation. The controlling source for the export boundary is the Regulation itself. The FAQ is useful for examples such as configurations, access-control material, virtual machines, and containers; it does not decide whether a particular customer's asset is protected, licensed, personal, or portable. That decision depends on the asset and the relationship in front of the team.
The exit has a clock—and a clean-up state
A portable inventory is only useful if it is connected to a sequence of actions. Under the Data Act, the contract must state the customer's switching rights and the provider's obligations in writing and in a form the customer can store and reproduce. The provider must make that contract available before signing. The contract is therefore not only evidence of a right that might be argued about later. It is part of the operating description of the exit.
The sequence starts when the customer tells the source provider what they intend to do. The maximum notice period for initiating the switch is two months. During that period the service contract remains applicable. The customer may notify the provider that they will switch to another provider, move to on-premises infrastructure, or erase their exportable data and digital assets when the service ends.
After the notice period comes the transition period. The ordinary maximum is 30 calendar days. During it, the source provider must provide reasonable assistance, act with due care to maintain business continuity, explain known continuity risks, and maintain a high level of security, including while data are transferred and later retrieved. The customer and destination provider still have to perform the work that belongs to them. The source provider is not required to recreate the destination environment, but the source-side service cannot simply become unavailable because the customer has started to leave.
The 30-day period is a default ceiling, not a claim that every migration fits comfortably inside 30 days. The Regulation recognizes technical unfeasibility, but places the burden on the source provider. If the provider cannot complete the mandatory maximum transitional period, it must notify the customer, duly justify the problem, and indicate an alternative period of no more than seven months. The notification must be made within 14 working days of the switching request. The customer also has a one-time right to replace the 30-day period with a longer period they consider more appropriate for their purposes. An agreed alternative does not remove the continuity obligation.
That structure creates a useful operational test. A provider cannot wait until the end of the transition to explain that the workload was unusually complex. The customer needs enough information before initiating the move to decide whether the ordinary period is realistic, whether a longer customer-chosen period is necessary, and which evidence will show that the transition is complete. The provider's later claim of technical unfeasibility must be specific and timely. It is not a general permission to keep the customer indefinitely.
The end of the transition is not the end of the customer's control over the material. The contract must guarantee a minimum retrieval period of at least 30 calendar days beginning after the agreed transitional period ends. That window allows the customer to retrieve the remaining exportable data and digital assets after the service contract has been terminated or the switching work is otherwise complete. The contract must also guarantee full erasure of exportable data and digital assets generated directly by, or relating directly to, the customer after the retrieval period—or after a later alternative period agreed with the provider—provided the switching process has been completed successfully.
Erasure is therefore a state with a condition, not an automatic deletion button. The customer should first establish that the destination or on-premises environment has received and validated what it needs. Only then does the contract's post-retrieval erasure commitment become the safe final state. This protects against two opposite failures: leaving unnecessary copies indefinitely, and allowing the source environment to erase the only usable copy before the customer has demonstrated a working destination.
The provider's information duties make this lifecycle observable before the request is made. Article 26 requires information about available switching and porting procedures, methods and formats, and known restrictions and technical limitations. It also requires a reference to an up-to-date online register describing the data structures and formats in which exportable data are available, together with relevant standards and open interoperability specifications. A customer should be able to use that information to plan an export and identify a test target without first discovering the provider's format at the point of failure.
The contract must also support the customer's exit strategy with relevant information and specify the categories that can be ported. Those requirements turn several routine procurement questions into evidence: Can the provider state what leaves? Can the customer reproduce the export in a usable format? Can the parties identify known limits before the notice clock starts? Can they explain which data or assets are excluded and why? Can the destination provider validate the material during the transition rather than after the source has disappeared?
Consider an order system whose customer has exported records but not yet proven the destination. During the transition, the source provider's obligations help keep the old service running and make the known export procedure available. The customer and destination provider transform and upload the material, then test the destination against the required business functions. If the test fails, the retrieval window and continuity duties matter because they preserve time to diagnose the failure. If the test succeeds, the customer can complete the switch and move toward erasure under the agreed terms. The sequence is safer because each state has an observable signal: request, supported export, destination validation, successful completion, and retrieval/erasure.
This is also why an exit rehearsal should not wait for a termination notice. The rehearsal can expose a missing data category, an unusable format, an application whose right of use does not travel, or a transition period that is too short for the workload. Those findings belong in the contract and the operating plan while the customer still has bargaining power and the source service is stable.
The resulting model is compact but not simplistic. A credible exit description has a portable surface—data, metadata, and right-of-use digital assets, with explicit exclusions—and an exit clock—notice, transition, retrieval, continuity, security, successful completion, and erasure. It also has an ownership boundary: the source provider enables and supports the source-side process, while the customer and destination provider make the new environment usable and prove the result. The next judgment is not whether every cloud workload fits the same schedule. It is whether this particular service's surface, clock, and responsibilities are complete enough to form a defensible exit map.