Data Act cloud switching requirements

Skip key takeaways

Updated August 27, 2026

• The exemption test is packaging, not law Article 31 exempts a service only where both limbs hold together, main features custom-built for one customer and not sold at broad commercial scale through the catalogue, and an engineering and product team can answer this today without waiting on counsel.
• The duty splits on a capability boundary, not a service-model label Article 30(1)'s open-ended equivalence duty and Article 30(2)'s bounded open-interfaces duty turn on whether a service hands the customer access to the operating system, software and applications running on the infrastructure, not on whether a vendor markets it as IaaS.
• Functional equivalence is defined in law and operationalised nowhere Article 2(37) supplies a legal definition built from shared features and a materially comparable outcome, but eleven queries and nineteen byte-level greps across roughly 2.4 million characters of primary text found no published standard that turns that definition into a testable threshold.
• An empty standards repository does not suspend obligations, it switches which one applies While the Article 35 repository stays empty, Article 30(5) requires exporting all exportable data in a structured, commonly used and machine-readable format at the customer's request, a live and buildable duty today rather than a gap waiting on the Commission.
• 12 January 2027 zeroes switching charges, not multi-cloud egress Article 29 removes charges for the act of switching, while Article 34 keeps at-cost egress charges for parallel multi-cloud use permanently in force with no expiry date, so ongoing multi-cloud egress never becomes free under this Regulation.

Copy takeaways

Is your service exempt before any of this applies

A service catalogue and a build record answer this before any lawyer needs to. Article 31 of the Data Act carves out data processing services whose majority of main features were "custom-built to accommodate the specific needs of an individual customer or where all components have been developed for the purposes of an individual customer", provided that same service is not also offered at broad commercial scale through the provider's own service catalogue. Both limbs have to hold together. A heavily configured product still sold off the shelf to other customers fails the second limb even where the configuration work for this one customer was extensive, and a service built once for a single client and never re-offered passes both.

Read the exemption's target list before assuming it changes nothing. It removes the switching-charge ban and both Article 30 duties for the one service that meets it. It does not touch the export duty that applies while the standards repository is empty, covered below, and it does not touch the ordinary notice and transitional-period mechanics a contract still has to specify if a customer ever leaves that service on ordinary terms.

This is a packaging question an engineering and product team can answer today, not a question that waits on counsel: does the catalogue list this as a shared SKU, and does the majority of what makes it work exist only because of this one customer? Answer both, and the verdict is EXEMPT from the switching-charge ban and both Article 30 duties. Answer either "no", and the next section decides which duty binds instead.

The test that decides your duty is a capability boundary, not a service-model label

A functional description the Regulation writes for itself decides the duty, not what the product page calls the service: whether the service gives a customer access to the operating services, software and applications running on top of the infrastructure, or stops at the infrastructure itself. A recital elsewhere names the IaaS delivery model as shorthand for the narrower case. The label is not the test. The Regulation's own words describe providers whose service is limited to "scalable and elastic computing resources limited to infrastructural elements such as servers, networks and the virtual resources necessary for operating the infrastructure", without handing the customer the operating system, software or applications layered on it. Those providers owe the open-ended equivalence duty under Article 30(1): take all reasonable measures toward the customer achieving functional equivalence on the destination service.

Every other data processing service, everything that does hand the customer that layer, owes a narrower and cheaper duty under Article 30(2) instead: make "open interfaces available to an equal extent to all their customers and the concerned destination providers of data processing services free of charge to facilitate the switching process". Publish the interface, do not charge for using it and the destination's own equivalence becomes the destination provider's problem rather than yours. A managed database service that exposes a proprietary query layer sits on the interface side of this line even where a vendor's own marketing calls the underlying compute IaaS.

Once a destination is chosen, everything downstream of this classification sits on top of an ordinary cloud migration, with these two duties layered over mechanics that guide already covers.

Verdict: IN under the equivalence duty if the capability description matches your service, IN under the open-interfaces duty if it does not.

The Regulation defines functional equivalence, and the definition names a test

