Switching Charges End on 12 January 2027. Lock-In Does Not.

On 12 January 2027, cloud switching charges become unlawful across the European Union. Article 29(1) of Regulation (EU) 2023/2854, the Data Act, states that from that date providers of data processing services "shall not impose any switching charges on the customer for the switching process" [W1]. Egress fees, exit fees, transfer charges. All of it, gone.

Most commentary reads this as straightforwardly good news for customers, and in a narrow sense it is. But there is a harder question sitting underneath, and it is the one worth preparing for now rather than in January. If the egress fee was the reason a workload has not moved in four years, that reason is about to expire. If it was not the reason, an organisation is about to discover what the real one was, in public, in front of a board that has read the same headlines.

This article sets out precisely what the law requires, separates that from the professional interpretation around it, and then deals with the part the legal commentary tends to skip: the costs of switching that no regulation can remove.

Chapter VI of the Data Act, Articles 23 to 31, governs switching between data processing services [W3]. It is worth being exact about the mechanics, because several of the timeframes are commonly misquoted.

The charges. Article 29 sets out a two-stage withdrawal. From 11 January 2024 until 12 January 2027, providers may impose reduced switching charges, capped so that they do not exceed the costs the provider directly incurs in facilitating that particular switch. From 12 January 2027, no switching charge may be imposed at all [W1].

The timeframes. Article 25 requires that contracts include a maximum notice period for initiating a switch of no more than two months, and a mandatory maximum transitional period of 30 calendar days in which the switch must complete. Where a 30 day transition is technically unfeasible, the provider must notify the customer within 14 working days and propose an alternative period, which may not exceed seven months. Customers also hold a right to extend the transitional period once, for a period they consider more appropriate. After the transition ends, a data retrieval window of at least 30 calendar days applies before the provider may erase the data [W2].

The transparency duties. Article 26 obliges providers to give clear information about switching procedures and their costs. Article 28 requires contractual transparency about international access and transfer. Article 30 covers the technical aspects of switching, including the concept of functional equivalence [W3].

What is exempt. The ban covers switching charges. It does not cover standard service and subscription fees, proportionate early termination fees in fixed-term contracts, or separately agreed support beyond the regulatory switching scope. Nor does it apply to in-parallel use, which is the multi-cloud case where a customer runs two services alongside each other rather than moving from one to the other [S01][S02].

That is the law. Everything that follows about what organisations should do in response is professional interpretation and analysis, including Atomity's own, and a qualified legal review of a specific contract remains necessary.

Two paragraphs of Article 29 deserve more attention than they have received.

Article 29(5) provides that, where relevant, providers "shall provide information to a customer on data processing services that involve highly complex or costly switching or for which it is impossible to switch without significant interference in the data, digital assets or service architecture". Article 29(6) requires that this information be published, for customers, in a dedicated section of the provider's website or in another easily accessible way [W1].

Read plainly, that is a legal obligation on providers to publish a list of the things a customer will struggle to leave. Some providers have interpreted the scope narrowly and some more broadly, and the phrasing leaves real room for argument. But the practical consequence is available today, before the deadline: for each provider in an estate, a team can go and read what that provider has itself chosen to disclose about where switching is hard.

This is a short exercise with an uncomfortable output. It produces, in the provider's own words, a map of the surfaces where an organisation is most committed. That map is considerably more useful for planning than an internal estimate, because it will also be the document a provider points to later if a switch turns out to be harder than a customer expected.

The egress charge is the most visible cost of leaving a cloud provider, which is why it became shorthand for lock-in. It is rarely the largest. When switching costs are decomposed, four categories consistently dominate, and none of them are addressed by Article 29.

Architectural coupling. A workload built on a managed queue, a proprietary serverless runtime, a provider-specific identity model or a managed database with non-standard extensions is not portable in the sense the Data Act contemplates. Moving it is not a transfer, it is a rewrite. The deeper the estate has gone into managed services, the more of the cost of switching sits in engineering time rather than in any invoice.

