Zurueck zum Blog
BS7-Roadmap

Hybrid-Betrieb On-Premise und Cloud: Vertragsregelungen fuer mehrjaehrigen Parallelbetrieb

Hybrid-Betrieb On-Premise Cloud ERP Cloud Parallelbetrieb Vertragsregelung

Nicht jedes Unternehmen plant einen vollständigen Wechsel zur Cloud. Manche Landschaften sind zu heterogen, manche regulatorischen Anforderungen zu spezifisch, manche Systeme zu tief in Prozesse eingebettet, um sie in einem Migrationsprojekt vollständig abzulösen. Das Ergebnis ist kein Übergangszustand, sondern ein bewusst gewähltes Betriebsmodell: On-Premise-Systeme und RISE-Cloud-Systeme laufen dauerhaft nebeneinander, über mehrere Jahre, manchmal über das Ende einer RISE-Vertragsperiode hinaus.

Dieser Betriebsmodus ist vertraglich möglich. Aber er ist nicht automatisch geregelt. Wer On-Premise und RISE parallel betreibt, ohne die vier zentralen Vertragsbereiche aktiv zu steuern, trägt Nutzungsrisiken, SLA-Lücken und Budgetabweichungen, die sich über die Laufzeit summieren.


Was Hybrid-Betrieb im SAP-Kontext bedeutet

Hybrid-Betrieb im SAP-Kontext bezeichnet den dauerhaften Parallelbetrieb von mindestens zwei unterschiedlichen Systemkategorien: einem oder mehreren On-Premise-Systemen unter eigenem oder drittem Wartungsvertrag einerseits und einem RISE with SAP-Vertrag (S/4HANA Cloud Private Edition, PCE) andererseits.

Das unterscheidet ihn von der Dual-Use-Periode, die ein temporäres Phänomen ist. Die Dual-Use-Periode beschreibt den Parallelbetrieb während einer laufenden Migration, typisch sechs bis achtzehn Monate, mit dem Ziel, das On-Premise-System danach vollständig abzuschalten. Hybrid-Betrieb ist das Gegenteil: Es gibt keinen geplanten Abschalttermin für das On-Premise-System. Beide Umgebungen sind dauerhaft Teil der Betriebsarchitektur.

Typische Konstellationen in der Praxis:

  • ERP on-premise bleibt, weil die Systemkonvertierung für bestimmte Werke oder Gesellschaften aus technischen oder regulatorischen Gründen zurückgestellt wird. RISE läuft für den Rest der Organisation.
  • BW oder SolMan on-premise, weil die Migration dieser Systeme aus dem laufenden Betrieb heraus zeitlich nicht in das RISE-Projekt passt.
  • Spezialsysteme auf eigener Infrastruktur, weil Datensouveränität, Latenzanforderungen oder Add-on-Abhängigkeiten einen Cloud-Betrieb ausschließen.

In allen Fällen gilt: Zwei Vertragsregimes laufen parallel. Das ist kein Problem der Infrastruktur, sondern ein Problem der Vertragssteuerung.


Steuerungsmoment Nutzung: Wer hat welche Rechte auf welchem System?

Im Hybrid-Betrieb ist die Nutzungsrechtssituation komplex, weil dieselbe Person berechtigt sein kann, sowohl On-Premise-Systeme als auch das RISE-System zu nutzen, ohne dass zwei separate Lizenzen anfallen müssen. Die vertragliche Grundlage für diese Regelung liegt im RISE-Vertrag und im bestehenden On-Premise-Lizenzvertrag, und beide müssen konsistent sein.

Das FUE-Modell (Full Use Equivalent), das in RISE die Lizenzmetrik bildet, normiert verschiedene Benutzertypen auf eine einheitliche Vergleichsgröße. Wer als Advanced User in RISE lizenziert ist, hat andere Nutzungsrechte als ein Core User oder Self-Service User. In der On-Premise-Umgebung gelten die dort vereinbarten Named-User- oder Professional-User-Klassen.

