Viele Cloud-Verträge im Mittelstand tragen eine stille Annahme in sich: Man bleibt ohnehin. Der Data Act hat diese Annahme zur Rechtsfrage gemacht. Seit dem 12. September 2025 gilt die Verordnung (EU) 2023/2854 in der gesamten EU (EUR-Lex), und die Bundesnetzagentur stellt als zuständige Behörde klar, dass die Wechselpflichten aus Kapitel VI sowohl für bereits geschlossene als auch für neu geschlossene Verträge gelten (Bundesnetzagentur). Am 12. September 2026 folgt die nächste Stufe für vernetzte Produkte, am 12. Januar 2027 entfallen Wechselentgelte einschließlich Egress-Gebühren vollständig (EUR-Lex). Der Rechtsanspruch allein bewegt allerdings keine Daten. Im Frühjahr 2025 hatte erst 1 Prozent der Unternehmen den Data Act vollständig umgesetzt, weitere 4 Prozent teilweise (Bitkom). Dieser Artikel übersetzt die Regulierung in Schnittstellen-Architektur: Was aus Cloud-ERP, Shop und Middleware exportierbar sein muss, warum funktionale Äquivalenz ohne dokumentierte Export-APIs scheitert und wie sich Lock-in schon beim Bau der Anbindung vermeiden lässt.
Der Fristenplan und ein weit verbreitetes Missverständnis
Der Data Act ist am 11. Januar 2024 in Kraft getreten und gilt seit dem 12. September 2025 (EUR-Lex). Damit sind die Artikel 23 bis 31 zum Wechsel zwischen Datenverarbeitungsdiensten anwendbar: Anbieter müssen vertragliche, wirtschaftliche und technische Hindernisse beseitigen, die einen Wechsel erschweren. Adressat der Pflichten ist der Anbieter des Datenverarbeitungsdienstes -- also der Cloud-ERP-Hersteller, der SaaS-Shop-Betreiber oder der Infrastrukturanbieter. Der Kunde ist der Begünstigte.
Hier hält sich ein Missverständnis hartnäckig: Für Bestandsverträge gebe es eine Schonfrist bis September 2026 oder 2027. Das trifft in dieser Form nicht zu. Artikel 50 des Data Act staffelt die Anwendung nur an drei Stellen (EUR-Lex): Artikel 3 Absatz 1 (Access by design) gilt für vernetzte Produkte, die nach dem 12. September 2026 in Verkehr gebracht werden. Kapitel III greift für Datenbereitstellungspflichten aus Rechtsakten, die nach dem 12. September 2025 in Kraft treten. Und Kapitel IV -- die Kontrolle missbräuchlicher Vertragsklauseln -- gilt für Altverträge erst ab dem 12. September 2027, sofern diese unbefristet sind oder mindestens zehn Jahre nach dem 11. Januar 2024 enden. Kapitel VI zum Anbieterwechsel ist in dieser Staffelung nicht ausgenommen.
Die Bundesnetzagentur formuliert es in ihren Fachinformationen unmissverständlich: Sowohl zuvor geschlossene als auch neu geschlossene Verträge müssen die Anforderungen des Kapitels 6 ab dem Geltungsbeginn am 12. September 2025 erfüllen (Bundesnetzagentur). In der juristischen Literatur wird über die Reichweite bei Altverträgen weiterhin diskutiert -- eine Pflicht zur Neuverhandlung bestehender Verträge leiten nicht alle Stimmen daraus ab. Für die Praxis ist die Konsequenz aber dieselbe: Wer heute plant, kann sich nicht auf eine Frist im Jahr 2026 oder 2027 berufen. Die Termine, die 2026 und 2027 wirklich anstehen, betreffen andere Sachverhalte.
| Stichtag | Was gilt | Rechtsgrundlage |
|---|---|---|
| 11.01.2024 | Data Act in Kraft; ab hier nur noch ermäßigte, kostendeckende Wechselentgelte zulässig | Art. 29 Abs. 2 und 3 |
| 12.09.2025 | Geltungsbeginn; Wechsel- und Portabilitätspflichten für Alt- und Neuverträge | Art. 50, Kapitel VI |
| 12.09.2026 | Access by design für vernetzte Produkte, die ab diesem Tag in Verkehr gebracht werden | Art. 3 Abs. 1 i. V. m. Art. 50 |
| 12.01.2027 | Wechselentgelte entfallen vollständig, einschließlich Egress-Gebühren | Art. 29 Abs. 1 |
| 12.09.2027 | Klauselkontrolle greift auf unbefristete Altverträge (bzw. Laufzeit bis 11.01.2034) | Kapitel IV i. V. m. Art. 50 |
Keine Schonfrist für Bestandsverträge beim Anbieterwechsel
Seit dem 30. Mai 2026 ist die Durchsetzung in Deutschland auch organisatorisch geklärt: Mit Inkrafttreten des Data-Act-Durchführungsgesetzes (DADG) ist die Bundesnetzagentur die zuständige deutsche Behörde für den Data Act und zentrale Anlaufstelle für alle Fragen (Bundesnetzagentur). Der Bundestag hatte das Gesetz am 26. März 2026 verabschiedet (Deutscher Bundestag); die Verkündung im Bundesgesetzblatt erfolgte am 29. Mai 2026. Das DADG regelt Untersuchungs- und Durchsetzungsbefugnisse, die Zulassung von Streitbeilegungsstellen und einen Bußgeldrahmen von bis zu 500.000 Euro (Deutscher Bundestag). Parallel überwacht der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit die Anwendung, soweit personenbezogene Daten betroffen sind.
Warum funktionale Äquivalenz ohne Export-APIs scheitert
Der Data Act unterscheidet nach Servicemodell. Für Infrastrukturdienste (IaaS) müssen Anbieter angemessene Maßnahmen bereitstellen, um nach dem Wechsel funktionale Äquivalenz zu ermöglichen -- die Europäische Kommission beschreibt sie als im Wesentlichen vergleichbare Ergebnisse bei gleicher Eingabe (Europäische Kommission). Für Plattform- und Softwaredienste (PaaS und SaaS) gilt eine andere Pflicht: Anbieter müssen offene Schnittstellen bereitstellen und exportierbare Daten in einem gängigen, maschinenlesbaren Format herausgeben (Europäische Kommission). Für ein Cloud-ERP oder einen SaaS-Shop ist damit nicht die Nachbildung der Software geschuldet, sondern der strukturierte Datenexport über eine dokumentierte Schnittstelle.
Genau an dieser Stelle bricht die Regulierung in der Praxis. Ein Anspruch auf Export nützt wenig, wenn niemand weiß, welche Objekte in welcher Reihenfolge und mit welchen Beziehungen exportiert werden. Aus der Projektarbeit kennen wir drei wiederkehrende Muster: Der Export liefert flache CSV-Dateien ohne Fremdschlüssel, sodass sich Belegpositionen nicht mehr ihren Köpfen zuordnen lassen. Oder er liefert ein proprietäres Backup-Format, das nur derselbe Anbieter wieder einlesen kann -- formal ein Export, praktisch ein Lock-in. Oder die Schnittstelle exportiert Stammdaten, aber weder Konfiguration noch Mapping noch Historie, sodass die Zielumgebung zwar Daten hat, aber keine Prozesse.
Dokumentierte Objekte
Jedes exportierbare Objekt braucht eine schriftliche Definition: Felder, Datentypen, Pflichtangaben, Beziehungen. Ohne diese Dokumentation lässt sich ein Import nicht planen, sondern nur raten.
Referenzielle Integrität
Belegköpfe ohne Positionen und Positionen ohne Artikelbezug sind wertlos. Der Export muss stabile Identifikatoren mitgeben, damit Beziehungen im Zielsystem rekonstruierbar bleiben.
Offene Formate
JSON, XML oder CSV mit dokumentiertem Schema sind maschinenlesbar und werkzeugunabhängig. Proprietäre Container erfüllen den Zweck der Regelung nicht, auch wenn sie technisch ein Export sind.
Was exportierbare Daten laut Kommission umfassen
Welche Daten aus Cloud-ERP, Shop und Middleware exportierbar sein müssen
Wer eine Anbindung baut, sollte den Exportumfang nicht dem Zufall überlassen, sondern ihn als Anforderung formulieren. In einer ERP-Shop-Landschaft fallen die relevanten Bestände in sechs Gruppen. Die ersten beiden werden fast immer bedacht, die letzten vier fast nie -- und genau sie entscheiden darüber, ob ein Wechsel in Wochen oder in Quartalen gelingt.
- Stammdaten: Artikel, Varianten, Kunden, Lieferanten, Preise, Konditionen, Steuerkennzeichen. Der Kern jeder Stammdatensynchronisation und meist der einzige Teil, den ein Standardexport zuverlässig abdeckt.
- Bewegungsdaten und Belege: Bestellungen, Lieferscheine, Rechnungen, Gutschriften, Zahlungen, Bestandsbewegungen. Aufbewahrungspflichten enden nicht mit dem Anbieterwechsel -- der Export muss den gesamten aufbewahrungsrelevanten Zeitraum abdecken.
- Mapping-Tabellen: Die Übersetzung zwischen Shop-ID und ERP-Nummer, zwischen Zahlarten, Steuerschlüsseln und Statuswerten. Ohne sie ist jede Zuordnung im Zielsystem eine Neuerfindung.
- Konfiguration: Regelwerke, Schwellenwerte, Freigabegrenzen, Kundengruppen, Sortimentszuordnungen. Diese Einstellungen sind in vielen SaaS-Diensten nicht exportierbar und müssen ausdrücklich verlangt werden.
- Historie und Protokolle: Änderungs- und Verarbeitungsprotokolle, die Nachvollziehbarkeit sichern. Sie sind der Anknüpfungspunkt für die Verfahrensdokumentation nach GoBD und damit für die steuerliche Prüfbarkeit.
- Identitäten und Berechtigungen: Benutzer, Rollen, Rechtezuordnungen. Sie enthalten in der Regel personenbezogene Daten und brauchen eine eigene datenschutzrechtliche Betrachtung beim Transfer.
Auffällig ist, wie oft die Mapping-Tabellen übersehen werden. Sie entstehen im Projekt fast beiläufig, wachsen über Jahre und sind am Ende das wertvollste Asset der Integration -- weil sie das gesammelte Wissen darüber enthalten, wie zwei Systeme zueinander passen. Liegen sie in einem proprietären Connector eines Drittanbieters, gehen sie beim Wechsel verloren, obwohl der Data Act den Datenexport aus dem ERP durchaus sicherstellt. Die Regulierung schützt die Daten im Dienst, nicht das Wissen in der Verbindung. Wie diese Übersetzungsschicht sauber modelliert wird, beschreibt unser Beitrag zum Daten-Mapping zwischen ERP und Shop.
Die Faustregel für den Exportumfang
Die 30-Tage-Frist technisch bedienen: Vollexport plus Delta
Artikel 25 des Data Act gibt den Takt vor, und der ist sportlich. Der Kunde kann den Wechsel mit einer Kündigungsfrist von maximal zwei Monaten einleiten (EUR-Lex). Danach beginnt eine verbindliche Übergangsfrist von höchstens 30 Kalendertagen, in der die exportierbaren Daten und digitalen Vermögenswerte zu übertragen sind (EUR-Lex). Ist die Übertragung technisch nicht in 30 Tagen machbar, muss der Anbieter den Kunden innerhalb von 14 Arbeitstagen begründet unterrichten und eine alternative Frist von höchstens sieben Monaten vorschlagen (EUR-Lex). Nach Ablauf der Übergangsfrist folgt eine Abruffrist von mindestens 30 Kalendertagen, danach werden die exportierbaren Daten gelöscht (EUR-Lex). Der Kunde kann die Übergangsfrist einmalig um einen Zeitraum verlängern, den er für seine Zwecke für angemessen hält (EUR-Lex).
Dreißig Tage klingen großzügig, bis man sie gegen ein laufendes Geschäft rechnet. Der Shop nimmt weiter Bestellungen an, das ERP bucht weiter, Bestände verändern sich stündlich. Ein Export, der am Tag 1 gezogen wird, ist am Tag 30 überholt. Deshalb funktioniert in der Praxis nur ein zweistufiges Verfahren: ein Vollexport als Basis und ein Delta-Export für alles, was sich seither geändert hat. Voraussetzung dafür ist, dass jedes Objekt einen verlässlichen Änderungszeitstempel oder eine Versionsnummer trägt. Fehlt dieser, bleibt nur ein vollständiger Neuabzug kurz vor dem Umschalten -- was bei großen Beständen genau das Zeitfenster sprengt, das die Verordnung vorsieht.
- Vollexport ziehen und prüfen: Referenzstand aller sechs Datengruppen, mit Zeilenzahlen und Prüfsummen je Objekt, damit Vollständigkeit belegbar ist.
- Import in die Zielumgebung: Der Vollexport wird geladen, während der Altbetrieb weiterläuft. Fehler zeigen sich hier -- zu einem Zeitpunkt, an dem sie noch niemanden kosten.
- Delta-Läufe fahren: Wiederholte Abzüge aller Änderungen seit dem letzten Stand, idealerweise täglich. So verkleinert sich die Lücke kontinuierlich.
- Abgleich und Abnahme: Stichproben über Belege, Bestände und Salden. Abweichungen werden dokumentiert und geklärt, nicht überschrieben.
- Letzter Delta-Lauf und Umschalten: Kurzes Schreibfenster schließen, finales Delta einspielen, Zielsystem produktiv setzen.
- Abruffrist nutzen: In den mindestens 30 Tagen nach dem Wechsel bleibt der Zugriff auf die Altdaten -- die letzte Gelegenheit, Lücken ohne Eskalation zu schließen.
Änderungszeitstempel sind eine Architekturentscheidung, keine Fleißarbeit
Lock-in schon beim Bau der Anbindung vermeiden
Der Data Act adressiert den Anbieter des Datenverarbeitungsdienstes. Er adressiert nicht die Architektur, die Sie um diesen Dienst herum bauen. Ein Unternehmen kann alle Rechte aus Kapitel VI haben und trotzdem faktisch gebunden sein -- weil die gesamte Integrationslogik in einem Connector steckt, den ein Dritter pflegt und der nur zwei bestimmte Systeme kennt. Fällt eines davon weg, fällt die Anbindung mit. Das ist kein regulatorisches, sondern ein hausgemachtes Problem, und es ist beim Bau vermeidbar.
Eigene Middleware statt Punkt-zu-Punkt
Eine herstellerneutrale Schicht zwischen Shop und ERP entkoppelt beide Seiten. Wird ein System getauscht, ändert sich ein Adapter -- nicht die gesamte Integration. Der Unterschied im Detail: REST-API oder Middleware.
Mapping und Historie im eigenen Haus
Übersetzungstabellen, Verarbeitungsprotokolle und Abgleichsstände gehören in eine Datenhaltung, auf die Sie ohne Mitwirkung eines Anbieters zugreifen können. Sonst wandert Ihr Projektwissen mit dem Vertrag.
Verträge mit Exit-Klausel
Exportumfang, Format, Frist und Mitwirkung gehören in den Vertrag, nicht in eine Zusage. Seit dem 12. September 2025 müssen Anbieter entsprechende Klauseln ohnehin vorsehen (Bundesnetzagentur).
Die Zahlen zeigen, wie wenig Ausweichmöglichkeiten heute bestehen. 86 Prozent der Unternehmen in Deutschland nutzen Cloud Computing, aber nur 8 Prozent der Cloud-Nutzer setzen überhaupt einen zweiten Anbieter ein (Bitkom Cloud Report 2026). Gleichzeitig müsste bei einem längeren Cloud-Ausfall 46 Prozent aller Unternehmen den Betrieb irgendwann einstellen (Bitkom Cloud Report 2026), und immerhin 75 Prozent sichern kritische Daten außerhalb der Cloud (Bitkom Cloud Report 2026). Die Erhebung beruht auf einer repräsentativen Befragung von 603 Unternehmen ab 20 Beschäftigten (Bitkom Cloud Report 2026). Übersetzt heißt das: Die Abhängigkeit ist hoch, die zweite Option selten und der Wechsel für die meisten ein theoretisches Recht.
Portabilität entsteht nicht in dem Moment, in dem man wechseln will, sondern in dem Moment, in dem man die Schnittstelle baut.
Das gilt auch für Systeme, die als besonders geschlossen gelten. Ob eine SAP-Anbindung oder ein Cloud-ERP eines anderen Herstellers -- entscheidend ist nicht, wie offen das Produkt beworben wird, sondern ob die Anbindung so geschnitten ist, dass ein Austausch ein Adapter-Projekt bleibt und kein Neubau wird. Wie sich diese Schnitte über Jahre stabil halten lassen, behandelt der Beitrag zur API-Versionierung.
Exit-Klauseln und Export-Tests als Teil der Abnahme
Ein Export, der nie ausgeführt wurde, ist eine Behauptung. Deshalb gehört der Portabilitätsnachweis in die Abnahme -- an dieselbe Stelle, an der auch Last- und Fehlerfälle geprüft werden. Der Aufwand dafür ist überschaubar, wenn er von Anfang an eingeplant ist; er wird teuer, wenn er erst unter Zeitdruck entsteht. Eine Testumgebung mit realistischen Testdaten ist dabei die Voraussetzung, um den Export zu üben, ohne den Produktivbetrieb zu berühren.
- Vollexport aller sechs Datengruppen wurde mindestens einmal vollständig ausgeführt und dokumentiert.
- Delta-Export über einen definierten Zeitraum wurde geprüft, inklusive Löschungen und Statusänderungen.
- Mapping-Tabellen und Konfiguration liegen in einem offenen Format außerhalb des jeweiligen Fachsystems vor.
- Der Vertrag benennt Exportumfang, Format, Übergangsfrist, Abruffrist und die Mitwirkung des Anbieters.
- Die vorvertraglichen Angaben zu Standardentgelten und ermäßigten Wechselentgelten liegen schriftlich vor (Art. 29 Abs. 4).
- Ein Verantwortlicher kann den Export ohne Mitwirkung des Anbieters auslösen und das Ergebnis prüfen.
Die vorletzte Zeile wird oft übergangen, ist aber ausdrücklich geregelt: Anbieter müssen potenzielle Kunden vor Vertragsschluss eindeutig über mögliche Standarddienstentgelte, Sanktionen bei vorzeitiger Kündigung und die im Zeitraum bis zum 12. Januar 2027 möglichen ermäßigten Wechselentgelte informieren -- und diese Informationen auf ihrer Website oder anderweitig leicht zugänglich veröffentlichen (EUR-Lex). Wer heute einen Cloud-Vertrag verhandelt, kann diese Angaben also einfordern. Sie sind ein guter Frühindikator dafür, wie ernst ein Anbieter die Portabilität nimmt.
Für bestehende Landschaften lohnt derselbe Test als Trockenübung. Ein einmaliger Vollexport aller Gruppen zeigt binnen weniger Tage, wo die Lücken sind -- und zwar bevor sie in einem echten Wechselszenario zum Problem werden. In der Regel finden sich die Überraschungen nicht bei den Artikeln und Kunden, sondern bei Konfiguration, Protokollen und Mapping. Dieselbe Logik greift bei Sicherheits- und Nachweispflichten, etwa wenn NIS2-Anforderungen an Schnittstellen belegt werden müssen: Was nicht getestet ist, gilt nicht als vorhanden.
Was jetzt konkret ansteht
Die Reihenfolge ist unspektakulär, aber wirksam. Zuerst eine Bestandsaufnahme: Welche Dienste verarbeiten Ihre Daten, welche Verträge liegen dem zugrunde, und was sagen diese Verträge heute über Export, Fristen und Entgelte? Zweitens ein Export-Test je Dienst, der die sechs Datengruppen abdeckt und ehrlich dokumentiert, was fehlt. Drittens die Architekturfrage: Liegen Mapping, Historie und Regelwerke an einem Ort, den Sie kontrollieren? Viertens die Vertragsseite -- Klauseln nachziehen, vorvertragliche Angaben einfordern, Exit-Prozess benennen. Und fünftens die technische Lücke schließen, wo der Standardexport nicht reicht.
Der letzte Punkt ist der, bei dem wir üblicherweise einsteigen. Wenn ein Cloud-ERP keine brauchbare Export-Schnittstelle mitbringt, bauen wir sie: eine dokumentierte Export- und Portabilitäts-API, die Vollexport und Delta über alle relevanten Objekte liefert, in offenen Formaten und mit stabilen Identifikatoren. Wenn die Integration in proprietären Punkt-zu-Punkt-Connectoren gefangen ist, lösen wir sie in eine herstellerneutrale Schicht auf, in der Mapping und Historie in Ihrem Hoheitsbereich bleiben. Und wo Belege und Buchungsdaten betroffen sind -- etwa bei einer DATEV-Anbindung -- achten wir darauf, dass der Export den aufbewahrungsrelevanten Zeitraum vollständig abdeckt. Einen Überblick über die dafür nötigen Bausteine geben unsere Integrationsleistungen; welche Systeme bei einer Ablösung typischerweise zuerst klemmen, zeigt der Beitrag zur ERP-Migration von Legacy-Systemen.
Der Data Act verschiebt die Beweislast: Nicht mehr der Kunde muss begründen, warum er wechseln möchte, sondern der Anbieter muss den Wechsel ermöglichen. Ob dieses Recht etwas wert ist, entscheidet sich allerdings nicht im Vertragstext, sondern in der Schnittstelle. Wenn Sie wissen möchten, wie portabel Ihre aktuelle Landschaft tatsächlich ist, sehen wir uns das im persönlichen Gespräch an.
Quellen und Studien