"Undefined" is the wrong word, and using it hands away the article's sharpest fact for free. Functional equivalence has a definition, in Article 2(37), that turns on re-establishing a minimum level of functionality from the customer's exportable data and digital assets. Its operative test: the destination service "delivers a materially comparable outcome in response to the same input for shared features supplied to the customer under the contract".

What that definition is missing is not a legal meaning but an engineering threshold: nothing published anywhere states how close "materially comparable" has to be, measured how, on what inputs. That gap is the subject of the next section. This one is about the shape the definition already has, because the shape is real and it is bounded on three sides.

First, the definition's own shared-features clause bounds the duty to features both source and destination already offer independently. Second, a supporting recital confirms the duty stops short of rebuilding anything: a source provider is never obliged to rebuild its service inside the destination's infrastructure. Third, Article 30(6) sets a hard floor: no provider has to develop new technology or hand over intellectual property or a trade secret to discharge this duty.

Put together, functional equivalence is a bounded, shared-features comparison with no obligation to invent anything new on either side. That is a testable shape. What it is not, yet, is a testable number.

What is missing is the threshold, not the definition

Three different duties sit inside Article 30, and each one stays live even though a standard is missing. The equivalence duty in Article 30(1) is live today and has no published threshold, as the previous section established. A second duty, compatibility with repository standards under Article 30(3), is dormant, not because anyone decided to pause it but because its own two triggers, an implementing act published in the Official Journal and a reference published afterward in the standards repository under Article 35(8), have not happened. A third duty is live precisely because the repository is empty: where the relevant standards have not been published there, "the provider of data processing services shall, at the request of the customer, export all exportable data in a structured, commonly used and machine-readable format." An empty repository does not pause obligations. It switches which one applies.

The absence behind all of this was searched, not assumed. Eleven queries and nineteen byte-level greps across roughly 2.4 million characters of primary text, spanning the Commission's own standardization work, national and international standards bodies and two hyperscalers, found the phrase "functional equivalence" in exactly one document. That document is an industry consortium's own switching framework, and it uses the phrase only to restate the duty and then add a disclaimer that equivalence depends on each customer's individual use, which forecloses any universal threshold rather than supplying one.

A missing standard is not a missing obligation. It is missing proof of compliance for an obligation that already exists.

IAM roles, policies and permission boundaries

The five categories below are a mandatory checklist against your own provider's specification, because the Regulation requires that specification to exist in the first place. Article 25(2)(e) obliges the switching-terms contract to carry "an exhaustive specification of all categories of data and digital assets that can be ported during the switching process, including, at a minimum, all exportable data", and Article 26 separately requires an up to date online register of the data structures and formats a customer can expect to receive. AWS has already discharged both in public: portability cards for its key services and an online register of data structures and formats across more than two hundred services. The UK Competition and Markets Authority recorded AWS stating that it published these in line with EU Data Act requirements, timed to the Regulation's own application date. Test your own provider's specification against the five categories below before assuming a raw-data export closes the gap Article 25(2)(e) actually requires closed.

Identity and access management is the first casualty of a data-only export. A customer relationship's IAM roles, the policies attached to them, service accounts and the permission boundaries that scope what a role can touch are not files anyone thinks to back up, because nobody edits them the way they edit a table. They are also the layer a destination environment cannot reconstruct from data alone: a rebuilt warehouse with no equivalent role structure is a warehouse anyone with a valid login can read in full. A specification worth the name lists role definitions, attached policy documents, trust relationships and the boundary conditions that limit what a role can assume, not a note that access controls exist.

Pipeline and orchestration definitions

A pipeline definition is a distinct asset from the data it moves, and an export that stops at tables leaves the orchestration invisible. CI/CD job definitions, the DAGs a scheduler runs, retry and backoff policies and the trigger conditions that decide when a job fires are configuration objects that live in a provider's proprietary orchestration service as often as they live in version control a customer actually owns. Where they live only in the provider's console, Article 25(2)(e)'s exhaustive specification has to name them as a category or the customer has no way to know they were excluded.

