Cloud computing has become the operational backbone of modern business, and the dependency it creates — on specific providers, proprietary data formats, and platform-specific configurations — has become one of the most contested issues in technology regulation. The EU Data Act addresses this dependency head-on in Chapter VI, which establishes a comprehensive set of obligations designed to ensure that cloud customers can move their data, workloads, and configurations from one provider to another without suffering disproportionate loss of functionality, excessive cost, or artificial delay.

For US cloud providers serving European customers, Chapter VI is among the most operationally significant parts of the Data Act. It goes beyond privacy or data governance and into the core commercial architecture of how cloud services are built and sold. It affects product design, contract language, pricing structures, technical standards, and the documentation that providers must maintain. This article explains what Chapter VI requires, what ‘switching’ actually means under the Act, what the functional equivalence and technical export obligations entail, and what US cloud providers must do to bring their EU offerings into compliance.

The Policy Problem Chapter VI Is Solving

To understand Chapter VI, it helps to understand the problem it is designed to solve. Cloud provider lock-in is a well-documented market structure issue. Once a customer has migrated workloads to a cloud platform, the practical cost of moving to a competitor — in terms of technical effort, data egress fees, retraining staff, rebuilding configurations, and accepting a period of reduced functionality — is often prohibitive. This creates a situation where cloud providers can raise prices, reduce service quality, or impose contractual terms that customers would not accept in a competitive market, simply because switching is too expensive.

The European Commission concluded that this lock-in dynamic distorts competition in cloud markets and undermines the broader EU data economy. If businesses cannot move their data and workloads efficiently, they cannot take advantage of competition between cloud providers. If they cannot export their data in usable formats, they cannot build on top of it with services from multiple providers. Chapter VI is the legislative response to these concerns: a set of rules designed to make switching real, not theoretical.

What ‘Switching’ Means Under the Data Act

The term ‘switching’ under Chapter VI is broader than it might initially appear. It covers the full range of scenarios in which a cloud customer moves from one provider or deployment model to another. This includes moving from one public cloud provider to a different public cloud provider (for example, migrating from a US hyperscaler to a European alternative). It includes moving from a public cloud environment to an on-premises infrastructure. It includes moving from one managed service offering to another. And it includes multi-cloud architectures, where a customer wants to distribute workloads across multiple providers.

The Act does not define switching narrowly as a full, wholesale migration of all workloads and data. A customer who wants to move a particular service, dataset, or application from one provider to another is engaged in switching within the meaning of Chapter VI, even if the rest of their cloud footprint stays with the original provider. This is an important point for providers who might otherwise argue that partial migrations are not covered by the switching obligations.

The Act’s switching framework applies to providers of ‘cloud computing services’ as defined in the EU’s cybersecurity framework (ENISA’s cloud taxonomy), which covers infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). All three categories are subject to the Chapter VI obligations, although the practical implementation will differ across service types because what a customer needs to ‘take with them’ varies significantly between an IaaS customer migrating virtual machines and a SaaS customer migrating application data and user configurations.

The Functional Equivalence Requirement

The centerpiece of Chapter VI’s switching framework is the requirement that a customer must be able to resume operations at the new provider without material degradation in functionality. This is sometimes described as the ‘functional equivalence’ requirement, and it is significantly more demanding than a simple obligation to export data.

Functional equivalence means that the combination of data export, configuration documentation, and technical assistance that the outgoing provider supplies must be sufficient to allow the customer to rebuild their operational environment at the new provider to a level that is functionally equivalent to what they had before. It does not require the new provider to be identical to the old one — different providers will have different architectures, different management interfaces, and different proprietary features. What it does require is that the customer is not left stranded: they must be able to rebuild a functioning equivalent.

For cloud providers, the functional equivalence requirement means that data export alone is not sufficient. If a customer’s workload depends on specific configurations, security policies, access controls, network topologies, automation scripts, or integration settings, the provider must supply that information in a form that allows the customer to recreate it elsewhere. Simply providing a data dump is not enough if the metadata, schema, configuration state, and operational parameters are left behind.

Technical Requirements for Data Export

