Your Cloud Exit Just Became Free. It Did Not Become Possible.

What Actually Changes on 12 January 2027?

The EU Data Act, Regulation 2023/2854, was published in the Official Journal on 22 December 2023 and has applied since 12 September 2025. Most engineering organisations processed it, if they processed it at all, as an Internet of Things regulation about who owns the data your machine produces. That is Chapter II. Chapter VI is the one that will land on your infrastructure roadmap, and it has a date attached that is now less than five months away.

The headline provision is simple to state. Between January 2024 and January 2027 providers of data processing services have been permitted to charge for switching and data egress only up to the costs they directly incur, with no margin. From 12 January 2027, that allowance ends: the Commission's own summary confirms the Act will entirely remove switching charges, including charges for data egress, from 12 January 2027. Not reduce. Remove.

Around that headline sits a set of contractual obligations that are already in force and that most customers have not yet exercised. A customer may trigger a switch with a maximum of two months' notice, and the provider must complete the transition within a maximum of 30 days from the end of that notice period, extendable only where the provider can demonstrate the switch is technically unfeasible in that window. Providers must also remove pre-commercial, commercial, technical and contractual obstacles to switching, and maintain an up-to-date online register of their data structures, formats and interoperability specifications.

Enforcement is national rather than centralised, which is why it has attracted less attention than the AI Act. Each Member State designates a competent authority and, where it appoints more than one, a data coordinator as a single point of contact. There is no uniform cap of the kind GDPR sets: Article 40 requires only that national penalties be effective, proportionate and dissuasive, so the exposure depends on which Member State's regime you fall under, and several have chosen to sit theirs alongside their existing data protection enforcement machinery.

So the legal position on 12 January 2027 is that your provider may not bill you for leaving, must help you leave inside a defined window, and must publish enough about its formats that leaving is a describable exercise. That is a genuine and unusual amount of leverage handed to a customer. What it is not is a migration.

Why Did Free Egress Not Move Anybody Last Time?

There is a natural experiment for this, and it has already run. In January 2024 Google Cloud announced it would waive egress fees for customers leaving the platform. AWS followed in March 2024, and Microsoft moved on Azure in the same window, all three of them citing the incoming European rules with varying degrees of enthusiasm. The single largest quoted financial obstacle to leaving a hyperscaler was voluntarily removed by every hyperscaler, two and a half years before the law required it.

The migration wave did not happen. Two and a half years later, the market looks substantially the same, with a bit more hybrid at the edges. This is the most useful piece of evidence available about what January 2027 will and will not do, and it is worth understanding rather than explaining away.

Part of the answer is that the waivers were narrower than the headlines. They apply to a full account exit, not to the ongoing cross-provider traffic that a genuine multi-cloud architecture generates, which means the operating model most teams would actually adopt was never covered. But the larger part of the answer is that the egress bill was never the binding constraint. For a mid-sized platform, moving fifty terabytes was an unpleasant five-figure line item on a migration that was going to cost seven figures in engineering time. Removing the five figures does not change the decision.

The binding constraint is that you did not buy virtual machines. You bought a set of managed services whose behaviour, semantics and failure modes are now assumptions inside your application code, and there is no export button for an assumption. Your identity model is expressed in one provider's policy language. Your asynchronous workflows are that provider's queue semantics. Your data pipeline is its event format. Your on-call runbooks name its console. None of that is data, so none of it moves when the data does.

This is the gap the Data Act was drafted to close, and it is worth being precise about how far it actually reaches, because that determines how much of the work stays with you.

What Does Functional Equivalence Actually Oblige Your Provider to Do?

The Act draws a line that most summaries skip, and the line is where your engineering budget lives.

For Infrastructure-as-a-Service, the provider must take all reasonable measures to help you achieve functional equivalence on the destination service. For everything else, Platform and Software services, the obligation is to facilitate switching through open interfaces and compatibility with common specifications or harmonised standards. Those are very different promises. One is about the outcome you get after moving. The other is about the doors being unlocked on the way out.

Then there is what functional equivalence means, which is narrower than the phrase suggests. It is defined as a minimum level of functionality in the environment of a new service of the same service type after switching, and, crucially, it extends only to functionality that both the source and destination services offer. If you built on a managed service with no counterpart at your destination, the obligation does not conjure one. The provider owes you documentation, capabilities and technical support. It does not owe you a replacement for the thing that made you choose it.

The cloud industry's own trade bodies have said as much, and not gently. CISPE, which represents European cloud infrastructure providers, has argued that the concept remains vague and undefined and that it oversimplifies the nature of infrastructure services, calling for guidelines, codes of conduct and European standards to give it operational meaning. Legal analysis has framed the same tension as dynamism versus equivalence: cloud services change weekly, and a statutory duty to reproduce functionality sits awkwardly on a moving target.

Read that as an engineering leader rather than a lawyer and the conclusion is uncomfortable but clarifying. The Act removes the toll booth and requires the provider to hold the door. Whether your application can walk through the door is a property of your architecture, and no regulation is going to change that property on your behalf.