A destination environment that receives the underlying data but not the pipeline that produced it has to reconstruct the transformation logic from scratch. Test this against your own stack: can you list every job definition your provider's orchestration layer holds, independent of its own UI, in a format you could hand to a different scheduler? If the honest answer is "only by screenshotting the console", the specification has a gap Article 25(2)(e) does not permit.

Metastore, schema and catalog metadata

A table's data can move while everything that makes the table legible stays behind. Metastore entries, schema definitions, partitioning and indexing rules and the catalog metadata that tells a query engine what a column means are frequently stored separately from the data itself, in a provider-specific catalog service with no standard export format. A destination database that receives rows with no partition scheme and no column-level documentation has received a dataset, not a system.

This is where the exclusion in Article 2(38), covered in full in the derived-artefacts section below, starts to matter for real rather than theoretical reasons. A proprietary indexing algorithm's internal state is a plausible candidate for that exclusion. A customer's own schema definitions and partition keys, which the customer wrote, are not, and a specification that folds them into an unnamed system-data bucket is worth challenging.

Network topology and federated identity trust

A destination environment depends on the network working before anything else does, and network configuration is the category most reliant on tribal knowledge rather than any exported file. VPC peering connections, subnet layouts, DNS records and zones and the federated identity trust relationships that let a workload in one environment authenticate against an identity provider in another are infrastructure-as-code artefacts where they exist at all, and console-only settings where they do not.

Federated trust is the sharper case. A customer that authenticates workloads through a provider-hosted identity federation has a trust relationship that is, by construction, specific to that provider's identity service. Reconstructing it on a destination requires re-establishing the trust chain, not exporting a file, and no vendor's single export button attempts this. An exhaustive specification under Article 25(2)(e) that lists only data assets and silently excludes network and identity configuration has excluded a category a customer needs to actually operate on the destination side.

Derived artefacts, materialised views and trained models

A trained model, a materialised view and a precomputed aggregate table share one property: each was derived from the customer's data by computation the customer paid for, and none of them is the customer's raw data. Whether they count as exportable data under the Regulation is where the export duty meets its sharpest limit.

Article 2(38) draws that limit as a boundary, not a footnote. Exportable data is input and output data, including metadata, generated or cogenerated by the customer's use of the service, but the definition excludes anything protected by intellectual property rights or constituting a trade secret, whether that protection belongs to the provider of the service or to a third party. A model a customer trained on its own data, using a provider's compute, is output data the customer generated, a plausible export candidate. The provider's own model architecture, a proprietary training method, or a third party's licensed component embedded in the pipeline is a different asset, and the trade secret and IP carve-out reaches it regardless of whose infrastructure it ran on.

Article 25(2)(f) gives a provider a legitimate route to name these exclusions up front, specifying categories exempted from export where a genuine trade-secret risk exists, provided the exemption does not impede or delay the switching process itself. A specification that exempts every model without distinguishing what the customer trained from what the provider built has used that exemption as cover for a broader exclusion than the article actually permits.

A free-egress program is not the statutory route

A support ticket is not a contractual right, and the distinction is the whole content of this section. Google, AWS and Microsoft each run a free-egress program, and each shares the same shape: the customer files a request, a support team reviews it at the account level, the provider approves or declines and a credit lands on a later invoice sized against a snapshot of the data present when the request was filed. None of the three changes a price up front. All three are revocable, all three are scoped to specific products rather than a whole account's egress and none funds the temporary dual-running a real migration actually requires, because the credit is calculated once against one snapshot. AWS has said plainly that its own support review exists because it cannot otherwise tell a routine transfer from a switch. The UK Competition and Markets Authority, working from information the three providers were compelled to disclose, found eligibility "largely at the discretion of the providers" with decisions run through customer support teams rather than an automated eligibility check, and that none of the programmes specify any customer dispute mechanism.

