Leaving your cloud provider should feel like moving, not rebuilding. Yet retrieving data is often only the first step: connections must also be rebuilt, certain services replaced and everything checked to ensure it works elsewhere. As of September 2026, the Data Act provides the new European framework for loosening this dependency. But the gap between a right to leave and a successful migration remains substantial. This analysis draws on the adopted regulation and established technical mechanisms, without prejudging an implementation record that has yet to be assessed.
A right to leave, not an automatic migration
The European Data Act entered into force in January 2024 and has applied since 12 September 2025. Its provisions on data processing services specifically target barriers to switching providers: deterrent clauses, opaque procedures, export difficulties and a lack of cooperation. It covers both major US companies operating in the European market and providers established in the Union.
The legislation requires exit conditions to be formalised in the contract. In particular, it provides for a maximum notice period of two months to initiate the switch, followed by a transition period normally limited to thirty days. If that deadline is technically unfeasible, the provider must justify this and may propose an extended transition within the limits set by the regulation. This timetable gives customers leverage, without guaranteeing that their own migration work will be completed as quickly.
Another crucial deadline is 12 January 2027. On that date, switching charges must be eliminated. Until then, the reduced charges permitted must not exceed the costs directly associated with switching. This means neither universally free network traffic nor the disappearance of all amounts owed under the contract. The exit bill and the actual cost of moving are two separate issues.
Files travel better than applications
Consider a fictional retailer. Its product photos are held in object storage, its catalogue in a managed database, its orders pass through a messaging service and its promotions trigger functions executed on demand. Downloading the photos seems straightforward. Replicating message delivery guarantees, access permissions and function behaviour is much less so.
This is the heart of technical lock-in. A virtual machine running a common operating system can be moved relatively easily, provided its image and networking are adapted. An application built around a proprietary database, an analytics engine or a specific artificial intelligence service may require rewriting. Interfaces can look similar without offering the same performance, limits or guarantees.
The Data Act distinguishes between these situations. For infrastructure services, it provides for measures to facilitate functional equivalence at the destination, under the conditions it defines. For other categories, open interface requirements and interoperability provisions play a greater role. The regulation does not require a competitor to replicate every proprietary service exactly. It therefore does not turn two cloud service catalogues into interchangeable parts.
The trap of invisible dependencies
Containers and Kubernetes have popularised a promise: package an application so it can run anywhere. They do improve portability, but they do not carry all of its infrastructure with them. Behind the container remain certificates, secrets, load balancers, backups and security rules. Even tools that describe infrastructure as code use provider-specific components.
Risk also lurks in day-to-day operations. A team accustomed to a console, its alerts and its dashboards must develop new habits. A migration can be technically complete while weakening the ability to diagnose an incident. Documentation and training are therefore elements of exit readiness, not optional extras.
A contract can hold customers back without banning departure
Lock-in does not always take the form of a clause preventing departure. It can stem from a discount tied to a multi-year commitment, a minimum spending requirement or commercial credits usable only within the same ecosystem. A company then retains the option to leave, but forfeits a benefit or must honour a commitment separate from migration charges.
Several documents must therefore be read together: the main contract, service schedules, pricing terms and negotiated agreements. Which data can be exported? In which formats? Who provides assistance? When will copies be deleted? The Data Act regulates the exit process, but the classification of a charge or the scope of a service may still give rise to disputes.
The issue becomes more complex when an integrator or reseller is involved. The customer does not necessarily have a single point of contact for hosting, licences and operations. Assigning responsibilities before departure avoids discovering during the switchover that nobody had planned to rebuild access permissions.
The bill goes far beyond transfer charges
Data transfer-out charges, often called egress fees, have become a symbol of cloud lock-in. Regulating them matters, especially for large volumes. But abolishing them when switching providers will pay for neither developers nor testing. The least visible costs may therefore become the most decisive.
- Parallel operation: maintaining both environments during copying, synchronisation and verification.
- Adaptation: modifying code, data schemas, security policies and operational tools.
- Validation: checking performance, data integrity, backups and disaster recovery.
- Operational risk: planning a phased switchover and a rollback if service deteriorates.
Added to this is data gravity: the larger a dataset and the more connected it is to other systems, the more coordination moving it requires. A production database continues to change during its transfer. The latest writes must be synchronised, duplicates avoided and downtime minimised. Bandwidth alone does not solve this problem.
Exit readiness starts at procurement
For businesses, the sensible response is not necessarily multicloud across the board. Systematically spreading every application across several providers can multiply the skills required, contracts and potential points of failure. It is better to identify critical services, map their dependencies and make a conscious choice about which ones to accept.
A limited exit test is often worth more than a sales promise. Exporting a database, restoring a backup elsewhere and measuring the work required allow the contract to be tested against reality. Buyers can also request documented formats, an assistance timetable and an estimate separating provider charges from internal work.
What happens next? The January 2027 deadline should shift the debate away from the advertised price of leaving and towards the actual ability to operate elsewhere. That is a prospect, not yet an established outcome. The Data Act’s success will depend on its enforcement, but also on better-planned architecture and procurement choices. The freedom to switch clouds will be measured by a simple question: have you already tried leaving?
