Cloud exit under the EU Data Act: Why switching rights are becoming a governance issue

For many years, cloud exit has been one of the most negotiated and least tested parts of cloud contracting.

I see this frequently when helping financial institutions, banks, insurance undertakings and other regulated operators on cloud outsourcing, ICT third-party risk and technology transformation projects. The discussion usually starts with a familiar concern; the customer wants the flexibility to move data, workloads or applications away from a cloud environment, but the practical ability to do so depends on architecture, formats, interfaces, costs, operational continuity and the provider’s own processes.

This is the point at which vendor lock-in becomes more than a commercial inconvenience. In regulated sectors, it may affect concentration risk, exit strategy, business continuity, auditability and the customer’s ability to remain in control of critical or important functions.

Chapter VI of the EU Data Act brings this issue into the centre of cloud contracting. It creates a binding framework for switching between data processing services and for moving from cloud services to on-premises ICT infrastructure. For customers, it strengthens the legal basis for demanding a workable exit. For providers, it requires a review of contracts, migration procedures, technical documentation, interfaces and pricing models.

The result is a significant shift in the way cloud contracts should be read. Exit provisions are becoming part of the operational design of the service.

 

From portability policy to binding switching rights

The Data Act starts from a pragmatic market observation. Cloud services have often been built around proprietary architectures, non-standard formats, complex dependency chains and charging models that make exit difficult in practice. Earlier EU policy relied, to a large extent, on voluntary industry initiatives and codes of conduct to support cloud portability. The Data Act moves beyond that approach and introduces mandatory obligations for providers of data processing services.

The scope is broad. Chapter VI covers services enabling on-demand network access to configurable computing resources, including infrastructure, platforms and software. In practical terms, this means that IaaS, PaaS and SaaS models can all be caught, although the technical obligations are calibrated differently depending on the nature of the service. The rules are relevant where the service is offered to customers in the EU, regardless of where the provider is established.

This territorial reach matters. Many corporate cloud arrangements are negotiated on global or regional templates. A Data Act review requires understanding which services are in scope, which data and digital assets are exportable, and how the provider will support the migration.

 

The obligation to remove obstacles

Article 23 is the operational core of the cloud switching regime. Providers must remove obstacles that prevent customers from switching to another provider, porting data and digital assets, using multiple providers simultaneously or moving to on-premises infrastructure.

Those obstacles may be commercial, contractual, technical or organisational. They may arise from termination mechanics, disproportionate switching costs, unclear migration processes, limited documentation, proprietary formats, inadequate export tools, insufficient interoperability, or service bundles that make it difficult to separate one data processing service from a wider package.

The customer should be able to terminate the existing service, enter into an arrangement with a different provider, transfer exportable data and digital assets, and maintain continuity during the switching process.

For IaaS services, the framework introduces the concept of functional equivalence. The source provider must take reasonable measures to facilitate materially comparable outcomes in the destination service, where both services share the relevant features. For PaaS and SaaS services, the emphasis is different; providers must make open interfaces available free of charge and support data portability and interoperability. In both cases, legal drafting and technical architecture need to be aligned.

 

Mandatory contractual content

The Data Act sets minimum contractual content for data processing services.

Contracts should expressly allow the customer to switch to another service, move to an on-premises environment or erase its exportable data and digital assets. The notice period for initiating the switching process cannot exceed two months. Once the notice period has expired, the transitional period for completing the switching process should generally be no longer than 30 calendar days.

Where a 30-day transition is technically unfeasible, the provider must inform the customer within 14 working days, explain the technical impossibility and indicate an alternative transition period. That alternative period cannot exceed seven months. During the transition, the provider has to maintain business continuity, provide reasonable assistance, inform the customer of known risks to continuity and preserve a high level of data security.

These requirements create a new level of specificity for cloud exit clauses. A generic obligation to provide reasonable assistance on exit will often be insufficient. Customers and providers need to define the data categories, digital assets, export formats, support services, documentation, interfaces, timelines, responsibilities and security measures that will apply during migration.

The same applies to trade secrets. The Data Act recognises that some data or resources may be protected by the provider’s trade secrets. At the same time, trade secret protection cannot be used in a way that frustrates the switching process. This is likely to become a delicate negotiation point, especially in complex SaaS and PaaS environments where the boundary between customer data, metadata, configuration, models, logs, analytics and provider knowhow is rarely self-evident.

The contract should also address post-switching retrieval and deletion. Once the transitional period has ended, the customer must have at least 30 calendar days to retrieve exportable data and digital assets. After a successful switch, the provider must delete the customer’s exportable data and digital assets. For regulated customers, this should be coordinated with record-retention obligations, audit requirements, litigation hold rules and sector-specific regulatory expectations.

 

