Since 12 September 2025, Lock-In Is No Longer a Commercial Problem. It Is a Legal Right. Almost Nobody Can Actually Exercise It.

What actually shifted in law on 12 September 2025?

For the past decade, wanting out of a cloud has been an arithmetic problem. Migration effort against remaining term, egress fees against a discount commitment. The outcome was almost always a renewal, because leaving cost more than staying. That was not an accident, it was the function of the design.

Regulation (EU) 2023/2854, the Data Act, entered into force on 11 January 2024 and has applied since 12 September 2025. Its Chapter VI covers Articles 23 to 31 and is headed “Switching between data processing services” (Garrigues). That turns the arithmetic into an entitlement. Not: the provider ought to make switching possible. But: it must remove the obstacles, meet the deadlines, and from a fixed date charge nothing for any of it. The scope covers IaaS, PaaS and SaaS as well as storage and database services (Alston & Bird), so not just the hyperscaler contract but also the CRM, the data warehouse and the managed search index.

The problem is not the law. A legal right to functional equivalence is worth nothing if your own architecture does not permit it. The provider owes you an export. It does not owe you a system that runs afterwards.

Deadline Reality

The regulation has applied since 12 September 2025. Switching charges phase out to zero under Art. 29(1) on 12 January 2027. In between, Art. 29(2) permits reduced charges, which under paragraph 3 must not exceed the costs the provider incurs directly as a result of the switch. Sign a three-year contract today and you are signing straight across that date.

Article 23 counts five obstacles, not four

The common shorthand says the Data Act bans commercial, technical, contractual and organisational switching obstacles. That is one category short. Art. 23 expressly names “pre-commercial, commercial, technical, contractual and organisational” obstacles. Pre-commercial means: what happens before the contract is signed counts too.

That fifth category moves the moment at which lock-in is created. Lock-in is not produced in the termination clause but during onboarding: in the SDK the provider recommends as the fastest path, and in the reference architecture that puts three proprietary services in the critical path because it saves time on day one.

Article 23 sets out in points (a) to (e) what has to work in the end: termination of the contract after the notice period, conclusion of a new contract with a different provider, portation of exportable data and digital assets, functional equivalence at the new provider, and unbundling of services where technically feasible.

Point (d), functional equivalence, is where most migrations fail. Not because the data is missing, but because the behaviour is. An export contains rows. It does not contain the retry semantics of a queue, the consistency guarantee of a managed data store, or the permission resolution of a provider’s own IAM.

The 30 days are not the deadline you have in mind

The number in every summary is 30 calendar days. It is correct, but describes only one segment of a chain. Art. 25(2)(a) speaks of a “mandatory maximum transitional period of 30 calendar days”. The decisive clause sits right next to it: that transition is “initiated after the maximum notice period referred to in point (d)”, and point (d) permits a notice period of up to two months. Realistically we are not talking about one month but roughly three. Anyone counting the 30 days backwards from contract end has miscalculated by eight weeks.

Step	Legal basis	Duration	Anchor
Notice period	Art. 25(2)(d)	up to two months	customer’s switching request
Transitional period, standard case	Art. 25(2)(a)	maximum 30 calendar days	end of the notice period
Transitional period where technically unfeasible	Art. 25(4)	no more than seven months	justification within 14 working days of the switching request
One-time extension by the customer	Art. 25	as the customer deems appropriate	independent of the provider’s grounds
Minimum data retrieval period	Art. 25(2)(g)	at least 30 calendar days	end of the transitional period

Two rows get overlooked routinely. The first is technical unfeasibility: under Art. 25(4), the provider must notify the customer within 14 working days of the switching request, justify the unfeasibility, and state an alternative transitional period not exceeding seven months. That is not an excuse, it is a procedure with a duty to give reasons and a hard ceiling. A customer who does not know it accepts an informal refusal when a written justification and an end date are owed.

The second is the extension on the customer side. Art. 25 gives the customer the right to extend the transitional period once, by a period the customer considers appropriate, independent of the provider’s grounds.