The statutory route looks nothing like this. A switch initiated under the Data Act runs on a contractual clock: a maximum two-month notice period, then a mandatory 30 calendar day transitional period during which the source provider keeps the service running. Where that period is technically unfeasible, Article 25(4) requires that the provider of data processing services "shall notify the customer within 14 working days of the making of the switching request, and shall duly justify the technical unfeasibility and indicate an alternative transitional period", capped at seven months, with one further extension the customer alone can trigger. AWS's own EU Data Act Addendum reproduces this structure almost clause for clause, as a contract rather than a webpage, which is the clearest evidence available that the addendum is the statute rendered into terms. AWS's free-egress marketing program was announced in the first half of 2024; the EU Data Act Addendum is a later, separate contractual instrument. Writing switching terms into a contract before a vendor forces the issue, rather than waiting on a support queue, is systems and contract work our own cloud migration and services practice does alongside a move.

Filing a support ticket for a credit is not exercising a switching right. It is asking a vendor for a discount, on terms the vendor can change at will.

What the deadline does not do

Zero and free are not the same word, and the Data Act only uses one of them for one specific thing. As of 12 January 2027, "providers of data processing services shall not impose any switching charges on the customer for the switching process." That is Article 29, and it zeroes exactly one category: charges for the act of switching itself. Article 34 governs a separate situation, running a service in parallel with another rather than leaving it, and it survives the same deadline untouched: "the providers of data processing services may impose data egress charges, but only for the purpose of passing on egress costs incurred", capped at cost rather than zero, with no expiry date attached anywhere in the text. Multi-cloud egress does not become free on 12 January 2027. It becomes at-cost, permanently, which is a materially cheaper outcome than today's marketing-program pricing but not the free outcome most coverage of the deadline implies.

The asymmetry sitting next to that correction is worth stating plainly rather than resolving. As of the live Azure documentation, a customer with a UK billing address gets a 180 day switching window, the right to leave a single Azure service rather than the whole account and routing over Microsoft's premium global network. A customer with an EU billing address, on the same page, gets 60 days, a full-account-only exit and ordinary ISP routing. The UK terms arrived through commitments Microsoft and AWS gave the UK Competition and Markets Authority on 31 March 2026, accepted in place of a formal market-status designation. Whether the EU's deadline caused, or is simply unrelated to, that gap is not stated by either source. Both facts are real, and a reader planning a 2027 switch should know both before assuming the law with the harder deadline produced the better terms.

Why a timed exit drill does not evidence functional equivalence

The general architecture for a rehearsed exit, portable formats and vendor abstraction already has a page: our DORA exit-strategy coverage treats those as a resilience discipline, and nothing in this section repeats it.

What a resilience drill measures is elapsed time: how long it takes to stand a workload up somewhere else, starting from an export and ending when the replacement is serving traffic. That is a useful number and it is not the number Article 2(37) asks for. The definition names a comparison, not a duration: the destination service must deliver a materially comparable outcome in response to the same input for shared features supplied under the contract. A drill that finishes in four hours and a drill that finishes in four days both answer how fast, and neither one, on its own, answers how equivalent.

What the second question needs is a differential record the first drill does not produce by default: a fixed input set run against both the source and the destination, the list of features the two services actually share rather than the union of everything either offers, the recorded outcome on each side for every input in that set and a stated threshold for what counts as materially comparable decided before the drill runs, not decided afterward by whichever result came back. Build that alongside the timed rehearsal, and the same exercise answers both questions at once. Skip it, and a fast, well-rehearsed exit still leaves functional equivalence unproven, because nobody measured the one thing the definition actually names.

Escrow of the transformation logic, verified by an independent rebuild

Escrow with independent rebuild verification borrows from an established discipline. Software escrow arrangements already store source code or configuration with a third party and periodically prove, through an actual rebuild, that what is stored is enough to reproduce the system without the original vendor's help. A byte-level search of the switching chapter turns up no instance of the words escrow or verification.