The economics of exit

The Data Act also attacks one of the most tangible forms of lock-in: the cost of leaving.

Until 12 January 2027, providers may still charge reduced switching charges, limited to the costs directly incurred in the switching process. From 12 January 2027, providers will be prohibited from imposing switching charges on customers. The European Commission has clarified that this includes data egress charges connected with switching.

This doesn’t mean that every cost connected with a cloud relationship disappears. Standard service fees, additional professional services and proportionate early termination charges may raise separate questions depending on the circumstances. The contractual analysis will need to distinguish carefully between a legitimate commercial charge and a switching charge that undermines the Data Act regime.

Several major cloud providers have already announced programmes to waive certain data transfer-out charges where a customer migrates away. The conditions still matter. Full exit versus partial exit, service-by-service scope, approval process, timing, eligible transfer routes, multi-cloud use cases and operational support may all affect the value of the waiver.

 

Why this matters for financial services and insurance

For banks, insurers and other financial entities, the Data Act sits alongside DORA and existing outsourcing governance.

DORA requires financial entities to manage ICT third-party risk within their ICT risk management framework, maintain information on ICT third-party arrangements, assess concentration risk and put in place exit strategies for ICT services supporting critical or important functions. The ECB’s guide on outsourcing cloud services also highlights provider lock-in, concentration risk, portability, exit planning and regular testing of exit plans as core supervisory concerns for supervised entities.

This is why the Data Act is particularly relevant for regulated cloud customers. It gives them additional rights against cloud providers, while DORA requires them to demonstrate that exit is realistic, feasible and operationally controlled. The two regimes speak to each other. One gives the customer stronger switching rights; the other requires the customer to build the governance capability to exercise them.

In practice, this means that financial entities should align four layers: the Data Act switching provisions in the cloud contract; the DORA contractual and third-party risk requirements; the technical exit plan for the relevant service; and the operational resilience documentation, including business continuity, testing and concentration risk assessments.

A well-drafted exit clause will have limited value if the customer has never mapped the data to be exported, tested the migration route, assessed the skills needed to perform the exit or identified credible alternative providers. Conversely, a sophisticated DORA exit plan will be harder to execute if the cloud contract lacks the mandatory Data Act content or leaves too much discretion to the provider during migration.

 

What providers and customers should do now

For cloud providers, compliance should be treated as a product, legal and operating model exercise. Standard terms, order forms, product schedules and online terms should be reviewed against the Chapter VI requirements. Providers should check whether the contract contains the mandatory switching rights, the maximum notice period, the transition process, the assistance obligations, the categories of exportable data and digital assets, the treatment of trade secrets, the post-switch retrieval period, deletion mechanics and the applicable switching charges.

Technical readiness is equally important. Providers should map how export works for each service family, because IaaS, PaaS and SaaS raise different issues. Documentation, APIs, export tools, migration runbooks, customer support processes and security controls should be consistent with the contractual promises made to customers. Switching-related charges also need to be transparent, defensible and aligned with the 2027 deadline.

For customers, the Data Act creates a stronger negotiation position, but the benefit will depend on how that position is used. In new procurements, switching should be built into the RFP and evaluation criteria. Customers should ask providers to describe the exportable data, digital assets, formats, interfaces, timing, support model, charges, treatment of trade secrets and deletion process. For critical systems, this information should be assessed by legal, procurement, technology, security and operational resilience teams together.

In existing contracts, customers should identify which arrangements involve data processing services in scope of the Data Act, prioritise critical or important functions, and review whether the current exit clauses can support the mandatory switching process. This is especially important where the contract relies on generic cooperation language, vague references to standard export tools or provider-controlled migration procedures.

For regulated customers, the review should feed into DORA remediation. The exit plan should be reconciled with the contract. The migration timetable should be realistic. The skills and resources required to execute the exit should be identified. Testing should be planned. Alternative providers or insourcing options should be reassessed periodically.

 

Cloud exit as an entry requirement

The Data Act won’t make cloud migrations simple. Complex systems will remain complex. Moving from one cloud environment to another will still require architecture work, data mapping, security planning, testing, business continuity measures and commercial discipline.

The change is that exit is becoming a regulated capability.

The most useful question for 2026 cloud contracting is a practical one; could the organisation actually execute the exit under stress, with data, continuity, security and costs under control?

For customers, this question should shape procurement, contract negotiation and operational resilience planning. For providers, it should shape product design, documentation, pricing and customer support.

Cloud exit used to be discussed at the end of the contract. Under the Data Act, it increasingly needs to be designed at the beginning.