EU Data Act and Cloud Data Portability: What Changes for Companies Using European Clouds

The EU Data Act has applied since September 12, 2025, so for companies using European cloud services, it is no longer a future reform but an active regulatory context. The most practical part for cloud users is the set of rules on switching between data processing services: changing providers, moving part of the infrastructure in-house, or using several clouds in parallel.

The main change is that businesses have stronger grounds to require clear exit terms, migration assistance, and the removal of artificial barriers from their providers. This applies not only to major cloud platforms, but also to a broader range of cloud and edge services: SaaS, PaaS, IaaS, and edge solutions.

However, the Data Act does not make an architecture automatically portable. If a system depends on managed databases, closed APIs, provider-specific access mechanisms, logs, keys, and internal formats, the legal right to export data does not turn into a ready-made migration. The regulation changes the balance between the customer and the provider, but technical readiness for switching remains the company’s responsibility.

In brief, companies will need to account for the following in advance:

• Portability covers not only files and databases, but also metadata;
• Lower switching charges do not mean zero migration cost;
• Dependence on a single provider should be assessed as a technical, contractual, and operational risk;
• Architecture should be designed with a possible cloud exit in mind.

As a result, the Data Act helps reduce external barriers, but it does not replace a Cloud Exit Plan. A company still needs to understand in advance which data can be exported, which metadata is needed to restore processes, which integrations will have to be reworked, and which services are too tightly coupled to a specific provider.

Below, we will look at what exactly the Data Act changes in cloud switching, which data must be portable, and where the provider’s obligations end and the company’s own area of responsibility begins.

What the Data Act Changes in Cloud Switching

Under the Data Act, switching between cloud services is understood more broadly than simply “closing an account with one provider and moving to another.” A company may change providers, move part of its data processing into its own infrastructure, or use several clouds in parallel.

This is the area regulated by Chapter VI of the EU Data Act, Articles 23–31. It covers data processing services: cloud and edge services, including SaaS, PaaS, and IaaS. In practical terms, this means not only virtual machines and storage, but also platforms, applications, managed services, and edge solutions where data is processed closer to the place where it is generated.

The main idea is to remove artificial barriers that prevent a customer from leaving a service or moving to another model. The Data Act treats these barriers more broadly than just the absence of an “export” button. The problem may include:

• Commercial terms that make exit too expensive;
• Technical restrictions: closed formats, incomplete APIs, complex export procedures;
• Contractual terms: unclear notice periods, termination rules, or switching timelines;
• Organizational barriers: no clear process, responsible contacts, or documentation.

For companies, this changes the negotiating position. When changing clouds, moving to a hybrid model, or working with multiple providers, a customer can rely not only on the contract, but also on the provider’s obligation to reduce obstacles to switching.

However, the boundary remains important. The Data Act does not promise that the service at the new provider will work the same way as the old one, and it does not migrate internal integrations, business logic, or application settings on behalf of the customer. The law can help the company obtain data, metadata, and a clearer exit process, but readiness for a real migration still depends on the company’s architecture.

That leads to the next question: what exactly counts as portable data, and why businesses need not only files or tables, but also metadata — relationships between objects, access rights, change history, and logs.

A Simple Explanation of Data Portability Requirements

Data portability under the Data Act is not just the ability to download an archive from a cloud service. The meaning is broader: the customer should be able to receive data related to the use of the service and use it to switch to another provider, move to its own infrastructure, or adopt a mixed model.

In practice, portable data can be divided into three groups:

• Input data — everything the customer has uploaded, transferred, or entered into the service: files, records, reference data, customer profiles, transactions, documents;
  
• Output data — the results produced by the service: reports, calculations, processed records, generated documents, analytics results;
  
• Metadata — data about structure and usage: relationships between objects, timestamps, user roles, access rights, audit logs, schemas, and storage parameters.

Metadata is especially important for business. Without it, a migration may be formally completed but practically useless. For example, in a SaaS CRM, exporting customer profiles and a list of deals is not enough. The company also needs relationships between customers, contracts, tasks, and responsible employees, change history, attachments, access settings, and activity logs. Otherwise, it receives a set of files, but not a business process that can be restored in another system.