Applied to a cloud switch, what gets escrowed is not a data dump. It is the transformation logic that turns the raw export from the five categories above into a working destination environment: the IAM provisioning scripts, the pipeline definitions, the schema and catalog rebuild steps, the network and trust configuration and the rules that decide which derived artefacts get regenerated rather than exported. The verification is that a party who was not involved in building the original system can take that escrowed logic and the raw export, and produce an environment a domain expert would call materially comparable to the source, on a schedule, not only once at signing.

That record is this article's own answer to the question no regulator has answered: not a certificate nobody can issue, but a rebuild a third party actually performed, with its inputs, outputs and threshold written down before it started.

The strongest fact available closes the argument better than any recommendation could. AWS's own EU Data Act Addendum, the contract it wrote specifically for this switching duty, uses the word "switching" thirty-nine times. It uses the phrase "functional equivalence" zero times. The one published contract written for this Regulation is silent on the one duty with no threshold.

Sources: Regulation (EU) 2023/2854 (Data Act), Official Journal text via EUR-Lex, Articles 2(37), 2(38), 23(d), 25, 26, 29, 30, 31 and 34; the UK Competition and Markets Authority's Appendix N, Egress fees and free switching programmes, final version, 1 August 2025, and its actions on cloud and business software, 31 March 2026; AWS's free data transfer out blog post and its EU Data Act Addendum; and Microsoft's Azure subscription cancellation and egress terms. Read on 27 August 2026. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel.

FAQ

Last updated: August 27, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 5

• ★ Featured question. Does the Data Act require functional equivalence if the destination has no equivalent service?

  Copy link Copies a direct link to this answer to your clipboard.

  The duty is bounded to features both the source and destination already offer independently, so a provider cannot be required to match a feature the destination never had. Article 30(1) obliges an IaaS-type provider to take all reasonable measures toward equivalence where a comparable destination service and comparable features exist, but a supporting recital confirms the source provider is never obliged to rebuild its own service inside the destination's infrastructure, and Article 30(6) confirms no provider has to develop new technology to close the gap.

  Where no destination counterpart exists at all, the duty has nothing to measure equivalence against.

• Is my service exempt because it is custom-built for one customer?

  Copy link Copies a direct link to this answer to your clipboard.

  Only if both limbs of Article 31 hold together, not one. The service's main features must be custom-built for that individual customer, and the same service must not also be offered at broad commercial scale through your service catalogue.

  A heavily customized product still sold to other customers from the same catalogue fails the second limb even where the customization work was extensive. Passing both limbs removes the switching-charge ban and both Article 30 duties, but it does not remove the export duty that applies while the Article 35 standards repository remains empty.

• What can a provider still charge for after 12 January 2027?

  Copy link Copies a direct link to this answer to your clipboard.

  Charges for the act of switching itself go to zero under Article 29, but egress charges for running a service in parallel with another provider are a separate matter under Article 34 and stay permitted at cost, with no expiry date in the text. Multi-cloud use, as opposed to a one-time exit, does not become free on that date.

  It becomes capped at the provider's actual cost, which is materially cheaper than most current marketing-program pricing but not the same as free.

• Does using a vendor's free egress program count as exercising Data Act switching rights?

  Copy link Copies a direct link to this answer to your clipboard.

  No. A vendor's free-egress program is a discretionary, revocable product decision reviewed by a support team at the account level, sized on a data snapshot and scoped to specific products, and the UK Competition and Markets Authority found that none of the three major programmes specify any customer dispute mechanism. The statutory switching right runs on a different, contractual mechanism: a maximum two-month notice period and a mandatory 30 calendar day transitional period, extendable only where technical unfeasibility is justified in writing within 14 working days.

  Filing a support ticket for a credit is not the same act as exercising that right.

• What has to be in the contract before a switch is possible?

  Copy link Copies a direct link to this answer to your clipboard.

  At minimum, the notice and transitional-period terms Article 25 requires: the maximum notice period, the mandatory transitional period and the process for extending it where technically unfeasible, plus an exhaustive specification of every category of exportable data and digital asset the customer can port, not only the raw data. A provider's own switching addendum, where one exists, is the clearest evidence that these terms have actually been written into a contract rather than left to a webpage that can change without notice.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.