Chapter VI places specific technical requirements on data export during a switching process. The requirements are designed to ensure that exported data is actually usable, not merely technically delivered.

Machine-Readable Formats

Data must be exported in machine-readable formats. This means formats that can be processed by software without manual intervention — structured formats like JSON, CSV, XML, Parquet, or similar open formats depending on the data type. Providing a customer with a PDF export of their data, or a format that requires the provider’s own proprietary tools to read, does not satisfy the machine-readable requirement.

Documented APIs

Where data is accessed via APIs, those APIs must be documented. The documentation must be sufficient to allow the customer — or a third party acting on the customer’s behalf — to understand how to retrieve all relevant data and configurations. Documented APIs are distinct from proprietary APIs: a provider cannot satisfy this requirement by providing an API that only works with the provider’s own downstream tools. The documentation must be complete enough to be useful to an independent operator.

No Proprietary Lock-In

The Act prohibits providers from structuring their export mechanisms in ways that create proprietary lock-in. Data must be exportable in formats that are not dependent on the provider’s own tools or infrastructure to be useful. This requirement directly targets one of the most common forms of technical lock-in: the practice of storing customer data in proprietary formats that can only be read, processed, or converted using the provider’s own software.

Completeness

The export must be complete in the sense relevant to the stated switching purpose. A customer who is migrating a particular service should be able to export all data and configuration information associated with that service, not just the data that the provider chooses to expose through standard export tools. If certain data is held in backup systems, archival storage, or secondary indices, the provider must make that data available for export as part of the switching process.

Implementation Timeline

The Data Act’s switching requirements did not become applicable all at once. The Act became applicable in September 2025, and the cloud switching provisions in Chapter VI apply from that date. However, the switching fee phase-out — which is addressed in the companion article on switching fees — operates on a distinct timeline. From September 2025, switching fees were required to be reduced to cost level. From January 12, 2027, switching fees must be eliminated entirely.

The functional equivalence and technical export requirements, by contrast, are obligations from September 2025. There is no phased implementation for these core switching obligations — they apply immediately to all cloud contracts governed by the Act. For US cloud providers that had not previously designed their export and portability features with regulatory compliance in mind, September 2025 was the compliance date for having these capabilities in place.

Given that we are now past September 2025, providers that have not yet implemented compliant switching procedures are already in a period of potential non-compliance. National supervisory authorities are still building their enforcement capacity, and the practical risk of immediate enforcement action may be limited, but the legal exposure is real, and providers should prioritize remediation.

Multi-Cloud Architectures

One of the more technically complex aspects of Chapter VI is its application to multi-cloud architectures. Many sophisticated cloud customers do not use a single cloud provider; they distribute workloads across multiple providers, often using a combination of public cloud, private cloud, and colocation infrastructure. The switching obligations under Chapter VI apply even in these complex environments.

For a customer operating a multi-cloud architecture, switching may mean moving a specific workload from Provider A to Provider B while leaving other workloads at Provider A, or it may mean consolidating all workloads from Provider A to Provider B. In either case, the outgoing provider must facilitate the switch in accordance with its Chapter VI obligations. The fact that the customer also uses other providers does not reduce the outgoing provider’s obligations.

For cloud providers, multi-cloud architectures present technical challenges around data and configuration consistency. If a customer’s data and configurations are distributed across a provider’s own services and those services have dependencies on each other, the provider must be able to document those dependencies and provide the customer with the information they need to recreate the relevant portions of their architecture elsewhere. A provider cannot use the complexity of a multi-cloud architecture as a justification for incomplete or unhelpful export documentation.

Documentation and Cooperation Obligations

Chapter VI imposes documentation and cooperation obligations on cloud providers that go beyond the technical export requirements. These obligations are about the process of switching, not just the technical output.

Pre-Contractual Documentation

Before a cloud service contract is entered into, the provider must make information available to the potential customer about the switching process, the export capabilities, the formats in which data can be exported, and any constraints or limitations that might affect a future switching exercise. This pre-contractual disclosure obligation is designed to allow customers to make informed decisions when choosing a provider — they should know, before they sign up, how easy or difficult it will be to leave.

