In five months the invoice that made cloud exit unthinkable is legislated to zero, and the most durable excuse in third-party risk management goes with it. DORA has required exit strategies for ICT services supporting critical or important functions since it applied. Most banks wrote them. Far fewer costed them, and fewer still rehearsed them, because the honest answer to "what would it take to leave?" involved an egress bill nobody wanted to put in front of a cost committee. From 12 January 2027 the EU Data Act abolishes switching charges outright, data egress included. That does not make migration easy. It removes the one obstacle that could be described as insurmountable without anybody having to test whether it was — and once the commercial barrier is gone, what is left is an engineering question a supervisor is entitled to see answered.
Executive Summary
- A date, not a direction of travel. Switching charges end on 12 January 2027. The statutory right to switch, and to receive technical assistance in doing so, has been in force since 12 September 2025.
- The excuse is being withdrawn, not the difficulty. Egress pricing was never the only reason exit plans stayed theoretical. It was the reason that did not require anyone to admit an architectural problem.
- DORA already asked for more than a document. Article 28(8) requires exit strategies that are comprehensive, documented and sufficiently tested, and reviewed periodically.
- The supervisory question changes shape. Not "do you have an exit plan?" but "you told us cost was the constraint — it is gone, so show us the rehearsal."
What Actually Changes on 12 January 2027 #
The Data Act is Regulation (EU) 2023/2854. Its switching provisions have arrived in stages, and the staging is worth stating precisely because the end state is unusually blunt.
Since 12 September 2025, customers of in-scope data processing services have held a statutory right to switch provider, and providers have owed technical cooperation to make porting work rather than merely permitting it in principle.
Since the Act entered into force, a transitional regime has capped what providers may charge. During that window switching and egress charges could not exceed the costs the provider actually incurred and that were directly linked to the switching process concerned. No margin, no strategic pricing.
From 12 January 2027, under the gradual-withdrawal provision in Article 29, switching charges are prohibited outright. That includes charges for data egress — the per-gigabyte transfer pricing that has done most of the work in making exit modelling look prohibitive.
Three consequences follow immediately, and only one of them is about money.
The commercial case for staying loses a line item that was often doing a great deal of rhetorical lifting. Contract terms drafted around a charging regime that will not exist need revisiting. And the analytical question shifts from what would this cost to what would this take, which is a much harder question to leave unanswered in a board pack.
Why Exit Plans Stayed On Paper #
It is worth being fair about this. Exit plans were not neglected because anybody thought they were unimportant. They stayed theoretical because a genuine test was expensive in a way that was easy to quantify and hard to justify.
Moving a meaningful workload out of a hyperscaler meant paying to move the data, standing up parallel capacity, and absorbing the cost of running two estates during a cutover. The egress line was the one a CFO could see, and it was reliably the line that ended the conversation. That made it an unusually comfortable obstacle: it deferred the programme without requiring anyone to say the architecture was the problem.
Underneath it, three harder constraints were doing the real work, and none of them is affected by the Data Act.
Managed services are not portable by nature. A workload built on a provider's managed database, its identity model, its event bus and its serverless runtime is not a workload that moves. It is a workload that gets rewritten. Portability was traded away deliberately, usually for good reasons of speed and operational cost, and the bill for that trade is denominated in engineering quarters rather than euros per gigabyte.
Data gravity outlives the data transfer. The analytical estate, the feature stores, the audit archives and everything that has grown up around them do not relocate cleanly even when the bytes are free to move.
Nobody has rehearsed it. A plan that has never been executed is a hypothesis. DORA's drafters clearly understood this, which is why Article 28(8) does not stop at requiring a plan.
Table 1: what the Data Act does and does not remove #
| Obstacle to exit | Removed on 12 January 2027? |
|---|---|
| Egress and switching charges | Yes — prohibited outright |
| Contractual terms built around those charges | No — they need renegotiating |
| Managed-service coupling | No — re-architecture, not transfer |
| Data gravity in the analytical estate | No |
| Absence of a rehearsed cutover | No — that is the work |
The right-hand column is the point. One row changes, and it is the row that has been standing in for all the others.
What DORA Actually Requires #
The obligation being unmasked here is not new, and it is more demanding than it is often treated as.
Article 28(8) requires financial entities to put in place exit strategies for ICT services supporting critical or important functions. Those strategies must account for provider failure, deterioration in service quality, business disruption arising from inadequate provision, and material risks to continuous deployment of the service. The plans must be comprehensive, documented, and — the phrase that matters — sufficiently tested and reviewed periodically.
"Sufficiently tested" was always the hard clause. A document describing a migration is not evidence that the migration is possible within a tolerable window. The supervisory expectation reads on the capability, not the artefact.
For two years, cost has been the reason the testing clause went unsatisfied in practice. It was a reason a supervisor could hear without immediately escalating, because it was true and quantifiable. From January it stops being available, and what remains is the answer to a question that has never had a good one: how long would this actually take, and how do you know?
The Contract Work Nobody Has Scheduled #
The near-term deliverable is unglamorous and time-boxed, which is a rare combination in this field.
Cloud agreements written over the last several years contain switching and egress economics that will be unlawful to charge. Some contain notice periods, assistance obligations and data-return terms calibrated to a world where the customer was expected to pay for the privilege. Those clauses do not self-correct on 12 January 2027; they simply become terms that cannot be enforced as drafted, sitting in agreements that still govern everything else.
That produces a discrete piece of work with a natural deadline: identify the affected agreements, establish which terms are displaced, and fold the corrections into the next renewal rather than discovering the mismatch during an incident.
Table 2: what to establish before the renewal cycle #
| Question | Why it decides your exposure |
|---|---|
| Which contracts price switching or egress? | Those terms become unenforceable; the rest of the agreement does not |
| What assistance is the provider actually obliged to give? | The statutory duty has been live since September 2025 |
| For each critical or important function, what is the target exit window? | "Sufficiently tested" needs a number to test against |
| Has any exit been rehearsed end to end, even at reduced scale? | A plan that has never run is a hypothesis |
| What would have to be rewritten rather than moved? | Separates a transfer problem from an architecture problem |
| Who owns the exit capability between tests? | Exit readiness decays silently as the estate evolves |
The Question This Exposes #
There is an uncomfortable possibility worth naming, because the January date will force it into the open.
If switching is free and exit is still not credible, then cost was never the binding constraint. The binding constraint was concentration — a critical function sitting on a provider it cannot practically leave, which is the precise condition DORA's third-party regime exists to surface, and the reason critical ICT third-party providers are designated and overseen at all.
That is not an argument for repatriating workloads. Cloud remains the right answer for most of what banks run, and a badly executed exit is worse than a well-managed dependency. It is an argument for knowing which of the two situations you are in, and being able to demonstrate it. The institution that can say "we tested a partial exit of this service, it took eleven weeks, here is what broke" is in a materially different supervisory conversation from the one that produces a forty-page document and an estimate.
The regulation has removed the excuse. It has not removed the problem, and it was never going to.
The Operating Playbook #
Five moves, and the first is not a contract review.
- Pick one critical or important function and cost the exit honestly — now, at the old prices. You want the number while egress still has a price, because it tells you how much of your reluctance was ever financial. Frequently the answer is: less than everyone assumed.
- Rehearse a partial exit. Not the whole estate. One service, one dependency, one restore into a second provider or on-premise footprint, with the clock running. The output is a duration and a defect list, which is what "sufficiently tested" is asking for.
- Inventory the terms that die in January. Switching charges, egress pricing, assistance obligations calibrated to them. Fold corrections into the renewal cycle rather than leaving unenforceable clauses in force by inertia.
- Separate transfer from rewrite, per workload. Two columns. What could move given free egress, and what would have to be rebuilt. The second column is your real exit horizon, and it is the number the board has never been given.
- Assign the capability an owner between tests. Exit readiness is a property of the current architecture, not a document with a review date. Without a named owner it degrades quietly with every sprint that adds a managed dependency.
Regulatory relief usually arrives as something removed. This one removes a number that has been standing in for an argument. The institutions that will look worst in 2027 are not the ones still on a single provider — most will be. They are the ones that spent two years telling supervisors cost was the obstacle, and have nothing to say in January when it isn't.
Frequently Asked Questions #
Does this mean cloud exit becomes easy?
No. It becomes free of switching charges, which is a different claim. The Data Act removes the transfer cost; it does not make a workload built on managed services portable. That remains a re-architecture, and it is measured in engineering quarters rather than euros.
What exactly is prohibited from 12 January 2027?
Switching charges, including charges for data egress. During the transitional period providers could recover only the costs directly linked to the switching process, with no markup; from that date they may not charge at all.
Hasn't something already been in force?
Yes. Since 12 September 2025 customers have had a statutory right to switch providers and to receive technical cooperation in porting their data. The January date closes the charging question specifically.
Where does DORA come into it?
Article 28(8) requires exit strategies for ICT services supporting critical or important functions, and requires them to be comprehensive, documented, sufficiently tested and periodically reviewed. Cost has been the practical reason the testing limb went unmet. That reason expires.
We are on one hyperscaler and will stay there. Does any of this apply?
Yes, and arguably more so. The obligation is to have a tested exit capability, not to exercise it. Staying is a decision; being unable to leave is a concentration risk, and after January you can no longer attribute the second to the price of egress.
What is the single most useful thing to do this quarter?
Rehearse a partial exit of one critical or important function and record how long it took and what failed. That artefact answers the supervisory question, sizes the real problem, and is worth more than any amount of further planning.
References #
- European Parliament and Council of the European Union, 2023. Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act). Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2023..
- European Commission, 2026. Data Act explained. Brussels: Directorate-General for Communications Networks, Content and Technology. Available at: European Commission, 2026..
- European Parliament and Council of the European Union, 2022. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2022..
- European Banking Authority, 2025. Guidelines on outsourcing arrangements. Paris: European Banking Authority. Available at: European Banking Authority, 2025..
Last reviewed .