From 12 January 2027, a cloud provider serving customers in the EU can no longer charge you for leaving. Switching charges, including the data egress fees that come with a switch, go to zero. For many businesses, the size of that exit bill has been a quiet reason to postpone any serious look at their cloud setup.
The fee was only one part of the cost of leaving. Once it disappears, the part that remains is the architecture: how your application, your data and your operations are tied to one provider. That is worth understanding before the date arrives, and before your next contract renews.
The EU Data Act has applied since 12 September 2025. Its chapter on switching between data processing services covers cloud and edge providers, and its direction is simple: customers should be able to move to another provider, or back to their own infrastructure, without being held back by fees, slow procedures or incompatible services. The European Commission names high egress charges, lengthy procedures and a lack of interoperability as the barriers it wants to remove (Commission, Data Act explained).
Charges are phased out in two steps. Between 11 January 2024 and 12 January 2027, providers may still charge for switching and data egress, but only for costs they actually incur in the process. From 12 January 2027, those charges are removed entirely. The market has partly moved ahead of the law: one industry summary notes that AWS, Google Cloud and Microsoft Azure each announced free data transfer out for departing customers back in 2024 (FAST LTA).
The Act also puts duties on the provider side. According to the Commission, providers of platform and software services must offer open interfaces and export data in a commonly used, machine-readable format. Providers of infrastructure services must take measures so that a customer moving to a similar service gets materially comparable results for the features both services share.
The ban applies to charges for the switching process. The everyday cost of serving data to your own users is not part of it. Egress for running several providers in parallel also remains, because it counts as ongoing operation and not as a one-off move (Cloudmagazin). If your plan involves a multi-cloud setup, egress still belongs in the cost model.
Contract terms are a separate matter. A fixed-term contract still runs to its end, and the Commission's Digital Omnibus proposal would make explicit that providers can include early-termination penalties in fixed-term contracts (Simmons & Simmons). That makes renewal dates worth a look. An auto-renewal that rolls over just before January could keep you on the old terms for another cycle.
There are also exceptions, and some are still moving. Article 31 already treats certain services differently, such as software custom-built for one customer and non-production versions used for testing (Garrigues). The Digital Omnibus proposes lighter rules for custom-made services, and for small and mid-sized providers, on contracts concluded on or before 12 September 2025 (Greenberg Traurig). Whether your services count as standardised or custom is a question for your provider and your legal adviser, ideally answered in writing.
Whatever the contract says, leaving a cloud provider is an engineering project. How big it is depends on four layers of your own system, and only the first of them is touched directly by the Data Act.
LayerWhat ties you inWhat to look atDataProvider-specific storage formats, managed database features, backups that exist only in the provider's storageCan you export the full dataset in an open format and restore it somewhere else? How long does a test restore take?ApplicationFunctions, queues and workflow services called directly from business logic through provider-specific SDKsHow much business logic imports provider code? Is it hidden behind an interface you control?Identity and securityRoles, policies, key management and network rules defined in the provider's own modelWhich access rules exist only in the provider's console or templates? Who holds the encryption keys?OperationsDeployment pipelines, monitoring, alerting and runbooks built around one provider's toolsCould your on-call team run the system on a different platform? Where are the runbooks, and when were they last tested?
In our experience, the data move is often the most predictable part of a migration. The longer work sits in the application and operations layers, where years of small decisions made sense one at a time and added up to a dependency nobody mapped. That is why a regulation that lowers the price of exit does not, by itself, lower the effort of it.
Take a fleet management platform with around sixty employees, serving transport companies in the Netherlands and Belgium. It runs on a single hyperscaler. The data sits in a managed database, route events are processed by serverless functions, messages move through the provider's queue service, and users sign in through the provider's identity service.
A public transport client asks a reasonable question before renewing: could the platform run on a European provider within a year? Until now, the team's first worry would have been the cost of moving several terabytes out. From January that line item disappears, and the conversation turns to what is left. The functions are written around the provider's event format. The access rules live in the provider's own policy language. The deployment scripts only work on one platform, and the runbooks assume its monitoring tools.
None of this is unusual, and none of it needs a rebuild. The practical route is to work through it in steps. Put the queue behind an interface the team controls. Describe the infrastructure in code that can be adapted. Restore a copy of the database into a second environment and time it. Write down the access rules in a provider-neutral form. After a few weeks, the answer to the client changes from "we are not sure" to "here is what it would take, and here is how long".
These can be done in a few weeks by a small group, and none of them requires a decision to switch.
We are not suggesting that anyone should leave their provider because the fee goes away. Your current setup may well remain the right choice, and a wholesale migration brings its own cost, risk and new dependencies. What the date offers is a reason to find out what your options are while the question is still a calm one.
Our approach to this comes from application modernisation work. Systems become expensive to change when nobody built in room for it, and cloud dependencies are one more form of the same problem. Separating business logic from provider-specific code, describing infrastructure in a portable way and testing a restore turn an assumed exit into a demonstrated one. We usually advise doing this one component at a time, starting with the workload where the answer matters most.
Portability has a price too. It takes engineering effort, and it can mean giving up a convenient feature that only works inside one vendor's ecosystem. How much of that trade makes sense depends on how critical the workload is and what it would cost you to be unable to move it.
Let's talk about your systems, the dependencies that matter most, and what a realistic exit plan would look like for your business.
.jpeg)
On 12 January 2027. Until then, providers may still charge for switching and data egress, but only for the costs they incur in the switching process. From that date, the Data Act removes these charges entirely for customers who move to another provider or back to their own infrastructure.
No. The ban covers charges for the switching process itself. Engineering effort, running two providers in parallel, everyday egress and the terms of your current contract still apply. How much work a move takes also depends on how closely your data, application, access rules and operations are tied to one provider.
Chapter VI of the Data Act covers providers of cloud and edge services broadly, but some services are treated differently. Article 31 already makes exceptions, for example for software custom-built for one customer. The Commission has also proposed further relief for custom-made services and for smaller providers on older contracts. Ask your provider in writing how the rules apply to the services you use.