Die entscheidende Frage für den Hybrid-Betrieb lautet: Welche On-Premise-Nutzungsrechte bleiben nach dem RISE-Vertragsabschluss erhalten, und welche erlöschen mit dem Beginn der Cloud-Subscription?

Das Cloud Extension Program, über das bestehende On-Prem-Kunden zu RISE wechseln, enthält Regelungen dazu, welche Nutzungsrechte in welchem Umfang auf die Cloud angerechnet oder aufrechterhalten werden. Diese Regelungen sind nicht standardisiert, sondern verhandlungsabhängig. Wer im Vertragstext keine explizite Formulierung zu On-Premise-Nutzungsrechten im Parallelbetrieb hat, bewegt sich in einer Grauzone.

Was der Vertrag regeln muss: Welche On-Premise-Systeme vom bestehenden Lizenzvertrag abgedeckt bleiben, für welchen Zeitraum, und ob und wie die FUE-Lizenzierung in RISE die On-Premise-Nutzung einschränkt oder ergänzt.


Steuerungsmoment Berechtigungen: Rollendesign als Lizenzkosten-Faktor

Im Hybrid-Betrieb verliert das Rollendesign seinen rein funktionalen Charakter und wird zu einem Lizenzkosten-Faktor. Das liegt an der FUE-Gewichtung in RISE: Ein Developer Access entspricht zwei FUE, ein Advanced User einem FUE, ein Core User einem Fünftel FUE. Wer ein zu breites Rollenprofil zuordnet, zahlt mehr als notwendig.

In On-Premise-Umgebungen wurde das Rollendesign häufig historisch gewachsen: Rollen wurden bei Projekten angelegt, selten bereinigt, und Benutzer erhielten im Zweifelsfall den breiteren Zugriff. Im Hybrid-Betrieb schlägt sich diese Historie direkt in der FUE-Abrechnung nieder, wenn Rollen aus On-Premise-Systemen ohne Überprüfung in die RISE-Umgebung übernommen werden.

Darüber hinaus entsteht ein Prüfungsaufwand im laufenden Betrieb: Wer hat auf welchem System welchen Zugriff, und stimmt das mit dem, was vertraglich lizenziert ist, überein? Im reinen On-Premise-Betrieb war das eine interne Governance-Aufgabe ohne direkte Abrechnungskonsequenz. Im Hybrid-Betrieb ist es eine Aufgabe mit direkter Budgetwirkung.

Was der Vertrag regeln muss: Wie Rollenzuordnungen zwischen On-Premise und RISE abgegrenzt sind, welche Prozesse das Rollendesign bei Änderungen auslöst, und wie Abweichungen zwischen lizenzierter und tatsächlicher Nutzung erkannt und korrigiert werden.


Steuerungsmoment Infrastruktur: Zwei SLA-Regimes unter einem Betriebsmodell

RISE with SAP beinhaltet ein definiertes SLA-Regime für die Cloud-Komponenten: SAP übernimmt Infrastruktur-Management, Patching, Backup, Security und 24/7-Monitoring für die PCE-Umgebung. On-Premise-Systeme haben kein äquivalentes Regime, es sei denn, ein separater AMS-Vertrag oder eine Outsourcing-Vereinbarung regelt das.

Im Hybrid-Betrieb entstehen dadurch SLA-Lücken an den Systemgrenzen. Wenn ein Prozess On-Premise und RISE-Systeme integriert, gilt der RISE-SLA für den Cloud-Teil, aber nicht für den On-Premise-Teil der Prozesskette. Störungen, die in der On-Premise-Komponente entstehen und sich auf die RISE-Umgebung auswirken, fallen in eine Verantwortungsgrauzone.