Operational re-platforming. Scaling policies, observability, incident tooling, infrastructure-as-code modules, network topology and the accumulated operational knowledge of the team are all provider-shaped. These do not transfer, and the cost of rebuilding them is paid in delivery capacity that is not going into the product during the transition.

Commitment residue. Reserved instances, savings plans and committed-spend agreements can outlast the decision to leave. An organisation twenty months into a three year commitment carries a real financial obligation that is untouched by the removal of switching charges, and early termination fees in fixed-term contracts remain permitted [S01].

Evidence and re-certification. In regulated sectors, a workload that carries an audit history, a set of approved controls and a documented compliance position does not arrive at a new provider with that history intact. Rebuilding the evidence trail is work, and in some cases it is the longest pole.

The point is not that switching is impossible. It is that the invoice line everyone could see was never a good proxy for the constraint that actually binds.

This does not have to be argued from first principles, because a version of it has already happened.

In January 2024, the three largest providers introduced global free switching programmes, under which a customer leaving for another provider could move their data out without paying egress charges. In other words, for switching purposes, the fee went to zero roughly three years before the Data Act required it to.

The United Kingdom's Competition and Markets Authority examined those programmes as part of its cloud services market investigation, which concluded on 31 July 2025 [S08].

Start with what the CMA concluded about egress fees themselves, because it cuts against the argument being made here and should be stated first. In its final decision the CMA found that "a key commercial barrier is the presence and magnitude of egress fees required to transfer data between cloud providers for the purposes of switching and/or multi-cloud" [S08]. The regulator did not think egress fees were trivial. It thought they mattered enough to name them as a barrier to competition.

It also found that "very few customers switch between clouds: less than 1% of customers switch provider each year" [S08].

Now the part that is harder to square with a simple story. Examining the free switching programmes specifically, the CMA reported that providers' own submissions "appear to indicate that use of the free switching programmes has been low to moderate since January 2024", with a material share of requests deemed ineligible or incomplete [S06]. And it concluded that "there may be other factors deterring customer switching that the reduction in egress fee costs alone cannot overcome" [S06].

Customer evidence to the investigation emphasised time, complexity and operational disruption. One financial institution estimated a switch at twelve months and approximately a thousand employees. A retailer described timelines from more than a month for simple workloads to over a year for complex ones [S06].

Read together, the two findings say something more precise than either alone. Egress fees were a real barrier, significant enough for a competition authority to act on. They were also not the only one, and removing them did not by itself produce switching.

Some caution is warranted. The free switching programmes carried conditions the statutory regime will not: advance approval, a sixty day completion window, minimum data volumes, and in at least one case no eligibility for partial switches [S06]. Part of the low uptake is attributable to that friction rather than to deeper barriers, and the CMA described the uptake data as inconclusive on whether egress fees materially obstruct switching decisions.

The planning implication survives the caveats. From January the fee is gone, which removes a barrier the regulator considered real. What remains is whatever else was holding the workload in place, and the organisations that have actually moved described that in employee-years.

Functional equivalence is the concept that speaks to whether a switch produces a working service at the other end rather than merely a copy of the data. It is worth reading Article 30 closely, because the obligation is narrower than the term suggests.

Article 30(1) requires providers to take all reasonable measures to enable a customer to achieve functional equivalence after switching, and it applies to services offering scalable and elastic computing resources limited to infrastructure elements such as servers, networks and the virtual resources needed to operate the infrastructure, without providing access to operating services, software and applications [W3]. That is a description of infrastructure services.

Article 30(2) covers everyone else. Providers other than those in paragraph 1 are required to make open interfaces available to all their customers and to the receiving provider, free of charge [W3]. That is a materially different obligation. Open interfaces are a means of getting data and instructions out. They are not a commitment that the destination will work the same way.