At the same time, portability does not mean that the customer receives a copy of the provider’s entire platform. The boundary begins where the provider’s own assets begin: service algorithms, internal tools, software components, optimization models, closed business logic, trade secrets, and intellectual property. The customer can request its data and the necessary context for using it, but not the cloud product itself “disassembled into parts.”

It is also important not to confuse the Data Act with GDPR Article 20. GDPR Article 20 concerns an individual’s right to receive and transmit their personal data. The Data Act operates more broadly in the context of the relationship between a customer and a cloud service provider: it covers service data and technical context where they are needed for switching. If the export includes personal data, GDPR requirements still apply.

This is where the main limitation becomes clear: the right to portability helps the company obtain data, but it does not automatically distribute all migration work. The provider must reduce barriers, while the company still needs to verify export completeness, format compatibility, metadata availability, and the readiness of the new environment to accept the data.

What You Can Require from the Provider, and What Remains the Customer’s Responsibility

After the question of portable data comes the next practical issue: who is responsible for what during the switch. The Data Act strengthens the obligations of the cloud service provider, but it does not turn the provider into the customer’s migration team.

The provider can be expected to offer a clear exit process: transparent contract termination terms, a documented export procedure, reasonable technical and organizational assistance, and the transfer of data and necessary metadata in the required format. Otherwise, the right to portability remains formal: the data may technically be available, but extracting it quickly and in a business-usable form becomes difficult.

Cost is a separate important point. Until January 12, 2027, limited charges related to the actual costs of switching may still apply. From January 12, 2027, switching charges, including charges for outbound data transfer during the switch, must be eliminated. However, this does not remove the customer’s internal costs: the team, testing, parallel operation of the old and new environments, integration setup, and application adaptation.

Responsibilities can be divided as follows:

The Data Act strengthens the customer’s negotiating position, but it does not replace a Cloud Exit Plan. The provider must reduce external barriers, while the company must prepare the internal part of the transition: architecture, data, integrations, keys, tests, and the target environment.

After that, the technical consequences become clear: if portability becomes a mandatory part of the provider relationship, architecture also needs to be designed so that cloud exit is not an emergency improvisation, but a pre-tested scenario.

Technical Implications for Architecture

For architecture, portability requirements mean one simple thing: a cloud service should be viewed not only as a runtime environment, but also as a potential exit point. This affects data storage, integrations, backups, key management, and the choice of managed services.

Data and Metadata Should Be Described in Advance

Portability starts with a data map. The company needs to understand where core data is stored, which reference data and relationships are required to restore processes, which logs are mandatory for audit, which parameters belong to service configuration, and which belong to business logic.

Without such a map, it is impossible to verify whether the provider has supplied a complete export. Formally, the data may be exported, but without relationships, roles, change history, attachments, and logs, the business process cannot be restored in a new system.

The same applies to backups. A backup inside the same cloud is not the same as portability. For critical systems, the company needs to verify whether data can be restored in another environment, whether encryption keys are available, and whether object versions, access rights, logs, and storage parameters are preserved.

Formats, Keys, and Managed Services Become Risk Areas

The more an architecture depends on closed formats, provider-specific APIs, and managed services from a single provider, the harder the switch becomes. If an application uses interfaces available only from one vendor, migration will require integration rework. If data is stored in a provider-specific format without a stable schema, the export may be usable only “on paper.”

Keys and identity should be reviewed separately. If encryption keys, roles, access policies, and audit logs are fully tied to the provider’s service, switching may become difficult even if the data export is complete. The company should define in advance which keys it controls, how they are rotated, and how the access model will be transferred.

The difference between IaaS, PaaS, and SaaS matters here as well. In IaaS, migration is usually more straightforward: virtual machines, disks, networks, images. In PaaS, dependency is higher: managed databases, queues, functions, and identity services often have their own APIs, scaling parameters, and log formats. In SaaS, the main difficulty is the data model and business processes: an export may include records, but not the application’s internal logic, automations, or relationship structure.