Switching charges go to zero, termination penalties do not

Art. 29(1) is unambiguous: “From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process.” Until then paragraph 2 applies, permitting reduced charges from 11 January 2024 to 12 January 2027, capped by paragraph 3 at the costs the provider incurs directly as a result of the switch. A day rate for migration support carrying the provider’s own margin is not covered.

The definition is what matters. Art. 2(36) draws switching charges narrowly: “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”. Early termination penalties are therefore, by definition, not switching charges and do not fall under the 2027 prohibition. The switching process becomes free, the remaining term stays owed.

The position on data egress charges is similarly differentiated. Art. 2(35) defines them separately as transfer fees for extracting data to another provider or on-premises. Recital 99 makes clear that egress charges for the parallel use of several services, meaning multicloud with no intent to switch, may still be levied after three years from entry into force, capped at the costs incurred. The zeroing applies to switching, not to running multicloud.

The market, incidentally, moved earlier than applicability required. Google was first to drop egress fees for provider switching in January 2024, with AWS and Microsoft Azure both following in March 2024 (CIO Dive). On 10 September 2025, two days before the date of application, Google Cloud announced “Data Transfer Essentials”: no-cost multicloud data transfer for customers in the EU and UK, so for parallel operation too. That goes further than the regulation demands.

No grandfathering: why the legacy contract does not protect you

The most common misconception in renewal conversations is that a contract signed before 12 September 2025 continues under the old rules. Art. 50 provides transitional rules explicitly only for Chapter III and Chapter IV. Chapter IV applies to contracts concluded after 12 September 2025 and only from 12 September 2027 to legacy contracts of indefinite duration or with an end date at the earliest ten years from 11 January 2024. For Chapter VI no such carve-out exists at all. The switching obligations therefore apply without any grace period to cloud contracts signed long before the date of application (Addleshaw Goddard).

That shifts the statics of the negotiation. The switching clause in your existing contract is no longer the governing rule, at best it describes what the provider volunteered. Until now you asked for switching rights and paid for them, usually with a longer term. Now you negotiate only the implementation, and test every clause against the statutory minimum.

Negotiation point	What Chapter VI gives you	What the legacy contract usually says
Transitional period	Art. 25(2)(a): maximum 30 calendar days	”reasonable assistance on a time and materials basis”
Notice period	Art. 25(2)(d): no more than two months	six months to end of term
Export format	Art. 30: structured, commonly used, machine-readable	provider’s own backup format
Switching charge	Art. 29(2) and (3): only costs directly incurred	day rates for migration support
Egress on switching	Art. 29(1): zero from 12 January 2027	list price per terabyte
Data retrieval after the switch	Art. 25(2)(g): at least 30 calendar days	deletion on contract end
Early termination	Art. 2(36): not a switching charge, stays permissible	full remaining term falls due

What Article 30 gives you and what it does not

Art. 30 differentiates by service type. Providers of infrastructure services owe “all reasonable measures in their power” so the customer achieves functional equivalence, an obligation of effort, not of result. All other providers, meaning PaaS and SaaS, owe open interfaces, to all customers equally and free of charge. Where harmonised standards are absent, the rule is export of all exportable data in a structured, commonly used, machine-readable format. For compliance with common specifications the regulation allows at least twelve months after their publication in the central Union standards repository.

“Structured, commonly used, machine-readable” is a precise legal standard and an inadequate technical target. A zip archive with 400 CSV files satisfies it; a running system it is not. The provider owes the extraction, nobody owes you the restore. If the right is to be exercisable, your side has to be built so that an extraction is enough.

Four architecture decisions that make the right exercisable

The data model belongs to you, not to the service

If business objects, relationships and states exist only in the internal representation of a managed service, the export is a translation, and translations lose. If the same model sits in your own relational database and the service works on top of it, the export is a dump. In practice: no provider-specific column types in the schema of the critical path, no business logic in stored procedures of a proprietary dialect, and identifiers that stay stable outside the service.

