Bei SAP bedeutet der Standard Kontrollverlust

In Migrationsprojekten für SAP S/4HANA Public Cloud tragen Testdaten wechselnde Buchstabenpräfixe, A, B, C, damit sich ein Migrationslauf beliebig oft wiederholen lässt, ohne vorher aufzuräumen. Nötig wird der Kniff, weil sich das gemietete Testsystem nicht per Klick zurücksetzen lässt: Wer im Standard bleibt, mietet auch die Testumgebung nur. Ein echter Neustart ist laut SAPs eigener Produktdokumentation zum Testdaten-Refresh¹ ein beim Anbieter zu beantragender, kalendergebundener Dienst mit bis zu 24 Stunden Ausfallzeit und vier Wochen Vorlauf. Das liest sich wie ein technisches Detail eines Migrationsprojekts. Verfolgt man es weiter, ist es eine Frage der Verhandlungsmacht zwischen Kunde und Anbieter.

Nicht der Vertrag entscheidet über Lock-in, sondern die Umgebung selbst#

Die einschlägige Fachliteratur zu Cloud-Migrationen sieht das ähnlich, unabhängig vom Anbieter. Eine Befragung von 114 IT-Fachleuten² durch Opara-Martins, Sahandi und Tian (2016) verortet das Lock-in-Risiko vor allem in der Portierbarkeit von Daten, der Interoperabilität der Schnittstellen und dem Anteil offener Standards in der Umgebung selbst, Faktoren, die im Vertragstext meist gar nicht auftauchen. Am SAP-Fall lässt sich das direkt nachvollziehen: Die Testdaten-Refresh-Funktion zeigt, dass der Reset der eigenen Testumgebung, ein zentraler Portabilitäts-Baustein, in der Public-Cloud-Variante einem vom Anbieter terminierten Kalender folgt statt einem Klick des Kunden. Ähnliches gilt für die ERP-Verbreitung selbst: 42 Prozent ERP-Nutzung bei kleinen und mittleren Unternehmen³ verdeckt, dass mittlere Betriebe längst bei 70 Prozent liegen, nahe an Großunternehmen.

Im Lobbyregister wehrt sich SAP gegen die eigene Ausstiegsregel#

Im Lobbyregister des Bundestags führt SAP SE zehn laufende Regelungsvorhaben, darunter den Eintrag zum EU Data Act⁴, erfasst am 28. Juni 2024 und zuletzt aktualisiert am 1. April 2026. Die Position lautet wörtlich: „Aussetzung und Revidierung“ der Regeln, „das betrifft insbesondere, aber nicht nur die Regelungen des Data Act zum ‚Cloud Switching‘ und zum ‚B2B Data Sharing‘.“ Für die Interessenvertretung gibt SAP einen Jahresaufwand von 1,59 bis 1,6 Millionen Euro und 28 Lobbyisten an. Betroffen sind ausgerechnet die Vorschriften, die beim Anbieterwechsel Funktionsäquivalenz erzwingen sollen⁵: Die Verordnung (EU) 2023/2854 staffelt Wechselgebühren für Cloud-Dienste seit Januar 2024 nach unten und verbietet sie ab dem 12. Januar 2027 vollständig. Dass ein Konzern für eine Regel wirbt, sagt nichts darüber, ob sie technisch nötig ist. Das deutsche Umsetzungsgesetz zum Data Act, das der zuständige Bundestagsausschuss im Frühjahr 2026 beriet, ändert an diesen Wechselregeln nichts, es klärt nur Aufsicht und Zuständigkeiten; die materiellen Vorgaben stehen unmittelbar in der EU-Verordnung. SAPs Forderung nach Aussetzung zielt damit auf Brüssel, nicht auf Berlin.

Nur 13 Prozent der eigenen Kunden wählen den gelobten Standardweg#

Unter den SAP-Bestandskunden, die bereits auf eine S/4HANA-Variante umgestiegen sind, nutzen laut dem DSAG-Investitionsreport⁶ 42 Prozent On-Premises, 33 Prozent Private Cloud und nur 13 Prozent Public Cloud. In einer Befragung von 198 Anwenderunternehmen zwischen Dezember 2025 und Januar 2026 verschiebt sich das Bild für die Investitionspläne 2026 kaum: 42 Prozent setzen weiter auf On-Premises, 22 Prozent auf Private Cloud, gerade einmal 6 Prozent auf den beworbenen Standardweg. Wer im Bestandssystem oder in der eigenen Cloud bleibt, verzichtet dabei nicht automatisch auf Aktualität: SAP hat die Wartungsfrist für die Vorgängergeneration seit der ursprünglichen Ankündigung bereits zweimal verschoben, zuletzt im August 2025 auf Ende 2030, mit optionalen Übergangsfristen bis 2033. Genau an dem Punkt, an dem die Public-Cloud-Variante einen Termin beim Anbieter braucht, betreibt das eigene Rechenzentrum oder die private Cloud die Umgebung selbst und setzt das Testsystem ohne fremden Kalender zurück. Der Standardweg verspricht feste Zyklen und rasche Einführung. Gewählt wird er von der eigenen Kundschaft am seltensten.

Nach zwölf bis 24 Monaten beginnt erst die Abhängigkeit#

Eine Einführungsdauer von zwölf bis 24 Monaten, wie sie in Projektberichten kursiert, misst nur die Bauzeit. Sie sagt nichts darüber, wie lange ein Unternehmen danach an die terminierten Zyklen des Anbieters gebunden bleibt, wie selten ein Testsystem im Projektalltag zurückgesetzt wird, weil jeder Reset einen Termin beim Anbieter braucht, und wer die nächste Migration verhandelt, wenn sich die Bedingungen ändern. Sie misst auch nicht, wie viel unternehmensspezifische Prozessgestaltung im Standard aufgeht, sobald Erweiterungen nur noch innerhalb vorgegebener Schnittstellen erlaubt sind. Zwei Tatsachen stehen dabei unverbunden nebeneinander: SAPs eigene Produktdokumentation legt fest, unter welchen Bedingungen Kunden ihre gemietete Testumgebung zurücksetzen dürfen, und SAPs Lobbyregistereintrag fordert von der Politik, ausgerechnet die Regeln zu lockern, die einen Ausstieg aus dieser Umgebung erleichtern würden. Ob das eine mit dem anderen zusammenhängt, sagt keine der beiden Quellen. Wer als Nächstes unterschreibt, verhandelt über beides zugleich: eine Testumgebung im Besitz des Anbieters und Ausstiegsregeln, die derselbe Anbieter in Brüssel bekämpft.

Die Angaben zur Testdaten-Refresh-Funktion stammen aus SAPs eigener Produktdokumentation (pages.community.sap.com, S/4HANA Cloud Public Edition, Test Data Refresh FAQ). Die Studie zu Lock-in-Risiken ist Opara-Martins, Sahandi und Tian, Journal of Cloud Computing 5 (2016), abrufbar über link.springer.com. Die Position und die Kennzahlen zur Interessenvertretung stammen aus lobbyregister.bundestag.de, dem Lobbyregister des Deutschen Bundestags, Eintrag R002180 (SAP SE), Stand 1. April 2026. Die Nutzungs- und Investitionszahlen stammen aus den DSAG-Investitionsreports; die Wartungsfristen aus SAPs eigenen Ankündigungen (Community-Blog 2020, news.sap.com 2025). Die Regeln zu Wechselgebühren stehen in Artikel 29 der Verordnung (EU) 2023/2854 (Data Act).