Until 2025 a European firm's cloud exit plan priced the egress bill as the main barrier and assumed the migration window was negotiable. The EU Data Act has applied since 12 September 2025 and removes switching charges entirely from 12 January 2027 while capping the switching timetable. What changed for the architecture team and what did not?

The situation the firm was in

Exit plans of that era had two load-bearing assumptions. The first was that leaving would cost a large, one-off egress bill, which made exit a budget question. The second was that if the firm ever did leave, the timetable would be agreed with the outgoing provider. Regulation (EU) 2023/2854 falsifies both, in opposite directions.

What actually changed

The money barrier goes away and a clock appears in its place. Under the Data Act's switching provisions a customer may start switching on a notice period of at most two months, followed by a mandatory maximum transitional period of 30 calendar days. Where that is technically unfeasible the provider must say so within 14 working days with a justification and propose an alternative of at most seven months. Switching charges are limited to costs actually incurred during the transitional years and must be withdrawn entirely from 12 January 2027.

Read that as an engineering requirement, not a legal one. 30 days is not a migration project; it is the window in which a rehearsed migration executes. A plan that has never been run fails inside that window because nobody knows the restore time, and the firm then depends on the provider's own assessment of technical unfeasibility to buy more time.

What did not change

The obligation has a shape. Functional equivalence is defined for a destination service of the same service type, and the obligation to enable it sits on providers of infrastructure services. Nothing in the regulation produces an equivalent of a proprietary managed service on a competitor's platform. If the firm's state lives in a provider-specific database, workflow engine or event service, the Data Act does not hand it a landing place. The real barrier to exit was never the egress invoice.

The useful action is a three-way classification of every dependency: commodity infrastructure; an open-protocol managed service with a self-hostable equivalent, such as Postgres or Kafka or an S3-compatible store or Kubernetes; and proprietary with no equivalent. Only the third class needs work, and the exit cost of the estate is the sum of that class. Choose the open-protocol option for anything holding durable state unless the proprietary service is measurably better on a metric the business tracks, since state is what makes the 30-day window impossible.

Where copying this would be a mistake

A firm outside the EU, or one whose regulator asks for no exit plan, should not build dual-provider abstractions for their own sake. An abstraction over two clouds costs the best features of both and is paid for on every release, which is a permanent tax against a risk that may never arrive.

When this is the wrong programme to run

For a non-critical workload the proportionate answer is a rehearsed data export and a documented rebuild, not a warm second provider. The claim a supervisor can actually test is when you last restored the production dataset into the alternative and what the recovery time was, not how many pages the plan runs to. One rehearsal a year on the single most critical service beats a complete paper plan for the whole estate, and it costs a week.