Strategy
Cloud reversibility: from 12 January 2027, it is a right
The Data Act bans exit fees and imposes contractual migration deadlines. What an architect should do with that: a tested exit plan, not one more clause.
Reversibility has for twenty years been the most consensual and least applied chapter of cloud contracts. The EU Data Act (Regulation (EU) 2023/2854) takes it out of the register of good intentions: from 12 January 2027, switching charges — including the data transfer fees tied to leaving — are prohibited for data processing services, whether IaaS, PaaS or SaaS.
What already applies, and what is coming
The chapter of the regulation devoted to switching has applied since 12 September 2025. Until 12 January 2027, providers may charge switching fees provided they are limited to covering the costs actually incurred; beyond that date, they may charge nothing on that basis. The obligation covers any provider serving customers established in the Union, wherever the provider itself is based.
The regulation also frames the process: a maximum notice period of two months to request the switch, a transition period capped at thirty calendar days, and the ability to retrieve your data for at least thirty days afterwards. These durations are contractual maximums — nothing obliges a customer to leave it to the last minute.
The exact scope, which is often misread
The ban covers charges related to switching: what you pay to leave. Day-to-day egress — serving content to your users, replicating across regions, feeding a partner — remains billable, and there is no reason it should be otherwise. Reading the text as the end of egress billing would lead to badly sized architectures.
A right does not make a migration possible
This is the point that concerns the architect. The exit bill has almost never been the real obstacle: it hurts, but it is paid once. What actually prevents leaving lies elsewhere, and the regulation changes none of it.
- Proprietary managed services. A managed database, a queue, an identity engine or an inference service expose APIs that exist nowhere else. The exit cost is a rewriting cost, not a transfer cost.
- Data gravity. Several hundred terabytes do not move in thirty days without preparation, even free of charge.
- Operational dependencies. Roles, access policies, secrets, deployment pipelines and observability are often more tightly coupled to the provider than the application itself.
- Know-how. A team that has never operated anywhere else will not do so in a quarter, whatever the clauses say.
What an architect should do with it
The right answer is not to make everything portable: an architecture that refuses every managed service pays permanent complexity for an option it may never exercise. The answer is to decide explicitly, component by component, what level of lock-in you consent to.
Three levels are enough to frame the discussion: portable (open standard, replaceable in days), replaceable (proprietary but with an equivalent and a known migration path), locked (no equivalent, exit means rewriting). A locked component is not a fault; a component locked by default, with nobody having decided it, is. This is exactly the kind of trade-off that deserves a written, dated architecture decision, as we explain regarding an architecture that does not have to be rebuilt.
An exit plan is tested, or it does not exist
An untested reversibility clause is worth exactly as much as a backup never restored. The useful exercise takes one day a year: take the most critical component, export its data to a neutral environment, and check that you can read it back. What the exercise reveals is almost never the volume — it is the forgotten dependency, the undocumented format, the secret nobody knows how to regenerate. These are the same reflexes as in operations and observability: you do not discover your blind spots on the day of the incident.
And for AI
The question now arises at the model layer too. An agent written directly against one provider's API, with its in-house tools and its memory format, is a locked component — including when the provider is excellent. The interoperability standards we described regarding MCP and A2A do not remove that lock-in, but they move its boundary, and that is what makes them useful in an architecture decision.
- From 12 January 2027, switching and exit charges are prohibited for data processing services in the EU.
- Ordinary egress remains billable: the ban targets leaving, not operating.
- Real lock-in is architectural — managed services, data gravity, operational dependencies — and the regulation does not touch it.
- Classify each component as portable / replaceable / locked, and write the decision down.
- An untested exit plan does not count.
Sources
Related reading
Does this challenge sound familiar?
A first conversation to assess it together, at no cost.