Die Hyperscaler-Wahl im RISE-Vertrag (Azure, AWS, Google Cloud) hat ebenfalls Bedeutung für den Hybrid-Betrieb, weil Komplementärservices wie Identity Management, Netzwerkanbindung oder Monitoring-Werkzeuge möglicherweise mit bestehender On-Premise-Infrastruktur zusammengeführt werden müssen. Azure ist der größte RISE-Partner und bietet die tiefste Integration mit On-Premise-Umgebungen über Microsoft Entra ID, was für Unternehmen mit bestehender Microsoft-Infrastruktur relevant ist.

Was der Vertrag regeln muss: Welche SLA-Verpflichtungen für welchen Systembereich gelten, wie Verantwortlichkeiten an Systemgrenzen definiert sind, und welche Prozesse bei Störungen greifen, die beide Umgebungen betreffen.


Steuerungsmoment Kosten: Zwei Abrechnungsregime parallel steuern

Im Hybrid-Betrieb laufen zwei Abrechnungsregime parallel: die On-Premise-Wartung nach dem bestehenden Lizenzvertrag und der RISE-ACV (Annual Contract Value) nach dem neuen Subscription-Modell. Beide haben unterschiedliche Rhythmen, unterschiedliche Bezugsgrößen und unterschiedliche Anpassungsmechanismen.

Die On-Premise-Wartung basiert auf der Maintenance Base, die sich aus den aktivierten Produkten, der Software-Version und gegebenenfalls dem Extended-Maintenance-Aufschlag ab 2028 zusammensetzt. Der RISE-ACV basiert auf FUE, Systemgröße, Edition und kontraktierten Zusatzmodulen.

Beide Größen können sich im Laufe der Hybrid-Betriebszeit verändern: Die Maintenance Base kann durch Lizenzaufgabe reduziert werden, der ACV kann durch Nutzerveränderungen oder Add-ons steigen. Wenn beide Entwicklungen nicht koordiniert beobachtet werden, entsteht eine Situation, in der das Gesamtbudget für SAP-Verträge schwer planbar ist.

Hinzu kommt die Frage der Maintenance Credits: Bestehende SAP ERP-Kunden können über das Cloud Extension Program Maintenance Credits gegen den RISE-ACV anrechnen. Diese Credits sind verhandlungsabhängig und zeitlich begrenzt. Im Hybrid-Betrieb muss klar sein, welche Credits auf welchen Teil der Subscription angerechnet werden, und ob On-Premise-Komponenten, die dauerhaft im Betrieb bleiben, überhaupt für Credits in Frage kommen.

Was der Vertrag regeln muss: Wie ACV und Maintenance Base getrennt nachverfolgt werden, welche Credits für welche Zeiträume und Produkttypen verfügbar sind, und wie Budgetabweichungen in beiden Regimes erkannt werden, bevor sie die Planung beeinflussen.


Fristenkette: Wann welche Entscheidung welchen Spielraum hat

Der mehrjährige Parallelbetrieb hat eine eigene Fristenkette, die von den Maintenance-Meilensteinen abhängt:

  • Bis 31.12.2027: On-Premise-Systeme unter Mainstream Maintenance. Kein Aufschlag, keine Pflicht-Entscheidung für Extended Maintenance.
  • Ab 01.01.2028: Wer On-Premise-Systeme unter EhP 6-8 weiter betreibt, zahlt Extended Maintenance mit zwei Prozentpunkten Aufschlag auf die gesamte Maintenance Base, sofern kein Wechsel zu PCE bis zu diesem Datum vollzogen wurde.
  • Bis 31.12.2030: Extended Maintenance verfügbar (kündbar 90 Tage zum Jahresende). Wer danach On-Premise-Komponenten weiter betreibt, benötigt entweder die Transition Option oder eine Drittpartei-Wartung.
  • Transition Option (Subskription 2028 bis 2030, Betrieb bis 31.12.2033): Für Unternehmen, die On-Premise-Systeme über 2030 hinaus benötigen. 20 Prozent Aufschlag gegenüber dem vergleichbaren PCE-Preis, Max Success Plan verpflichtend, nur EhP7 und EhP8 unterstützt.

