EU Data Act Cloud Switching: Your Customers Get An Exit On 12 January 2027

A customer gives two months' notice, asks for everything they are entitled to take with them, and expects to be running somewhere else within thirty days. You cannot charge them for it.

That is the position from 12 January 2027, and EU Data Act cloud switching obligations apply to software as a service as much as to infrastructure, which is the part most product teams have not registered. The legal analysis of this is widely available and well written. What is missing is anyone saying what has to be built, so this article is about that. It is not legal advice, and whether the regulation applies to your particular service is a question for a lawyer rather than for an engineering blog.

What changes, and on what date

The EU Data Act has been applicable since September 2025, and its switching provisions land in stages.

Until 12 January 2027, a provider may charge for switching, but the charge cannot exceed the costs directly incurred in performing it. That already rules out egress fees priced as a commercial deterrent rather than as cost recovery.

From 12 January 2027, switching charges are prohibited entirely. Not capped, not limited to cost, but removed. A customer moving to another provider or back to their own infrastructure cannot be billed for the act of leaving.

Alongside that sit obligations that arrive with the customer relationship rather than on a date. A customer can initiate a switch on two months' notice or less, effectively ending the contract early. Contracts have to carry terms describing the switching mechanics and any fees, and certain information has to be given before the contract is signed. And the provider has to support the move within a transition period of 30 days, extendable where the move is genuinely not technically feasible in that time, up to a maximum in the region of seven months.

The scope covers data processing services, which reaches infrastructure, platform and software services offered to customers in the EU. Plenty of teams read the early coverage, concluded it was about hyperscalers, and stopped. That reading is worth revisiting.

Switching charges going to zero is the smallest part

Removing a fee is a billing change. It can be done in an afternoon and most providers will do it late and without difficulty.

The obligations that cost real money are the ones that assume a capability exists. A customer who can leave in thirty days can only do so if there is something to leave with, and that means the export has to be complete, structured and usable by a competitor. A regulator or a customer's counsel reading your terms will find the charge removed. A customer actually exercising the right will find out whether the capability is real.

The commercial framing worth holding on to is that this is not only a compliance cost. Once every provider in a market must let customers leave without charge, the friction that retained some accounts stops working. What retains customers afterwards is the product. Teams that treat this as a lock-in problem tend to build the minimum and lose the accounts anyway. Teams that treat it as a portability feature tend to find it useful in sales, because a buyer who can see the exit is more willing to walk in.

One clarification is worth making because it recurs in every discussion of this. Switching without charge does not mean switching without effort on the customer's side, and it does not oblige a provider to make a competitor's product work. The duty is to release what the customer is entitled to, in a usable form, within the window, and to describe the formats and interfaces involved. It is not a duty to guarantee that everything behaves identically once it arrives somewhere else. That distinction matters when scoping, because teams reading the requirement at its most expansive occasionally set out to build a migration service for products they do not control.

Data is the easy half, digital assets are the hard one

The regulation contemplates a customer porting the data and the digital assets they have the right to use, and the distinction between those two is where the engineering effort concentrates.

Data is the records. Customers, transactions, documents, messages, whatever your service holds on their behalf. Most teams have some version of this already, and where they do not it is a well-understood problem: enumerate the tenant's rows, serialise them in a documented structure, deal with volume and with references to files in object storage.

Digital assets are everything that makes the service theirs rather than merely a database. Configuration, workflow definitions, permission models, custom fields, templates, rules, integrations, dashboards, saved views, automations. These live in the shape of your platform. They are frequently expressed in internal identifiers, they reference features a competitor does not have, and in many products they have never been serialised at all because there has never been a reason to.

Three practical problems come out of that, and they are worth confronting deliberately.

Internal identifiers travel badly. An export full of your own primary keys is technically complete and practically useless. Anything a customer might reasonably map to another system needs a stable, meaningful identifier alongside it.

Structure has to be documented, not merely present. A well-formed file in an undocumented shape is an obstacle wearing the clothes of compliance. Publishing the schema of your export is a small piece of work that changes the character of the whole thing.

And some configuration genuinely has no equivalent elsewhere. The honest response is to export it in a readable, documented form and say what it represents, rather than to omit it because no competitor consumes it.

Thirty days is an engineering requirement, not a contract term

Legal summaries describe the transition period as a contractual obligation. Treat it as a performance requirement with a number on it, because that is what it becomes when someone exercises it.

The test is straightforward to state. Take your largest tenant. Run a complete export. Measure how long it takes, whether it completes, and whether anyone has to intervene. If your answer is that it has never been attempted at that size, that is the answer.

Several things fail predictably at large tenant scale. An export implemented as a synchronous request will time out. One that holds a transaction open long enough to produce a consistent snapshot will affect other tenants on shared infrastructure. One that assembles everything in memory will exhaust it. And an export that takes eleven days of wall clock time to produce technically fits inside thirty days until you remember that the customer then has to load it somewhere and verify it.

The design that survives is unremarkable and worth building once: an asynchronous, resumable job that writes incrementally to object storage, produces a manifest describing what it contains and the point in time it represents, and can be re-run to capture the delta after a cutover. That last property matters more than it appears, because a real migration is not a single copy. It is a bulk transfer followed by a catch-up.

Consistency deserves an explicit decision rather than a default. An export assembled over hours from a live system is not a single point in time unless something makes it one. Say what the guarantee is, record it in the manifest, and make it something a customer can rely on.