Where Does the Lock-In Actually Live in Your Architecture?

If you want to know what a switch would cost you, the honest exercise is not a spreadsheet of storage volumes. It is an inventory of the places where a provider's opinion has become your application's structure. In most estates they are the same six places.

Identity and access is usually the worst of them and the least visible. Roles, policies, service principals, resource-scoped grants and the conditional logic wrapped around them are a substantial body of engineering that exists only in one vendor's dialect. There is no export format. It is rewritten by hand, and it is rewritten by the people who understand your security model, who are the people you can least afford to allocate to a migration.

Data services come second. Managed relational databases move reasonably well when you stayed close to the open engine underneath, and move badly when you adopted the proprietary extensions that were the reason to pick them. Proprietary key-value and document stores, provider-specific query semantics and consistency models are the ones that end up rewritten rather than migrated. Few estates make this easy to see. Flexera's 2026 State of the Cloud report, a survey of 753 cloud decision-makers, finds 73% of respondents running hybrid cloud, up again on the previous year, which means the dependency graph a migration has to untangle already crosses more than one boundary before anybody proposes adding another. Teams cannot cost the move because they cannot see the graph.

Third is the asynchronous layer, the queues, topics, event buses and workflow orchestrators that quietly encode delivery guarantees, ordering semantics and retry behaviour into the correctness of your system. Fourth is serverless and the event glue around it, which is the highest-velocity and least portable code most organisations write. Fifth is observability, where the agents, the query language and every dashboard and alert built on top of them are a genuine multi-month rebuild that nobody puts in the estimate. Sixth is the commercial layer: committed-spend discounts and reserved capacity, which are not technical obstacles at all but which reliably decide the timing of a switch that the engineering has already made possible.

The pattern across all six is the same. The portable part of your system is the part you wrote to an open interface, and the expensive part is the part you wrote to a console. That ratio is a design decision, it is measurable today, and it is almost never measured until somebody asks how long a move would take and the honest answer is a shrug.

Is There Any Evidence Companies Will Use the New Leverage?

The demand-side signal is much stronger than the 2024 non-event would suggest, and it has changed character. Lock-in used to be a procurement grumble. It is now a board-level risk register item, largely because of sovereignty and pricing volatility rather than migration ambition.

A survey of 540 IT professionals across the United States, the United Kingdom and Germany, conducted in November 2025, found 94% of organisations concerned about vendor lock-in, with nearly half describing themselves as seriously worried. The cited drivers are revealing: 57% worried about future support and 46% about uncertain product roadmaps. That is not a complaint about invoices. It is a complaint about dependence on decisions made elsewhere. In the same survey 49% said they were considering or planning a shift back toward on-premises or hybrid models, and 84% reported data sovereignty concerns.

In regulated sectors the pressure is not sentiment at all, it is supervision. Financial entities under DORA have to maintain documented exit strategies for every critical ICT third-party provider and to test them, which turns portability from an architectural preference into an auditable control with an owner and a date. Once one regulator requires a tested exit, the capability tends to spread through the rest of the estate because nobody wants to run two standards.

Set against that, the counter-signal in the same Flexera data deserves respect. Wasted cloud spend stands at 29% and rose in 2026 for the first time in five years, which the report attributes to surging AI workloads, and generative AI is now the third most widely used public cloud service at 58%, up from 50%. Organisations are not, in aggregate, consolidating and simplifying. They are adding a fast-moving, expensive, deeply proprietary layer on top of an estate they already struggle to inventory. The leverage arrives in January. Whether anyone is in a position to use it depends on what gets built between now and then.

Does the Digital Omnibus Weaken Any of This?

Partly, and it is worth tracking rather than assuming, because the direction of travel in Brussels through 2026 has been simplification rather than expansion.

On 19 November 2025 the Commission published the Digital Omnibus, a package amending the Data Act alongside GDPR and the AI Act. On the switching chapter specifically, the proposal introduces simplified obligations for small and medium-sized and small mid-cap providers, and for bespoke services that were custom-developed or significantly adapted under contracts concluded before 12 September 2025. It would also permit proportionate early termination penalties in fixed-term contracts, provided they do not constitute an obstacle to switching, and it removes the prescriptive essential requirements that had been attached to smart contracts.

None of that touches the January 2027 abolition of switching charges for the providers most customers actually use. Analysis of the package reads it as trimming edge cases and reducing burden on smaller providers rather than dismantling the switching regime, and in any case it remains a proposal moving through the ordinary legislative procedure, not law. Planning on the assumption that the deadline slips is a bet against the one provision that has been stable since 2023.

There is a second development that matters more for day-to-day contracting. In November 2025 the Commission published modular standard contractual clauses for cloud and other data processing contracts, covering switching and exit, termination, security and business continuity, non-dispersion, non-amendment and liability. They are voluntary and non-binding, and they are the most useful artefact to come out of this regime so far, because they give a customer a drafted starting point instead of an argument. If you have a renewal between now and January, the clauses are the cheapest leverage available and the negotiation costs you nothing but attention.