For most enterprise estates, that asymmetry is the whole story. The infrastructure layer is the part the law makes genuinely portable. The platform and software layers above it, where an organisation's real commitments live, get interfaces rather than equivalence, and that distinction is deliberate.

Here is the sequence worth anticipating. Coverage of the deadline will be heavy in the weeks around it, because it is a clean, dated, consumer-friendly story. Executives will read it. The reasonable inference from a headline that says the barrier to leaving your cloud provider has been removed is that the barriers to leaving have been removed.

At which point the question arrives: we have been saying for years that moving was too expensive. The fee is gone. What is the plan?

Organisations that have decomposed their switching costs will have a real answer. It might be that two workloads are genuinely portable and worth moving, four are coupled deeply enough that the rewrite cost exceeds any benefit, and the remainder sit somewhere in between pending a commitment expiring in eighteen months. That is a credible position. It is defensible in front of a board, a risk committee or a regulator, and it converts a vague anxiety into a set of dated decisions.

Organisations that have not done that work will answer with a feeling. Feelings do not survive contact with a board that has just been told the main obstacle was removed by law.

The regulatory direction here is not isolated. Under DORA, financial entities in the European Union are already expected to maintain exit strategies for critical ICT third-party arrangements, which means that for a meaningful part of the market the requirement to be able to answer this question predates the Data Act deadline [S05].

This is a short exercise, and the value is in the number it produces rather than in its sophistication.

1. List the ten workloads that matter most. Revenue-bearing, regulated, or both. Not the whole estate.
2. For each, name the provider-specific dependencies. Managed services, proprietary runtimes, identity, data services, anything where the replacement is not obvious.
3. Find the provider's Article 29(5) disclosure and check whether any of those dependencies appear in it.
4. Estimate the rebuild, not the transfer. Engineering weeks to reach functional equivalence at a different provider, plus the evidence work if the workload is regulated.
5. Add the commitment residue. Months remaining on any commitment covering that workload, at its committed rate.

The output is a switching cost per workload, expressed in engineering weeks and euros, with the egress line set to zero because from January it is zero. The unit that matters is the one the organisations in the CMA evidence used when they described their own switches, which was people and months rather than transfer charges [S06].

Atomity exists because placement decisions of this kind are made repeatedly, under changing cost, compliance and sovereignty conditions, and are rarely documented well enough to be defended later. The platform evaluates where a workload should run across providers against cost, performance, compliance, sovereignty and operational risk together, and retains the reasoning behind each decision as evidence.

For the exercise above, that means the switching cost picture is maintained continuously rather than assembled once under deadline pressure, and the answer to why a workload sits where it does exists in a form that a risk committee can read. It does not remove the engineering cost of an actual migration, and it is not a substitute for legal review of a contract.

Several things about this deadline remain genuinely uncertain, and it is worth being honest about them rather than projecting confidence.

Enforcement practice is untested. The Data Act became applicable on 12 September 2025 and the charge prohibition takes effect on 12 January 2027, but how national competent authorities will supervise Article 29 in practice, and how aggressively, is not yet established [S01][S04].

The boundary between a prohibited switching charge and a permitted service fee will be litigated in commercial negotiation long before it is litigated in court. Providers have latitude in how they structure pricing, and the ban addresses charges for the switching process specifically rather than the total cost of a customer relationship [S01].

The scope of Article 29(5) disclosures is being interpreted differently across providers, and a disclosure that is thin is not by itself evidence that switching is easy.

Finally, none of this speaks to whether switching is a good idea. The Data Act makes leaving cheaper at the margin. Whether a given workload should move remains a decision about cost, performance, resilience, sovereignty and organisational capacity, and the removal of a fee changes only one input to it.

If you want to know what your actual switching cost looks like with the egress line set to zero, that is the kind of question Atomity was built to answer. Get in touch and we will walk through the exercise with you on your own estate.