Active Assistance During Switching

When a customer initiates a switching process, the provider is not permitted to simply point the customer to a self-service export tool and walk away. Chapter VI requires active cooperation from the provider throughout the switching period. This includes providing technical assistance, responding to questions about data formats and configurations, and working collaboratively with the customer and, if applicable, with the incoming provider to facilitate a smooth transition.

The cooperation obligation extends to working with the incoming provider where technically feasible. In practice, this means that if the customer has identified their new provider and the two providers can establish a direct technical channel to facilitate the data transfer, the outgoing provider must cooperate with that approach. It cannot refuse to engage with the incoming provider or make the process unnecessarily difficult by routing everything through manual customer-mediated processes.

Post-Switch Data Retention

After a switching process is complete, the outgoing provider must retain the customer’s data for a period that allows the customer to verify that the switch has been completed successfully. The Act establishes a default retention period for this purpose. During this window, the customer must be able to access their data at the outgoing provider to perform verification or to retrieve anything that may not have been captured in the initial migration.

Practical Implications for US Cloud Providers

For US cloud providers with EU customer bases, Chapter VI requires a systematic review of product capabilities, contract language, pricing structures, and operational processes.

Product and Engineering

The functional equivalence and data export requirements translate directly into engineering obligations. Providers must ensure that their platforms have robust, well-documented export capabilities covering all data and configuration types that a customer would need to reconstitute their environment elsewhere. If a provider’s current export tools are partial, poorly documented, or limited to certain data types, that is a product gap that must be addressed.

Providers should conduct a comprehensive audit of what data and configurations customers accumulate over the course of using the service, and then assess whether all of those elements are exportable in machine-readable formats through documented APIs. Any gaps identified should be prioritized in the product roadmap as a regulatory compliance matter, not merely a nice-to-have feature.

Contract Review

Standard cloud service agreements must be reviewed for compatibility with Chapter VI. Clauses that restrict data portability, limit export capabilities, impose technical barriers to switching, or create procedural delays in the switching process may conflict with the Act’s requirements. Customer contracts that were entered into before September 2025 may include terms that are now non-compliant; providers should consider how to address these contracts through standard amendment processes or new terms of service cycles.

Customer Communication

The pre-contractual disclosure requirements mean that providers must update their standard sales and onboarding documentation to include clear information about switching capabilities, export formats, and any constraints. This information should be written in plain language and should be readily accessible — buried in a technical appendix to a contract that most customers will not read does not satisfy the spirit of the disclosure obligation.

Operational Readiness

The active cooperation obligation during switching means that providers must have a defined operational process for managing switching requests. This includes a designated team or function responsible for handling switching requests, internal protocols for responding to customer requests within a reasonable timeframe, and documented procedures for coordinating with incoming providers where feasible.

Providers that have historically treated switching as an edge case — handled on an ad hoc basis by the customer success team — will need to formalize this process. A Chapter VI-compliant switching request handling process is an operational capability, not just a product feature or contractual promise.

Enforcement and Penalties

The Data Act relies on Member State supervisory authorities to enforce its provisions, including Chapter VI. Each EU Member State is required to designate one or more competent authorities responsible for monitoring compliance and imposing penalties for breaches. The Act specifies maximum administrative fines that Member States must make available, and national authorities have the discretion to impose penalties proportionate to the severity and duration of the violation.

For cloud providers with EU customer bases, the enforcement risk is twofold. First, supervisory authorities may initiate investigations based on market surveys or complaints from cloud customers who experience switching difficulties. Second, customers who are unable to switch despite wanting to do so may have private rights of action under national implementing legislation. The combination of public enforcement and private litigation creates a meaningful compliance incentive that US providers should factor into their Chapter VI compliance investment.

The Data Act’s enforcement framework for cloud switching is still being operationalized by national authorities, and early enforcement is likely to focus on the most egregious cases of non-compliance. However, providers should not assume that a grace period exists: the legal obligations apply from September 2025, and a provider that receives a complaint from a major enterprise customer about switching difficulties faces legal exposure regardless of how mature the enforcement system is at that moment.