Export formats get tested, not documented

An export path nobody has ever read back in is a claim. The only reliable check is a recurring restore attempt on a neutral stack. Same idea as with backups: the write is not the test, the restore is.

# .github/workflows/exit-drill.yml (excerpt)
# Runs monthly, not first thing after you serve notice.
name: exit-drill
on:
  schedule:
    - cron: "0 3 1 * *"

jobs:
  restore-on-neutral-stack:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
      objectstore:
        image: minio/minio
    steps:
      - name: Trigger export via the documented interface
        run: ./scripts/export.sh --target ./artifacts

      - name: Format check, no provider-specific binary format
        run: ./scripts/assert-open-format.sh ./artifacts

      - name: Import into the neutral target environment
        run: ./scripts/restore.sh --from ./artifacts --into "$NEUTRAL_DB_URL"

      - name: Verify functional equivalence
        run: pytest tests/equivalence -q --maxfail=1

The last step is the real one. tests/equivalence does not check row counts, it checks whether the business invariants still hold after the import: the same permissions, the same aggregates, the same results for a handful of production-like queries. Get that run green once and you have not merely demanded the functional equivalence of Art. 23(d), you have measured it. Sensibly it hangs off the same continuous monitoring as the rest of operations, so a quietly changed export format shows up immediately.

Infrastructure as code is a precondition, not a nice-to-have

The second big loss in a migration is not the data, it is the configuration: network rules, IAM roles, queues, certificates, scaling parameters. When that state has grown over years inside a web console, it exists nowhere in readable form.

The Data Act changes none of that. It obliges the provider to make your data and digital assets portable, not to hand you a build sheet for your own environment. Declarative infrastructure is therefore the condition under which the 30-day period is realistic. If you have to work out during the switch what the target environment should look like, you lose the deadline in planning, not in transfer.

Proprietary managed services do not belong in the critical path

The fourth decision is the most uncomfortable, because it trades speed for optionality. A managed service saves weeks on day one. In the critical path it costs months at switching time, because there is no equivalent at the destination and the semantics must be rebuilt.

Building block in the critical path	What happens when you switch	Preparatory work
Containers on standard images	rebuild in days	images mirrored in your own registry
Relational database, open dialect	dump and restore	no provider-specific extensions in the schema
Proprietary managed data store	no one-to-one target at the new provider	abstraction layer or replacement before the renewal
Serverless functions on provider events	event model not transferable	event bus as a layer you own
IAM and network rules maintained in the console	reconstruction from memory	declarative configuration as the single source
Managed search with its own query dialect	queries have to be rewritten	queries encapsulated in the application layer

This is not a recommendation to run everything yourself, it is a recommendation to make the decision deliberately. Outside the critical path a proprietary service is often the right call. For the building blocks without which the business stops, it is a bet on the renewal. If you want to run that trade-off systematically, the comparison of in-house and bought-in gives you the frame, and the SaaS graveyard is the reminder that providers also disappear without any involvement from you.

The exceptions that can take the right away from you

Two things belong in any honest assessment. The first is Art. 31, and it holds two exceptions of very different reach. Paragraph 1 covers services the majority of whose main features are custom-built for a specific customer and that are not offered broadly on a commercial basis in the service catalogue: for those, Art. 23(d), Art. 29 and Art. 30(1) and (3) do not apply. Paragraph 2 goes considerably further: for non-production versions provided for testing and evaluation for a limited period, the obligations of the whole of Chapter VI do not apply. Those are genuine exceptions, not questions of interpretation. The provider must inform the prospective customer before contracting which obligations do not apply. If that information is missing, take it as a signal.

