Editor's note: The IAPP is policy neutral. We publish contributed opinion and analysis pieces to enable our members to hear a broad spectrum of views in our domains.
This is the fourth article in a five-part series on the EU Data Act. The first article, "EU Data Act operational impacts: Introducing the Data Act," explores the creation of the Data Act, its objectives, the negotiation backdrop, and how it fits within the EU's digital rulebook. The second article, "EU Data Act operational impacts: The Data Act's interplay within the EU digital rulebook," dives into the roles and requirements under the Act. The third article, "EU Data Act operational impacts: The Data Act as a challenge to data protection or other way around?" looks at the roles and requirements under the Act and cross-references stakeholder obligations with other laws to identify issues across the board.
Since the early days of the cloud revolution, organizations have embraced the flexibility and scalability that cloud services offer. Yet, migrating data and applications between different providers has often been seen as a complex and resource-intensive process, raising concerns about interoperability and vendor lock-in.
Companies often face challenges such as ensuring data portability without loss or corruption, adapting applications to different architectures, maintaining security and compliance throughout the process, and minimizing downtime to protect business continuity. These efforts also require careful management of costs and resources while overcoming vendor-specific dependencies that limit interoperability and make transitions more difficult.
The EU Data Act accelerates the transition into a new era of data portability and cloud interoperability, aiming to bring some balance to the digital market by giving users, regardless of size or type, greater control over our data. One of its most consequential aspects, especially for cloud service providers, is the requirement to enable effective switching between cloud services.
At its core, the Data Act’s provisions on cloud switching are about removing vendor lock-in, reducing economic dependency on dominant providers and fostering a competitive, innovative cloud ecosystem. See Recitals 77-80. But with this comes a series of compliance obligations and technical challenges that stakeholders must carefully navigate.
This article explores the relevant legal requirements under the Data Act and the challenges in having an effective implementation; it also examines if any similar obligations can be found under the Digital Operational Resilience Act and the Network and Information Security Directive 2.
The legal obligations for cloud switching under the Data Act
Entering into force progressively through 2024–2027, the Data Act introduces a right for users to change “providers of data processing services” — including cloud service providers — or migrate workloads on premises with minimal disruption. Under Chapter VI (Articles 23-26), the legislation requires digital service providers to make switching data processing services technically possible, contractually transparent, and financially fair.
It does so by removing commercial, contractual, and technical obstacles to switching cloud services and introducing mandatory portability interfaces and documentation that facilitate a seamless transfer. The act also eliminates data export fees — specifically egress fees — by January 2027, supports functional equivalence of digital services post switch, and establishes clearer rules on termination causes and what constitutes proportionate charges during transitions.
Cloud providers must ensure that users are able to retrieve all of their digital assets — including structured and unstructured data, metadata, and configurations — in a structured, widely supported, and machine-readable format. For example, users should be able to export databases such as CSV or JSON files, download configuration files in XML, and obtain metadata in standardized formats such as Dublin Core or ISO 19115.
Any loss of functionality during migration, such as the inability to use certain analytics features after export, must be transparently documented and objectively justified; silent degradation is not acceptable. Interoperability is not optional or merely a technical preference, it has become a regulatory obligation.
For instance, if a customer moves from one cloud provider to another, the new provider must be able to ingest the exported data without requiring extensive manual reformatting. While the law allows some flexibility in defining what constitutes reasonable effort, service providers and users must be able to demonstrate compliance through contractual commitments, including data portability clauses in service agreements, and verifiable system capabilities, such as providing automated export/import tools and audit logs of data transfers.
Technical challenges in enabling portability
While the Data Act lays out a strong regulatory vision, the practical implementation of cloud switching is technically complex. Organizations may face several key obstacles.
Legacy systems and proprietary architectures
Many cloud applications are built using provider-specific APIs, proprietary services, or orchestration layers. Switching such workloads requires rearchitecting components or introducing abstraction layers, which may not be feasible without significant effort or cost. For example, a company’s legacy customer relationship management platform was tightly integrated with a specific cloud provider’s proprietary workflow engine. When migrating to a multicloud model, the team had to rebuild automation logic using open-source orchestration tools, resulting in additional development time and cost.
Data gravity and export complexity
Large datasets, especially in analytics-heavy workloads or AI training pipelines, can be physically difficult to export or re-ingest into a different environment due to bandwidth limitations, format mismatches, or compliance constraints — like localization restrictions. For example, during the migration of a company’s regional data lakes, exporting multiterabyte analytics datasets from the current provider was hampered by bandwidth throttling and they needed to convert proprietary storage formats to open standards.
Security and IAM misalignments
Identity and access management policies differ widely across cloud platforms. Translating these securely into another provider’s framework while preserving integrity and audit trails poses a risk if not handled carefully. For example, when consolidating IAM across multiple cloud environments, mapping fine-grained access controls and audit logs from provider one to provider two required custom scripts and manual validation to ensure that privileged access and compliance reporting were not compromised.
Lack of unified standards
Despite the presence of some open standards and frameworks, such as GAIA-X or ISO/IEC 19941, there is not a universally adopted industry standard for switching between data processing services.
Switching between clouds, especially in multiservice or hybrid deployments, is not a plug-and-play process. Experience shows that careful planning, robust tooling, and adoption of standardized interfaces are essential to overcome these technical and compliance-based complexities.
Compliance considerations for providers
In order to meet Data Act and customer expectations, cloud providers must not only offer the right tools, but they also need to re-evaluate their governance frameworks and service offerings. Key compliance areas include the following:
Contractual transparency. The terms and conditions applicable to switching cloud providers must be clearly disclosed in customer contracts, including timelines, service levels during transition, supported export formats, and any termination charges.
Document the switching processes. Providers should develop and publish standard operating procedures for data extraction, service decommissioning, and migration support. These procedures should align with internal cybersecurity risk management frameworks, especially under NIS2 obligations.
Security and continuity controls. During a switch, the provider remains responsible for data confidentiality, availability, and integrity. Therefore, safeguards such as access control, encryption, secure logging, and business continuity measures must remain in place throughout the process.
Proportionality and justification. Where providers are unable to fully meet the switching obligations, they must document and justify this, ideally referencing technical infeasibility, workload criticality, or proportionality under resource constraints. This is particularly relevant to smaller cloud service providers.
Lessons from DORA
The Digital Operational Resilience Act, which applies to financial entities, contains a parallel mandate for managing third-party information and communication technology risk and ensuring portability and exit strategies from critical ICT service providers including, guess what, cloud providers.
Similar to the Data Act, exit strategies must be integrated into operational risk frameworks, ensuring functional continuity post-switch or transition to on-prem, with tested and documented termination processes and contracts guaranteeing data access, availability, and retrievability upon exit.
The Data Act takes that principle and scales it to the entire economy. For the provider, the challenge is the same: build systems that customers can exit without chaos. For the customer, the message is similar: test your exit strategy before it becomes an emergency.
Practical moves — From both sides
Companies subject to the Data Act should start mapping data now. At minimum, companies should maintain a clear understanding of their data assets, including their location and the format in which they can be exported. Ensure you have reliable, user-friendly data migration tools in place. If customers need extensive support or multiple tickets just to exit, the migration process is not yet adequate. Review contracts and replace complex exit clauses with clear, transparent procedures and timelines. Organizations should test internal migration to identify weak spots and then repair and test again until compliant.
From a customer perspective, organizations should scrutinize the terms before agreeing to any service. If data portability and deletion rights are not clearly defined, seek clarification. Ask providers to demonstrate how your data can be securely exported in practice — not just explain it in documentation. The relationship with a service provider should preserve the autonomy over your data; continued use should be a deliberate decision, not the result of technical or contractual lock-in.
Have we reached the dawn of Portability by Design and by Default?
With the EU Data Act, portability and interoperability have become fundamental rights for every cloud user. This shift is reshaping the cloud landscape, bringing users long-awaited control of data and choices.
But making cloud switching a reality isn’t just about ticking a compliance box; it’s about weaving portability into the very fabric of how services are designed, contracts are written, and security is managed. Providers who embrace these principles — right from system architecture to procurement and governance — will be best positioned for the future.
As demonstrated by other EU initiatives like DORA and NIS2, early adopters don’t just meet regulatory requirements. They set themselves apart by building resilient, future-ready, and truly user-centric cloud ecosystems. In this new era, portability isn’t just a feature — it’s a strategic advantage.
Cristina Costache, AIGP, CIPP/E, CIPM, CIPT, FIP, global data protection officer and chief information security officer for Noventiq.