Integrations Must Move Together with the Data

Cloud systems rarely operate in isolation. They are connected to payment services, corporate identity, storage systems, reporting tools, notification services, and security tools.

During a switch, the company needs to migrate not only data, but also the exchange flows: API requests, webhooks, queues, access tokens, synchronization schedules, rate limits, and error handling. If these dependencies are not documented in advance, the new environment may accept the data but still fail to operate properly within the business process.

After this analysis, one thing becomes clear: portability cannot be added to a system with a single contract amendment. It has to be tested in advance across data, metadata, APIs, backups, keys, managed services, and integrations. That is why the next section provides a short checklist to help identify the main dependency points on a single cloud provider before switching vendors becomes an urgent task.

Checklist: How to Reduce Dependence on a Single Cloud Provider in Advance

Reducing dependence on a single provider does not necessarily mean moving to multi-cloud immediately. Multiple clouds can reduce concentration risk, but they also add complexity in security, networking, monitoring, integrations, and cost management.

A more practical starting point is to focus on verifiable measures that make cloud exit technically possible:

Portability should also be included in architecture reviews. When choosing a new cloud service, the company should evaluate not only cost and functionality, but also the exit scenario: which data can be retrieved, in what format, how quickly, and with what technical limitations.

The migration plan should also account for a period of parallel operation between the old and new environments in advance. This is not a formality: data synchronization, testing, rollback, and downtime management almost always require separate time, budget, and owners.

This checklist does not eliminate all risks, but it turns provider dependence from a hidden problem into a manageable parameter. The Data Act reduces external barriers, while the company must reduce internal technical obstacles in advance: closed formats, untested backups, undocumented integrations, dependence on provider-controlled keys, and business logic hidden in the settings of a single service.

Conclusion

The new rules change the balance between the customer and the cloud provider: companies have stronger grounds to require a clear exit process, the transfer of data and metadata, switching assistance, and the reduction of commercial barriers. But this does not turn migration into an automatic process.

Real portability remains an architectural task. If a system depends on managed services, closed APIs, built-in access mechanisms, logs, and keys from a specific provider, the right to switch does not remove the technical complexity.

That is why the exit strategy should be built in advance: describe data and metadata, verify exports, test recovery, control keys, document integrations, and include provider switching scenarios in architecture reviews. The law reduces external barriers, but resilience to cloud switching is created inside the company — in its architecture, contracts, and operational processes.

FAQ

Does the Data Act mean that data from a European cloud can now be migrated for free?

No. From January 12, 2027, switching charges must be eliminated, including charges for outbound data transfer during the switch. However, the company’s internal costs remain: the team, testing, integrations, downtime, and configuration of the new environment.

Which cloud services fall under the switching rules?

The rules in Chapter VI cover data processing services, including cloud and edge services, SaaS, PaaS, and IaaS. This applies not only to the largest cloud platforms, but also to a broader range of providers if their service is used for data processing.

Does the provider have to transfer all of its technology together with the data?

No. Portable data includes input data, output data, and necessary metadata related to the use of the service. Algorithms, internal tools, software components, and assets protected by the provider’s intellectual property or trade secrets do not have to be transferred.

How is portability under the Data Act different from GDPR Article 20?

GDPR Article 20 concerns a data subject’s right to receive and transmit their personal data. The Data Act establishes a broader regime, including customer switching between cloud services and the portability of service data. If the data is personal data, GDPR requirements still continue to apply.

Does using multiple clouds fully remove dependence on one provider?

Not fully. Using multiple providers can reduce concentration risk, but it also adds complexity in security, networking, monitoring, access management, cost control, and incident response. It is an architectural decision, not a universal safety net.

Sources

1. Regulation (EU) 2023/2854 — Data Act, EUR-Lex

2. European Commission — Data Act explained

3. CISPE Cloud Switching Framework v1.0

4. Alston & Bird — The Data Act: Switching Requirements for Cloud Services Providers