The second is the Commission’s Digital Omnibus proposal of 19 November 2025. It would soften Chapter VI noticeably: new paragraphs 1a and 1b in Art. 31 would exempt custom-built services as well as all SME and small-mid-cap providers of non-infrastructure services from nearly all switching obligations for contracts concluded before 12 September 2025, with no duty to renegotiate before the contract ends. Proportionate early termination penalties in fixed-term contracts would also be expressly permitted. As of 15 July 2026 the Council’s consolidated text is still under negotiation and is not law in force (Greenberg Traurig, full text of the analysis, Bird & Bird on the new Art. 31 paragraphs).

That produces an uncomfortable asymmetry: the right applies today, but could fall away retroactively for a slice of contracts. The architecture work that makes it exercisable keeps its value in both scenarios. A negotiating position resting solely on the statute does not.

Who enforces this, and what has happened so far?

Supervision is organised nationally, and Germany was late. The Bundestag passed the German Data Act implementation act (DADG) on 26 March 2026. Since 30 May 2026, coinciding with that act entering into force, the Bundesnetzagentur has been the central German supervisory authority for the Data Act and expressly supervises the rules simplifying cloud provider switching as well. That is roughly eight months behind the date of application.

Art. 40 sets the sanctions frame: Member States had to notify their penalty rules by 12 September 2025, and penalties must be effective, proportionate and dissuasive. For infringements involving personal data, meaning Chapters II, III and V, supervisory authorities may impose fines up to the ceiling of Art. 83(5) GDPR. Concrete enforcement cases over breaches of the switching obligations are not documented through the end of July 2026; observers expect enforcement to pick up only in the second half of 2026.

The provider side has moved independently. In November 2024, CISPE published a “Cloud Switching Framework” together with Gaia-X, built on five pillars: transparency on procedures, costs and limits; defined notification channels; export interfaces and migration tooling; an orderly termination procedure; and contractual confirmation of the right to multicloud. AWS has been a CISPE member since 2017 and has published its own EU Data Act Addendum, and Google Cloud maintains a Data Act compliance page. These documents are the starting point of any renewal negotiation, not its outcome.

Market Position

On 24 July 2025, Synergy Research put European cloud providers at 15 percent of the European market, down from 29 percent in 2017 with the slide to 15 percent completed by 2022 and stable since. AWS, Microsoft and Google together hold 70 percent. The European cloud infrastructure market stood at 61 billion euros in 2024, with growth of around 24 percent expected for 2025. The strongest European providers are SAP and Deutsche Telekom at 2 percent each.

Those numbers explain why Chapter VI exists and why it will not be enough alone. A right to switch moves market share only once switching is technically feasible in the time the law provides.

What you decide this quarter

The Data Act moved the negotiating table, not your system landscape. Three decisions bring the two together.

First: put the Art. 25 chain of deadlines into every renewal preparation under way and test the existing clauses against the table above. Anything falling short of the statutory minimum is not a negotiating win for the provider, it is an open question.

Second: take an honest inventory of the proprietary services in the critical path. Not to replace them all, but to know which of them make the 30-day period impossible. That list is the basis for any integration work that makes the right exercisable.

Third: run the exit drill once. Not as a concept, but as a green or red run. Everything else is a claim about your own portability.

On the same calendar, in passing: 12 September 2026, from which the access obligation of Art. 3(1) applies to connected products newly placed on the market. If you build hardware, you have a second clock running. If you want to know what this assessment looks like in a system landscape that has grown over years, talk to us.

Sources

Note on sourcing: The full text of Regulation (EU) 2023/2854 was not machine-retrievable via EUR-Lex at the time of writing; the article quotations come from the full-text mirrors data-act-law.eu and eu-data-act.com. Only the version published in the Official Journal is authoritative for legally binding statements. A widely repeated claim that a separate intermediate stage for switching penalties and migration fees applies from 12 January 2026 has no counterpart in the legal text and contradicts Art. 29(2); it is deliberately not reproduced here. Concrete fine levels for Chapter VI infringements in Germany could not be confirmed against any primary source. The negotiation status of the Digital Omnibus package refers to the documented position as of 15 July 2026. This article is not legal advice; obtain qualified counsel for the assessment of your specific contracts.

Key Takeaways