Many mid-market cloud contracts carry a silent assumption: you will stay anyway. The Data Act turned that assumption into a legal question. Regulation (EU) 2023/2854 has applied across the EU since 12 September 2025 (EUR-Lex), and the Bundesnetzagentur, as the competent authority, states plainly that the switching duties in Chapter VI apply to both previously concluded and newly concluded contracts (Bundesnetzagentur). The next stage for connected products follows on 12 September 2026, and on 12 January 2027 switching charges including egress fees disappear entirely (EUR-Lex). A legal right, however, does not move any data. In spring 2025, just 1 percent of companies had fully implemented the Data Act, with a further 4 percent partially (Bitkom). This article translates the regulation into interface architecture: what has to be exportable from cloud ERP, shop and middleware, why functional equivalence fails without documented export APIs, and how to avoid lock-in while the integration is still being built.
The timeline and a widespread misconception
The Data Act entered into force on 11 January 2024 and has applied since 12 September 2025 (EUR-Lex). Articles 23 to 31 on switching between data processing services are therefore live: providers must remove the contractual, commercial and technical obstacles that make switching hard. The obligations address the provider of the data processing service -- the cloud ERP vendor, the SaaS shop operator, the infrastructure provider. The customer is the beneficiary.
One misconception is remarkably persistent: that existing contracts enjoy a grace period until September 2026 or 2027. That is not accurate in this form. Article 50 staggers application in only three places (EUR-Lex): Article 3(1) (access by design) applies to connected products placed on the market after 12 September 2026. Chapter III applies to data provision duties arising from legal acts entering into force after 12 September 2025. And Chapter IV -- the control of unfair contractual terms -- applies to legacy contracts only from 12 September 2027, provided they are of indefinite duration or end at least ten years after 11 January 2024. Chapter VI on switching is not carved out of this staggering.
The Bundesnetzagentur puts it unambiguously in its guidance: both previously concluded and newly concluded contracts must meet the requirements of Chapter 6 from the date of application on 12 September 2025 (Bundesnetzagentur). Legal commentary continues to debate the reach for legacy contracts -- not every voice derives an obligation to renegotiate existing agreements from it. For practical planning, the consequence is the same: nobody can rely on a deadline in 2026 or 2027. The dates that genuinely fall in those years concern different matters.
| Date | What applies | Legal basis |
|---|---|---|
| 11 Jan 2024 | Data Act in force; from here only reduced, cost-covering switching charges are permitted | Art. 29(2) and (3) |
| 12 Sep 2025 | Date of application; switching and portability duties for existing and new contracts | Art. 50, Chapter VI |
| 12 Sep 2026 | Access by design for connected products placed on the market from this date | Art. 3(1) with Art. 50 |
| 12 Jan 2027 | Switching charges cease entirely, including egress fees | Art. 29(1) |
| 12 Sep 2027 | Unfair terms control reaches indefinite legacy contracts (or terms running to 11 Jan 2034) | Chapter IV with Art. 50 |
No grace period for existing contracts when switching
Since 30 May 2026 enforcement in Germany is also settled organisationally: with the Data Act Implementation Act (DADG) entering into force, the Bundesnetzagentur is the competent German authority for the Data Act and the central point of contact for all questions (Bundesnetzagentur). The Bundestag passed the act on 26 March 2026 (Deutscher Bundestag); it was promulgated in the Federal Law Gazette on 29 May 2026. The DADG governs investigation and enforcement powers, the approval of dispute resolution bodies and a fine framework of up to 500,000 euros (Deutscher Bundestag). In parallel, the Federal Commissioner for Data Protection and Freedom of Information supervises application where personal data is involved.
Why functional equivalence fails without export APIs
The Data Act differentiates by service model. For infrastructure services (IaaS), providers must make reasonable measures available to enable functional equivalence after switching -- the European Commission describes it as materially comparable outcomes in response to the same input (European Commission). For platform and software services (PaaS and SaaS), a different duty applies: providers must make open interfaces available and hand over exportable data in a commonly used, machine-readable format (European Commission). For a cloud ERP or a SaaS shop, what is owed is therefore not a re-creation of the software but a structured data export through a documented interface.
This is precisely where the regulation breaks down in practice. A right to export is worth little if nobody knows which objects are exported, in what order, and with which relationships. From project work we see three recurring patterns. The export delivers flat CSV files without foreign keys, so document line items can no longer be matched to their headers. Or it delivers a proprietary backup format that only the same provider can read back in -- formally an export, practically a lock-in. Or the interface exports master data but neither configuration nor mapping nor history, leaving the target environment with data but without processes.
Documented objects
Every exportable object needs a written definition: fields, data types, mandatory entries, relationships. Without that documentation an import cannot be planned, only guessed at.
Referential integrity
Document headers without line items, and line items without an article reference, are worthless. The export must carry stable identifiers so relationships can be reconstructed in the target system.
Open formats
JSON, XML or CSV with a documented schema are machine-readable and tool-independent. Proprietary containers do not serve the purpose of the rule, even if they are technically an export.
What exportable data covers according to the Commission
What has to be exportable from cloud ERP, shop and middleware
Anyone building an integration should treat the export scope as a requirement rather than an afterthought. In an ERP and shop landscape the relevant stock falls into six groups. The first two are almost always considered, the last four almost never -- and it is precisely those four that decide whether a switch takes weeks or quarters.
- Master data: articles, variants, customers, suppliers, prices, terms, tax codes. The core of any master data synchronization and usually the only part a standard export covers reliably.
- Transaction data and documents: orders, delivery notes, invoices, credit notes, payments, stock movements. Retention duties do not end when the provider changes -- the export has to cover the entire retention-relevant period.
- Mapping tables: the translation between shop ID and ERP number, between payment methods, tax keys and status values. Without them, every assignment in the target system is a reinvention.
- Configuration: rule sets, thresholds, approval limits, customer groups, assortment assignments. These settings are not exportable in many SaaS services and have to be demanded explicitly.
- History and logs: change and processing logs that secure traceability. They are the anchor for process documentation under GoBD and therefore for tax auditability.
- Identities and permissions: users, roles, rights assignments. These usually contain personal data and need their own data protection assessment before any transfer.
It is striking how often mapping tables are overlooked. They emerge almost incidentally during a project, grow over years, and end up as the integration's most valuable asset -- because they hold the accumulated knowledge of how two systems fit together. If they sit inside a third party's proprietary connector, they are lost when you switch, even though the Data Act does secure the data export from the ERP itself. The regulation protects the data in the service, not the knowledge in the connection. Our article on data mapping between ERP and shop describes how to model that translation layer cleanly.
The rule of thumb for export scope
Serving the 30-day window: full export plus delta
Article 25 sets the pace, and it is a brisk one. The customer can initiate the switch with a notice period of at most two months (EUR-Lex). A binding transitional period of no more than 30 calendar days then begins, during which exportable data and digital assets must be transferred (EUR-Lex). If the transfer is technically unfeasible within 30 days, the provider must inform the customer with reasons within 14 working days and propose an alternative period of at most seven months (EUR-Lex). After the transitional period, a retrieval period of at least 30 calendar days follows, after which exportable data is deleted (EUR-Lex). The customer may extend the transitional period once by a period they deem appropriate for their own purposes (EUR-Lex).
Thirty days sounds generous until you set it against a running business. The shop keeps taking orders, the ERP keeps posting, stock changes hourly. An export pulled on day one is stale by day 30. Only a two-stage procedure works in practice: a full export as the baseline and a delta export for everything that changed since. That requires every object to carry a reliable change timestamp or version number. Without one, the only option is a complete re-extract shortly before cutover -- which, with large data volumes, blows exactly the window the regulation provides.
- Pull and verify the full export: a reference state of all six data groups, with row counts and checksums per object so completeness is demonstrable.
- Import into the target environment: the full export is loaded while the old system keeps running. Errors surface here -- at a point where they still cost nobody anything.
- Run deltas: repeated extracts of all changes since the last state, ideally daily. The gap narrows continuously.
- Reconcile and accept: samples across documents, stock and balances. Deviations are documented and resolved, not overwritten.
- Final delta and cutover: close a short write window, load the final delta, put the target system live.
- Use the retrieval period: for at least 30 days after the switch, access to the old data remains -- the last chance to close gaps without escalation.
Change timestamps are an architecture decision, not busywork
Avoiding lock-in while the integration is built
The Data Act addresses the provider of the data processing service. It does not address the architecture you build around that service. A company can hold every right in Chapter VI and still be tied down in practice -- because the entire integration logic lives in a connector maintained by a third party that knows exactly two systems. Remove one of them and the integration goes with it. That is not a regulatory problem but a self-inflicted one, and it is avoidable at build time.
Own middleware instead of point-to-point
A vendor-neutral layer between shop and ERP decouples both sides. Replace a system and one adapter changes -- not the whole integration. The details: REST API or middleware.
Mapping and history in-house
Translation tables, processing logs and reconciliation states belong in storage you can reach without a provider's cooperation. Otherwise your project knowledge leaves with the contract.
Contracts with an exit clause
Export scope, format, deadline and provider cooperation belong in the contract, not in a promise. Since 12 September 2025 providers have had to include such clauses anyway (Bundesnetzagentur).
The figures show how few alternatives exist today. 86 percent of companies in Germany use cloud computing, yet only 8 percent of cloud users run a second provider at all (Bitkom Cloud Report 2026). At the same time, a prolonged cloud outage would eventually force 46 percent of all companies to halt operations (Bitkom Cloud Report 2026), while 75 percent back up critical data outside the cloud (Bitkom Cloud Report 2026). The survey is based on a representative sample of 603 companies with 20 or more employees (Bitkom Cloud Report 2026). Translated: dependency is high, a second option is rare, and for most organisations switching is a theoretical right.
Portability is not created at the moment you want to switch, but at the moment you build the interface.
This holds even for systems considered particularly closed. Whether a SAP integration or another vendor's cloud ERP -- what matters is not how open the product is marketed, but whether the integration is cut so that a replacement remains an adapter project rather than a rebuild. How to keep those cuts stable over years is covered in our article on API versioning.
Exit clauses and export tests as part of acceptance
An export that has never been run is a claim. That is why the portability proof belongs in acceptance testing -- in the same place load and failure cases are checked. The effort is modest when planned from the start; it turns expensive when it first appears under time pressure. A test environment with realistic test data is the prerequisite for rehearsing the export without touching production.
- The full export of all six data groups has been executed completely and documented at least once.
- The delta export over a defined period has been verified, including deletions and status changes.
- Mapping tables and configuration exist in an open format outside the respective application system.
- The contract names export scope, format, transitional period, retrieval period and provider cooperation.
- The pre-contractual information on standard service fees and reduced switching charges is available in writing (Art. 29(4)).
- A named owner can trigger the export without provider cooperation and verify the result.
The second-to-last line is often skipped, yet it is expressly regulated: before concluding a contract, providers must clearly inform prospective customers about possible standard service fees, penalties for early termination, and the reduced switching charges that may apply until 12 January 2027 -- and publish this information on their website or otherwise make it easily accessible (EUR-Lex). Anyone negotiating a cloud contract today can therefore demand these details. They are a good early indicator of how seriously a provider takes portability.
For existing landscapes, the same test is worth running as a dry run. A one-off full export of all groups reveals the gaps within days -- before they become a problem in a real switching scenario. As a rule, the surprises are not in articles and customers but in configuration, logs and mapping. The same logic applies to security and evidence duties, for instance when NIS2 requirements for interfaces have to be demonstrated: what is not tested does not count as present.
What to do now
The sequence is unspectacular but effective. First, an inventory: which services process your data, which contracts underpin them, and what do those contracts say today about export, deadlines and charges? Second, an export test per service covering the six data groups and honestly documenting what is missing. Third, the architecture question: do mapping, history and rule sets sit in a place you control? Fourth, the contractual side -- update clauses, request the pre-contractual information, name the exit process. Fifth, close the technical gap wherever the standard export falls short.
That last point is usually where we come in. When a cloud ERP ships no usable export interface, we build one: a documented export and portability API delivering full export and delta across all relevant objects, in open formats and with stable identifiers. When the integration is trapped in proprietary point-to-point connectors, we dissolve it into a vendor-neutral layer where mapping and history stay within your control. And where documents and accounting data are involved -- for example in a DATEV integration -- we make sure the export covers the full retention-relevant period. Our integration services give an overview of the building blocks; the article on ERP migration from legacy systems shows which systems typically jam first during a replacement.
The Data Act shifts the burden of proof: the customer no longer has to justify wanting to leave, the provider has to make leaving possible. Whether that right is worth anything, however, is decided not in the contract text but in the interface. If you would like to know how portable your current landscape actually is, we will take a look at it in a personal conversation.
Sources and studies