One further requirement belongs with the export rather than beside it, and it is easy to leave until last: evidence. A switch that has been completed needs to be demonstrable afterwards. What was exported, when, at what point in time, to whom it was delivered, and when the customer confirmed receipt. That record protects both parties, and it is the difference between a dispute resolved in an afternoon and one resolved by reconstructing server logs six months later. Build it as part of the orchestration rather than as a reporting task, because the information is only cheap to capture while the job is running.

Existing contracts do not update themselves

This is the point most likely to be missed inside a busy company, and it produces a nasty surprise.

Contracts already in force do not automatically acquire the new terms on 12 January 2027. They have to be amended, allowed to terminate on schedule, or renewed onto compliant terms. That is a commercial and legal exercise across an existing customer base, and it needs owners and a timeline in the same way the engineering work does.

The engineering consequence is a timing one. If the contract remediation programme runs into late 2026, and the export capability is not finished until then either, the company is doing both at once during the quarter when sales is also closing its year. Sequencing the build ahead of the paperwork gives the commercial team something real to point at while they are renegotiating, which is a materially easier conversation than promising a capability that does not exist yet.

There is also a question of who owns this internally, and it is genuinely awkward. The obligation is legal, the capability is engineering, the decisions about what a configuration export should contain are product, and the contract remediation is commercial. A programme with no single owner across those four tends to stall at the first decision that needs two of them, which in practice is usually the digital asset question. Name an owner early, and give them the authority to settle what an export contains without convening everyone.

What this does to your architecture

The difficulty of all of the above is decided almost entirely by one thing that was settled long ago, which is how cleanly a tenant's data is separated from everyone else's.

A platform with a genuine tenant boundary, whether that is a database per tenant or a rigorously enforced tenant column with no exceptions, can enumerate a customer's holdings with confidence. Export becomes a large but ordinary piece of work.

A platform where the boundary has eroded is in a harder position. Shared reference data that has been quietly customised for one customer, cross-tenant lookups added for a reporting feature, a table without a tenant key that a background job populates: each of these turns a mechanical export into a series of judgement calls about what belongs to whom. Those judgements are slow to make and risky to get wrong, since exporting another customer's data into a tenant's archive is a considerably worse problem than being late.

There is a useful side effect here. The work required to answer the question is the same work required to answer a procurement questionnaire about tenant isolation, and increasingly the same work required to respond to a data subject access request with confidence. Teams that scope this narrowly as a Data Act task frequently find they have paid for three things and only counted one.

A final architectural note concerns derived state, which is where late surprises concentrate. Search indexes, materialised views, caches, analytics tables and machine learning features are all built from tenant data and all hold a copy of it. Most of that does not need to be exported, since a customer can rebuild it elsewhere from the source records. But two questions have to be answered for each: does it contain anything that exists nowhere else, and is it deleted when the tenant leaves. The first decides whether it belongs in the export. The second is a separate obligation that arrives at the same moment, because a customer who has switched away is entitled to expect that the copies go too.

What EU Data Act cloud switching compliance costs, with the hours shown

Here is the rate, the hours and the multiplication.

The rate band for this work is $40 to $100 per hour by seniority. Administrative surfaces and reporting sit near the floor, tenancy and data architecture near the ceiling. Mixed teams blend to about $65.

The scope below assumes a multi-tenant platform with an intact tenant boundary. Where that boundary has eroded, add a remediation phase before any of it.

Module	Hours
Scope assessment and tenant data inventory	60
Full data export, asynchronous and resumable	190
Digital asset and configuration export	150
Switching orchestration, notice, status, completion	170
Documented export schema and format publication	120
Contract terms, pre-contract information, fee removal	90
Audit trail and evidence of completion	90
Total	870 hours

Eight hundred and seventy hours runs $34,800 at $40, $87,000 at $100, and $56,550 at the $65 blend.

Two things move that number materially. Whether the tenant boundary holds, since remediation is its own project and can exceed the export work. And how much of your product's value is expressed as configuration rather than as records, because a highly configurable platform has far more to serialise than a simple one.

A sequence that works backwards from January

Start with the inventory, because it is cheap and it determines everything else. Enumerate what a tenant actually owns across every store, including object storage, search indexes, caches holding derived state, and anything a background job writes. Teams routinely find two or three stores nobody had counted.

Build the data export second, asynchronous and resumable from the start, and test it against your largest tenant rather than a convenient one. An export proven on a small account has proven nothing about the requirement.

Take digital assets third, and accept that this is where product decisions are required rather than only engineering ones. Somebody has to decide what a workflow definition means outside your platform, and that person is not a backend engineer working alone.

Publish the schema fourth. It is a small task with a disproportionate effect on whether the export is genuinely usable, and it is visible evidence of good faith.

Leave the billing change and the contract terms until last, because they are quick, and doing them first creates an obligation you cannot yet meet.

Working backwards from 12 January 2027, a programme of this shape wants to start no later than the autumn of 2026 to leave room for the contract remediation to run alongside it without colliding with a year end.

Two questions are worth answering this quarter. Can you produce a complete, documented export for your largest tenant today, and how long does it take. And does your tenant boundary hold everywhere, or are there tables and jobs that quietly cross it. The first is a measurement. The second decides the size of the project.