Im Hybrid-Betrieb bedeutet diese Fristenkette: Wer dauerhaft On-Premise-Komponenten plant, muss bis spätestens Ende 2027 entschieden haben, welches Wartungsregime für welchen Systemteil gilt, und ob die Transition Option als Verlängerungsoption in Frage kommt.

Diese Entscheidung ist nicht losgelöst vom RISE-Vertrag. Wenn RISE und On-Premise beide langfristig laufen, bestimmt die Verhandlungsführung beider Verträge in welchem Umfang Credits, SLA-Abgrenzungen und Nutzungsrechte die Gesamtkosten beeinflussen.


Was ohne aktive Steuerung unkontrolliert bleibt

Hybrid-Betrieb ist kein Sonderzustand, der einmalig vertraglich geregelt wird und dann läuft. Er ist ein Dauerzustand mit laufenden Steuerungsaufgaben:

  • Wer auf welchem System Zugriff hat, verändert sich über die Zeit.
  • Die FUE-Verteilung in RISE verschiebt sich, wenn Prozesse zwischen On-Premise und Cloud neu zugeordnet werden.
  • Maintenance-Kosten für On-Premise-Systeme ändern sich mit den SAP-Fristentakten.
  • Credits haben Verfallsdaten, die ohne Monitoring nicht erkannt werden.

Die Herausforderung liegt nicht darin, dass Hybrid-Betrieb technisch komplex ist. Sie liegt darin, dass zwei unterschiedliche Vertragsregimes gleichzeitig beobachtet und koordiniert werden müssen, ohne dass ein zentrales System dafür vorgesehen ist.

Wer SAP-Verträge nach der Unterschrift nicht aktiv steuert, merkt die Konsequenzen eines schlecht geregelten Hybrid-Betriebs erst, wenn eine Maintenance-Rechnung nicht zum Budget passt, eine Lizenzprüfung Nutzungsrechte infrage stellt oder ein Renewal beide Vertragsregimes gleichzeitig betrifft.


Fazit

Dauerhafter Hybrid-Betrieb aus On-Premise und RISE ist kein technisches, sondern ein Steuerungsproblem. Die vier Bereiche, Nutzungsrechte, Berechtigungen, SLA-Abgrenzung und Budgetverfolgung, müssen im Vertragstext verankert und im laufenden Betrieb beobachtet werden.

Wer diese vier Bereiche aktiv steuert, behält Handlungsspielraum bei Veränderungen, Renewals und SAP-seitigen Fristen. Wer sie dem Zufall überlässt, trägt Budgetrisiken, die sich über mehrere Jahre summieren.

Nächste Schritte: Wenn Sie Hybrid-Betrieb planen oder bereits im Parallelbetrieb arbeiten, ist eine Bestandsaufnahme der Vertragsgrundlagen der erste Schritt. Unser Vertragscheck analysiert Ihre aktuelle Vertragssituation und zeigt auf, welche Regelungen fehlen und wo Handlungsbedarf besteht. Sprechen Sie uns an.

Naechste Schritte

Wenn Sie Ihren aktuellen Vertrag auf Risiken und verfuegbare kommerzielle Hebel pruefen lassen moechten: Der FinOptory Vertragscheck ist ein Festpreis-Engagement, das in vier Wochen eine strukturierte Grundlage liefert.

Dieser Beitrag gehört zum Themen-Hub On-Premise-Migration und SAP Transition Option. Für die Bewertung eines konkreten Vertrags liefert der FinOptory Vertragscheck in vier Wochen eine strukturierte Grundlage.

Bernhard Maendle
Verfasst von Bernhard Maendle Managing Consultant, FinOptory fuer SAP

Zuletzt aktualisiert: Juli 2026