
The migration estimate lands on your desk with one line circled in red: data egress, the fee your cloud provider charges to hand your own data to a competitor. Somebody in finance has read that EU Data Act switching charges are being abolished. They're right. From 12 January 2027, providers of data processing services "shall not impose any switching charges on the customer for the switching process" [R1], and the legal definition of switching charges names data egress explicitly [R5].
Then look at the rest of the estimate. The egress line is one row. The other rows are engineering: re-pointing IAM, replacing a managed queue that has no equivalent on the other side, rewriting the jobs that assumed one vendor's storage semantics, running both stacks in parallel while you cut over. The law zeroes the first row. It says nothing about the others, and the Commission's Data Act FAQ says so in almost those words [R36].
EU Data Act switching charges are charges, "other than standard service fees or early termination penalties, imposed by a provider of data processing services on a customer for the actions mandated by this Regulation for switching to the system of a different provider or to on-premises ICT infrastructure, including data egress charges" (Regulation (EU) 2023/2854, Article 2(36)). [R5]
Key takeaways
What follows describes the published text of the Regulation and related official documents. It is not legal advice.
Data Act Article 29, in Regulation (EU) 2023/2854, is titled "Gradual withdrawal of switching charges", and it runs in two stages [R1] [R2].
The first stage is nearly over. "From 11 January 2024 to 12 January 2027, providers of data processing services may impose reduced switching charges on the customer for the switching process" [R2]. Reduced means capped: those charges "shall not exceed the costs incurred by the provider of data processing services that are directly linked to the switching process concerned" [R3]. A provider can recover what the move actually costs it. It can't make a margin on your departure.
The second stage is the one with the date on it. "From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process." [R1]
The date is not arbitrary. The Regulation was published in the Official Journal on 22 December 2023 and entered into force on the twentieth day after that, which is 11 January 2024 [R11]. The recitals say "Switching charges should therefore be abolished after three years from the date of entry into force of this Regulation." [R12] Three years from 11 January 2024 is where the January 2027 date comes from.
Don't compress this into "the Data Act starts in 2027". The Regulation "shall apply from 12 September 2025" [R11]. The switching rules, the contract terms and the capped-charge regime are live now. Only the zero lands in January.
The recitals are candid about why egress was singled out. "Unnecessarily high data egress charges and other unjustified charges unrelated to actual switching costs inhibit customers from switching, restrict the free flow of data, have the potential to limit competition and cause lock-in effects for the customers." [R12] The legislator's theory of lock-in is a pricing theory. Hold on to that, because it's the part the rest of this post argues with.
They apply to providers of data processing services, a category broad enough to cover IaaS, PaaS and SaaS, wherever the provider is established, when it serves customers in the EU [R7] [R8] [R10]. The definition is long and reads like a textbook description of cloud computing: "a digital service that is provided to a customer and that enables ubiquitous and on-demand network access to a shared pool of configurable, scalable and elastic computing resources ... that can be rapidly provisioned and released with minimal management effort or service provider interaction" [R7].
That covers more than infrastructure. Recital 81 names the three delivery models the concept includes: "Infrastructure as a Service (IaaS), Platform as a service (PaaS) and Software as a Service (SaaS)" [R8]. The Commission's FAQ, which is technical guidance and expressly not the Commission's official position [R37], goes further: Chapter VI "does not make a distinction between different types of SaaS, and thus applies to all SaaS types which display the characteristics listed in the definition" [R35].
A "customer" is "a natural or legal person that has entered into a contractual relationship with a provider of data processing services with the objective of using one or more data processing services" [R9]. Business customers count. This is not a consumer-only regime.
Geography doesn't get you out either. The Regulation applies to "providers of data processing services, irrespective of their place of establishment, providing such services to customers in the Union" [R10]. A SaaS company in Austin with customers in Amsterdam is inside the scope on the plain words of Article 1(3)(f). Whether a specific product meets the Article 2(8) definition is a fact question about how it's provisioned and sold, and it's the question to put to counsel.
Here's what isn't covered, and it matters for the close of this post. A development agency, a staffing firm or an engineering subscription writes code for you; it doesn't give you on-demand network access to a shared pool of elastic computing resources. On my reading of Article 2(8), that kind of vendor is not a provider of data processing services, and the switching rules don't bind it. The vendor evaluation scorecard uses the Data Act's notice and transition periods as a benchmark for dev-vendor exit terms for exactly that reason: a useful yardstick, never an obligation you can claim a dev shop is under.
If you read only Article 29(1), you'd conclude that leaving a cloud provider becomes free. It doesn't. The definition of switching charges carves two things out in its first clause: "other than standard service fees or early termination penalties" [R5]. The recitals and Article 34 add two more. Here are the four charges that remain lawful after the ban.
1. Standard service fees. "Standard service fees for the provision of the data processing services themselves are not switching charges. Those standard service fees are not subject to withdrawal and remain applicable until the contract for the provision of the relevant services ceases to apply." [R13] You keep paying for the service during the notice period and the transition. The Regulation says the contract "remains applicable" during the transitional period [R15].
2. Early termination penalties in fixed-term contracts. Nothing in the Regulation prevents "parties from agreeing on contracts for data processing services of a fixed duration, including proportionate early termination penalties to cover the early termination of such contracts" [R13]. If you signed a three-year committed-spend deal for the discount, a proportionate early termination penalty in it is not a switching charge, and the ban doesn't touch it. Providers have to tell you about these penalties before you sign [R4].
3. Egress for ongoing multi-cloud use. The ban covers switching. Running two providers side by side is a different activity under Article 34: "the providers of data processing services may impose data egress charges, but only for the purpose of passing on egress costs incurred, without exceeding such costs" [R14]. The FAQ states the consequence plainly: in cases of in-parallel use, "the provider may still bill the customer for the costs incurred for data egress, even after 12 January 2027" [R34].
4. Extra services you ask for. Providers can charge for "additional services that go beyond the provider's switching obligations" when those services "are performed at the customer's request and the customer agrees to the price of those services in advance" [R13]. And if you hire someone else to help with the move, that's your cost: "Nothing in this Regulation prevents a customer from compensating third-party entities for support in the migration process" [R13].
That fourth item is the quiet one. Hold it next to what the Regulation says about who does the actual moving: "the source provider of data processing services is responsible for extracting the data to a machine-readable format, but it is the customer and the destination provider of data processing services who are to upload the data to the new environment, unless a specific professional transition service has been obtained" [R51]. Extraction is the provider's job. Everything after extraction is yours.
The charges ban gets the headlines. The contract terms in Article 25 are the part you can use this quarter, because they have applied since 12 September 2025 [R11]. The contract must include at least:
If 30 days is technically unfeasible, the provider must tell you "within 14 working days of the making of the switching request", justify it, and propose an alternative that "shall not exceed seven months" [R17]. You, separately, have "the right to extend the transitional period once for a period that the customer considers more appropriate for its own purposes" [R18].
Providers must also point you to "an up-to-date online register ... with details of all the data structures and data formats" your exportable data comes in [R21]. It tells you what shape your data will be in when it leaves, which is the first input to sizing a migration. Ask for it before you need it.
Article 31 is where scope gets decided, and it's the article vendors will cite back at you.
The first exemption is for custom-built services. Article 29, among others, "shall not apply to data processing services of which the majority of main features has been 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, and where those data processing services are not offered at broad commercial scale via the service catalogue of the provider" [R27]. Both halves have to hold. A bespoke platform run for one client can still carry switching charges after January 2027. A catalogue product with a few customer-specific settings can't, and the recitals add that a provider who later deploys the service at scale "would have to comply with all obligations for switching" [R30].
The exemption is narrower than it looks. The FAQ is explicit that custom-built "does not mean that custom-built services are fully excluded from the scope of Chapter VI", and that such providers "must make open interfaces available and ensure that data are exported in a structured, commonly used and machine-readable format" [R33]. The provider also has to tell you, before you sign, which obligations don't apply [R29]. If nobody told you, that's a question for your contract, not an assumption to make in your favour.
The second exemption covers services "provided as a non-production version for testing and evaluation purposes and for a limited period of time" [R28]. A time-limited, non-production trial sits outside Chapter VI. Free-tier offerings are a different matter: Article 23 requires providers to remove obstacles to porting data "including after having benefited from a free-tier offering" [R50].
One more thing is moving. The Commission's Digital Omnibus proposal of 19 November 2025 would add lighter regimes for services "adapted by the provider to the specific needs of the customer" and for SME and small mid-cap providers, where the contract was concluded on or before 12 September 2025 [R38]. Both new regimes are drafted "with the exception of Article 29": the charges ban survives [R38]. The proposal's own recital says "switching charges, including egress charges, constitute a serious obstacle to switching" [R39]. As of 28 September 2026 the European Parliament's Legislative Observatory lists the procedure as "Awaiting committee decision" [R40]. It's a proposal, not law. Even the simplification package left the zero in place.
If you run on AWS, Azure or Google Cloud, 12 January 2027 changes less than the headline suggests, because all three have offered free egress to customers who leave since 2024.
The UK Competition and Markets Authority set out the sequence in its cloud market investigation: "on 11 January 2024, Google announced a global programme ... on 5 March 2024, AWS announced a similar programme ... on 13 March 2024, Microsoft announced that it also offers free egress globally for customers leaving Azure" [R44]. AWS said its waiver "follows the direction set by the European Data Act and is available to all AWS customers around the world and from any AWS Region" [R42].
The programmes came with conditions. As documented by the CMA: AWS customers had 60 days to complete their move; Google required customers to "move all their workloads and data out of Google Cloud and terminate their contract", except for partial migrations, within 60 days of approval; Microsoft required data out within 60 days and cancellation of "all Azure subscriptions associated with their account" [R45]. AWS has since extended its window: "Eligible customers will have 90 days to complete their move off of AWS." [R42] The CMA's view of the original 60 days was blunt: "unlikely to be a sufficient period of time to complete a switch for many customers" [R48].
Google went further in September 2025 with zero-charge transfers for multi-cloud workloads in the EU and UK. "Although the Act allows cloud providers to pass through costs to customers, Data Transfer Essentials is available today at no cost to customers." [R43] Only opted-in multicloud traffic qualifies; "all other traffic will continue to be billed at existing Network Service Tier rates" [R43].
So egress for leaving has been free since early 2024 at what the CMA calls "the three main cloud providers" [R44]. What happened next is the interesting part.
According to the CMA, "uptake of the free switching programmes has been low relative to the size of these cloud providers' customer bases" [R46]. The regulator offered candidate reasons, and two of them are the thesis of this post: "the egress cost to customers for switching may not be a factor influencing the decision to switch", and "there may be other factors deterring customer switching that the reduction in egress fee costs alone cannot overcome (for example, technical barriers)" [R46].
In fairness to the other side of the argument, the CMA also found the uptake data "inconclusive in terms of whether egress fees are or are not a barrier" [R46]. Low uptake doesn't prove egress didn't matter. It does mean nobody can point at 2024 and say that removing the fee set customers free.
Google, which is not a neutral party here, put it more sharply when it removed its own fees: "the cost for customers to migrate data out of a cloud provider is minimal" [R41]. Google's point was about licensing. The same sentence applies to architecture.
The Data Act's technical obligations explain why. The duty to help you reach "functional equivalence", meaning the destination service "delivers a materially comparable outcome in response to the same input" [R49], applies only to infrastructure providers: servers, networks and virtual resources "that do not provide access to the operating services, software and applications" [R22]. Recital 86 is explicit that there is no such obligation "for providers of data processing services other than those offering services of the IaaS delivery model" [R49]. PaaS and SaaS providers owe you open interfaces "free of charge" [R23] and, where no common standard exists, an export of "all exportable data in a structured, commonly used and machine-readable format" [R24].
And the limits are written in. Providers "shall not be required to develop new technologies or services, or disclose or transfer digital assets that are protected by intellectual property rights" [R25]. Exportable data covers your input and output data and metadata, "excluding any assets or data protected by intellectual property rights, or constituting a trade secret, of providers" [R26]. The FAQ closes the loop: no source provider has a responsibility "to assist the customer in rebuilding their data processing service in the environment of the destination provider" [R36].
You get your data in a readable format. You don't get your system. Your own code and configuration can travel as "digital assets", which the Regulation defines as "elements in digital form, including applications, for which the customer has the right of use" [R53]. What that code was built against doesn't travel: the queue semantics, the proprietary database features, the serverless triggers, the IAM model. Those are the provider's service, not your data, and making your code work without them is nobody's obligation but yours [R25] [R36]. That's my reading of how the pieces fit together, not a finding any regulator has published, but every piece of it is quoted above.
That is the lock-in that survives 12 January 2027. It lives in your repository, not on your invoice. If you've inherited a platform built on a dozen managed services, the egress fee was the cheapest part of leaving even before the law changed.
Everything above treats you as a customer. Turn it round.
If your product is SaaS with self-service provisioning and elastic capacity, and you sell to business customers in the EU, the FAQ's reading is that Chapter VI applies to you [R35], wherever you're incorporated [R10]. The obligations then run from you to your customers:
Penalties are set nationally. Member States "shall lay down the rules on penalties" and they must be "effective, proportionate and dissuasive" [R31]. The Commission must evaluate how Articles 23 to 31 are working by 12 September 2028, "with a special focus on SME providers" [R32].
In practice, this turns your export feature from a nice-to-have into a contractual deliverable. If your current export is a CSV of one table and a support ticket, check whether it covers "all exportable data", including metadata "directly or indirectly generated, or cogenerated, by the customer's use" [R26]. That's an engineering question before it's a legal one. If you ship software into the EU under your own name, the Cyber Resilience Act's Article 14 reporting duty is the other regulatory clock running this year.
The strongest version of the other side goes like this. The hyperscalers made switching egress free in 2024 [R44]. The CMA found low uptake [R46]. Your company isn't planning to move clouds, and if it were, the fee would be a rounding error next to the migration. The Omnibus may yet lighten Chapter VI for older contracts [R38]. So the date is a non-event.
Parts of that are right. For a customer of AWS, Azure or Google Cloud who plans a clean, full exit, the January date adds little beyond turning a voluntary programme into a legal floor. Google, for one, already calls that cost "minimal" [R41].
Where it goes wrong is in treating switching as something you do rather than something you can credibly threaten. The CMA made this point itself: lower barriers may not produce more switching, but "can also work to enhance the threat of switching and thereby increase the competitive pressure on cloud providers" [R47]. The threat only works if the exit is real on the engineering side too. A team that can't leave in 30 days plus one customer-chosen extension doesn't have much to bargain with at renewal, whatever the law says about fees.
And the steelman is silent on the other direction. If you're the SaaS provider, the date is not optional, and the export obligations have applied since September 2025 [R11].
None of this needs a lawyer to start. It needs an afternoon with your architecture diagram and your contracts.
The first four steps are reading. Steps 5 and 6 are engineering.
Step 5 is a scoped engineering task: a dependency inventory, a cost of replacement per managed service, a one-page answer to "could we leave in 30 days?". Dev On Demand isn't a data processing service and the Data Act doesn't govern it, but its own page reads "No lock-in" and "Cancel any time", with no notice period required, 100% IP ownership, and a flat $3,495/mo for one AI-augmented engineer on a 3-day task cycle [R52]. Start with the audit as one real task; if it turns up a migration, that's the kind of work the page lists as a typical ask [R52].
Before 12 January 2027, open the contract with your largest cloud provider and write down three things: the notice period, the transitional period, and the name of every service you'd have to rebuild to leave.
EU Data Act switching charges end on 12 January 2027. From that date, providers of data processing services "shall not impose any switching charges on the customer for the switching process" (Article 29(1)). [R1] Between 11 January 2024 and 12 January 2027 they may charge only reduced switching charges that do not exceed the costs "directly linked to the switching process concerned" (Article 29(2)–(3)). [R2] [R3] The Regulation as a whole has applied since 12 September 2025. [R11]
No. It bans egress charged as part of switching to another provider or to on-premises infrastructure. [R1] [R5] For in-parallel use of two providers, Article 34(2) still allows egress charges "only for the purpose of passing on egress costs incurred, without exceeding such costs", and the Commission's FAQ confirms these can be billed "even after 12 January 2027". [R14] [R34] Standard service fees and proportionate early termination penalties in fixed-term contracts are also outside the ban. [R5] [R13]
Yes, where the service meets the definition. The Regulation names SaaS alongside IaaS and PaaS as data processing service delivery models (Recital 81), and the Commission's FAQ says Chapter VI "applies to all SaaS types which display the characteristics listed in the definition". [R8] [R35] It applies to providers "irrespective of their place of establishment, providing such services to customers in the Union" (Article 1(3)(f)). [R10] Whether a given product meets the definition is fact-specific; this is not legal advice.
Yes, if the majority of main features were custom-built for an individual customer, or all components were developed for that customer, and the service isn't offered at broad commercial scale through the provider's catalogue (Article 31(1)). [R27] Custom-built services still owe open interfaces and export in a structured, commonly used, machine-readable format, and the provider must tell you before signing which obligations don't apply. [R29] [R33]
No. Infrastructure (IaaS) providers must take reasonable measures to help you reach functional equivalence; PaaS and SaaS providers owe open interfaces and a structured data export. [R22] [R23] [R24] The Commission's FAQ states that the Data Act "does not place a responsibility on any source provider to assist the customer in rebuilding their data processing service in the environment of the destination provider." [R36]