One further date belongs on the same calendar even though it sits in a different chapter. The Data Act's data-access-by-design obligation under Article 3(1) applies to connected products placed on the market after 12 September 2026, which is three weeks from now. If your organisation ships hardware as well as software, that is a design requirement, not a policy one, and it applies irrespective of where the manufacturer is established.

Why Is the AI Stack Rebuilding Lock-In Faster Than the Law Removes It?

While the Data Act unwinds a decade of infrastructure lock-in on a fixed schedule, the layer being built on top of that infrastructure is re-establishing it at a speed no legislative timetable can match. It is worth saying plainly because the two trends are usually discussed by different people in different meetings.

The mechanisms are familiar and they arrive faster than they did in the infrastructure era. Capacity for accelerated compute is allocated through multi-year commitments, which converts a technical choice into a financial one before any code is written. Managed inference endpoints, vector stores, agent runtimes and evaluation tooling are proprietary by construction and mostly younger than three years, so there are no harmonised standards for them to be compatible with. Prompt and tool-calling behaviour is tuned per model family, which makes a swap a re-evaluation exercise rather than a configuration change. And the retrieval corpus, once embedded, has a gravity of its own.

The regulatory asymmetry is stark. Chapter VI applies to data processing services, and a managed AI platform is one, but functional equivalence is an IaaS duty, and open-interface compatibility presumes a standard exists. For most of the AI stack, the obligation resolves to little more than letting you export your data, which was never the hard part in the first place.

The practical implication is that the exit-readiness work worth doing now is not only about last decade's dependencies. The same discipline, an abstraction boundary you own, formats you can read without the vendor, and evaluation you can rerun elsewhere, is what keeps the AI layer switchable. Teams that build it once tend to apply it in both directions. Teams that treat portability as a compliance chore do it for the infrastructure they are bored of and skip it for the platform they are excited about, which is precisely backwards.

What Should You Actually Build Before January?

The goal is not to become cloud-agnostic. Lowest-common-denominator architecture is a real and expensive failure mode: you give up the managed services that justified the platform, you carry the operational burden yourself, and you end up slower on every axis in exchange for an option you may never exercise. The goal is to know your exit cost and to keep it deliberate.

Start with the dependency graph, because that is where the honest estimate lives and almost nobody has one. Produce a written inventory of every managed service in use, classified three ways: open engine behind a standard interface, proprietary but with a credible counterpart elsewhere, and genuinely singular. Attach an estimate in engineer-weeks to each entry in the second and third categories. That document is the exit cost, and until it exists every conversation about lock-in is a feeling rather than a number.

Then pick the boundaries worth paying for. Not all of them; the ones where the cost of abstraction is low and the cost of coupling is high. Identity, secrets, storage access, queue publication and observability instrumentation are usually worth an internal interface. Databases, in most cases, are worth staying close to the open engine rather than adopting the proprietary extension that saves a fortnight now. Kubernetes, Terraform or OpenTofu, OpenTelemetry and open table formats are not a strategy on their own, but they are the substrate on which a strategy is affordable.

Then make the provider do its share, which is the part almost nobody exercises. Request the register of data structures, formats and interoperability specifications that the Act obliges them to publish. Put the standard contractual clauses on the table at your next renewal. Ask, in writing, what functional equivalence means for the specific services you consume, and keep the answer. These are cheap actions with a legal basis behind them, and the response tells you more about your real position than any architecture review will.

Finally, test one thing for real. Not a plan, a rehearsal: stand up one non-trivial service on a second provider, run it under production-shaped load, and measure how long it took and what broke. A single rehearsal converts an unknown into a number, and the number is almost always different from the estimate in a way that changes the roadmap.

Who Should Do This Work, and When?

The awkward property of exit-readiness work is that it produces no features. It competes for the same senior engineers who are the constraint on everything else, it is invisible in the sprint review, and it can be deferred indefinitely without any immediate consequence. This is exactly why it is usually done badly and late, in the middle of a migration, by people under pressure.

It is also work that suits a dedicated team far better than a project team. The inventory is only useful if it stays current; the abstraction boundaries are only worth having if somebody defends them at code review for years; the rehearsal is only meaningful if the people who ran it are still around when the real switch happens. That continuity is the whole value, and it is the thing a rotating set of contractors structurally cannot provide.

This is the shape of engagement Stepto is built around. We put senior engineers in Serbia onto a product rather than a ticket queue, working Central European hours, which means the people who write down your exit cost are the same people who keep it from drifting, and they are available in the hours when your architects are also awake. Being inside the EU regulatory perimeter matters here in a way it does not for every kind of work: the Data Act, DORA exit testing and GDPR residency are the same constraints for our engineers as for yours, rather than clauses translated across a jurisdictional gap and a nine-hour offset.

On timing, the answer is that the useful window is now and it is roughly two quarters. The inventory is a matter of weeks. The boundaries are a design decision that costs almost nothing if made before the next twenty services are adopted and a great deal afterwards. The contractual asks land best at a renewal, and renewals are scheduled. What you cannot do is start in January, because on 12 January 2027 what you receive is an option, and an option is only worth what you are ready to do with it.