Dual-Use-Periode: Governance beim Parallelbetrieb von On-Premise und Cloud ERP

Während der Migration auf RISE laufen zwei Systeme gleichzeitig: das bestehende On-Premise-System und die neue Cloud-Umgebung. Dieser Parallelbetrieb, in der Branche als Dual-Use-Periode bezeichnet, dauert typischerweise sechs bis achtzehn Monate. Wer ihn nicht aktiv steuert, verliert Überblick darüber, welche Nutzer auf welchem System lizenziert sind, wann welche Wartungskosten enden und wo das RISE-ACV beginnt. Die Governance-Anforderungen dieser Phase werden im Migrationsprojekt häufig erst spät sichtbar, obwohl sie sich im Vertrag frühzeitig abbilden lassen.

Was die Dual-Use-Periode ist und was sie nicht ist

Die Dual-Use-Periode beschreibt den Zeitraum, in dem ein Unternehmen sowohl seine On-Premise-Landschaft als auch die neu bereitgestellte RISE-Umgebung produktiv betreibt. Das ist kein Sonderfall: Fast jede Migration verläuft in Wellen. Nicht alle Geschäftsbereiche, Buchungskreise oder Systemklassen gehen gleichzeitig in Betrieb. Einzelne Systeme laufen weiter, bis der letzte Prozess migriert ist und der Cut-over vollständig abgeschlossen wurde.

Was diese Phase von einer einfachen Testumgebung unterscheidet: Beide Systeme sind produktiv. Nutzer arbeiten aktiv in beiden Umgebungen. Transaktionen werden auf beiden Seiten gebucht. Das hat direkte Konsequenzen für die Lizenzierung, die Wartungsabrechnung und die vertragliche Abgrenzung zwischen altem und neuem System.

Was die Dual-Use-Periode nicht ist: ein kostenfreier Übergangszeitraum. SAP räumt Dual-Use-Rechte im Rahmen des Cloud Extension Program ein, jedoch unter Bedingungen, die im Vertrag explizit geregelt sein müssen. Wer diese Rechte stillschweigend voraussetzt, ohne sie vertraglich verankert zu haben, bewegt sich in einer Grauzone.

Was SAP vertraglich erlaubt und was nicht

Das Cloud Extension Program ermöglicht es Bestandskunden, während der Migration vorübergehend sowohl On-Premise- als auch Cloud-Lizenzen zu nutzen, ohne für denselben Nutzer doppelt zu zahlen. Diese Dual-Use-Regelung ist jedoch an Voraussetzungen geknüpft:

Erstens muss der RISE-Vertrag bereits abgeschlossen sein, bevor die Dual-Use-Rechte in Kraft treten. Ein laufendes On-Premise-System ohne aktiven RISE-Vertrag ist kein Dual-Use, sondern normaler On-Premise-Betrieb mit voller Maintenance.

Zweitens ist die Dual-Use-Periode zeitlich begrenzt. Die zulässige Dauer wird im Vertrag festgelegt und variiert. Sie ist kein dauerhafter Hybrid-Betrieb. Wer dauerhaft parallel fahren will, braucht eine andere vertragliche Grundlage.

Drittens gilt die Dual-Use-Regelung für die Nutzerlizenzen, nicht automatisch für alle Komponenten der On-Premise-Landschaft. Add-ons, Third-Party-Maintenance-Verträge und AMS-Leistungen für das alte System laufen weiter, bis sie explizit gekündigt werden.

Ein häufiger Steuerungsmoment entsteht hier: Wartungsverträge für On-Premise-Systeme laufen weiter, auch wenn die Nutzung bereits auf RISE verlagert wurde. Wer keine systematische Nachverfolgung betreibt, zahlt für Maintenance, die keinen Gegenwert mehr liefert.

FUE-Lizenzierung im Parallelbetrieb: Wer wird wo gezählt?

Das FUE-Modell (Full Use Equivalent) normalisiert verschiedene Benutzertypen auf eine einheitliche Vergleichsgröße. Im RISE-Vertrag ist die FUE-Anzahl das zentrale Lizenzmaß. Im On-Premise-System hingegen sind Named User und deren Zugriffsprofile die Abrechnungsbasis.

Während der Dual-Use-Periode entsteht daraus eine praktische Herausforderung: Dieselbe Person kann auf beiden Systemen aktiv sein. Im On-Premise-System hat sie ein Rollenset aus der ECC-Landschaft. Im RISE-System erhält sie schrittweise ihren neuen Zugang in der S/4HANA Cloud Private Edition. Wenn keine aktive Steuerung stattfindet, bleibt sie in beiden Systemen vollständig lizenziert.

Genau hier liegt der erste Steuerungsmoment im Bereich Nutzung: Wer migriert wann vollständig? Ab welchem Datum ist ein Nutzer ausschließlich in RISE aktiv? Wann kann der On-Premise-Zugang deaktiviert werden? Ohne diese Datenbasis lässt sich weder die FUE-Anzahl optimieren noch die On-Premise-Lizenzstruktur gezielt abbauen.

Das FUE-Modell bietet dabei strukturell Spielraum: Wer Rollenbreite reduziert und Nutzertypen korrekt zuordnet, kann mehr Nutzer mit weniger FUE abdecken. In der Dual-Use-Phase ist dieser Spielraum allerdings begrenzt, weil Rollendefinitionen noch aus dem ECC-System stammen und oft erst im Zuge der Migration auf S/4HANA bereinigt werden. Das ist ein weiterer Grund, die Governance dieser Phase nicht dem Migrationsprojekt zu überlassen, das primär auf technischen Go-Live fokussiert ist.

Billing-Abgrenzung: Wann endet On-Premise-Wartung, wann beginnt RISE-ACV?

Die Abrechnungsgrenze zwischen altem und neuem System ist eine der häufigsten Quellen für Budgetabweichungen in der Migrationsphase.

Der RISE-ACV beginnt in der Regel mit Vertragsunterschrift oder zum vereinbarten Startdatum, unabhängig davon, wann der produktive Go-Live stattfindet. In der Praxis bedeutet das: Unternehmen zahlen für RISE, während das On-Premise-System noch in voller Produktion läuft. Wer das Startdatum des RISE-Vertrags nicht aktiv steuert und mit der realen Migrationsplanung synchronisiert, baut unnötige Doppelkosten auf.

Auf der On-Premise-Seite gilt: Maintenance-Verträge laufen bis zur Kündigung. Es gibt keine automatische Abrechnung auf Basis der tatsächlichen Systemnutzung. Wer sein On-Premise-System am 1. März abschaltet, zahlt die Maintenance bis zum nächsten Kündigungstermin, wenn er nicht rechtzeitig kündigt.

Die Kündigung der On-Premise-Maintenance hat typischerweise eine Frist von neunzig Tagen zum Jahresende. Das bedeutet: Wer im Oktober produktiv auf RISE geht, muss die Kündigung spätestens im September eingereicht haben, um ab dem 1. Januar nicht weiter zu zahlen. Wer diesen Steuerungsmoment im Bereich Kosten verpasst, zahlt ein weiteres Jahr.

Dasselbe gilt für Third-Party-Maintenance-Verträge, AMS-Vereinbarungen für das alte System und etwaige Infrastrukturverträge für On-Premise-Hardware oder Co-Location. Sie alle haben eigene Laufzeiten und Kündigungsfristen, die nichts mit dem RISE-Startdatum zu tun haben.

Vier Steuerungsmomente in der Dual-Use-Phase

Die Dual-Use-Periode verändert die Grundstruktur der Vertragssteuerung nicht, sie verschiebt jedoch die Gewichte. Alle vier Steuerungsbereiche sind aktiv, und in jedem entstehen spezifische Governance-Aufgaben:

Nutzung: FUE-Verteilung zwischen On-Premise-Nutzern und Cloud-Nutzern muss laufend beobachtet werden. Wer in welchem System aktiv ist, verändert sich wöchentlich während einer gestaffelten Migration. Ohne aktives Tracking wird das Ergebnis erst beim nächsten Vermessungsdatum sichtbar, wenn SAP das ACV-Profil prüft.

Berechtigungen: Rollendesign aus ECC wird auf S/4HANA übertragen. Dabei entscheidet die Rollenbreite darüber, welchem FUE-Typ ein Nutzer zugeordnet wird. Ein zu weit gefasstes Rollenset kostet mehr FUE als notwendig. Die Migration ist der Moment, an dem Rollendesign und Lizenzoptimierung zusammenfallen. Dieser Steuerungsmoment lässt sich in der Dual-Use-Phase nutzen oder, wenn keine Systematik dahintersteht, verpassen.

Infrastruktur: Auf der On-Premise-Seite laufen SLAs weiter, die nicht mehr dem tatsächlichen Schutzbedarf entsprechen. Auf der RISE-Seite gelten die vereinbarten SLAs im Hyperscaler-Modell. Der Abgleich zwischen beiden SLA-Welten gehört zur Infrastruktur-Governance der Migrationsphase. Wer Hyperscaler-Wahl und SLA-Parameter nicht im Vertrag verankert hat, bemerkt Abweichungen erst im Betrieb.

Kosten: ACV-Tracking während der Ramp-up-Phase, Maintenance-Credits gegen ACV verrechnen, On-Premise-Maintenance gezielt kündigen, Extended-Maintenance-Aufschlag als separate Budget-Position führen. Diese vier Aufgaben fallen gleichzeitig an und greifen ineinander. Eine systematische Übersicht darüber, was gerade auf welchem System läuft und was welche Kosten verursacht, ist die Voraussetzung dafür, dass keine Position vergessen wird.

Governance-Lücken im Parallelbetrieb: Was systematisches Monitoring leisten muss

Die zentrale Herausforderung der Dual-Use-Phase liegt nicht in der technischen Komplexität, sondern in der Datenlage. Die Frage "Wer nutzt gerade was auf welchem System?" lässt sich aus dem RISE-Vertrag nicht ablesen. Sie lässt sich aus dem On-Premise-Lizenzkataster nicht ablesen. Sie erfordert eine eigene Monitoring-Schicht, die beide Welten zusammenführt.

Drei Governance-Lücken treten in der Praxis häufig auf:

Erstens die Nutzungs-Lücke: Beide Systeme werden vermessen, aber nicht synchronisiert. Wer auf beiden Systemen Active User zählt, ohne den Überschneidungsbereich zu kennen, kann keine FUE-Optimierung vornehmen.

Zweitens die Kosten-Lücke: Maintenance-Kosten für das alte System, ACV-Kosten für das neue System und laufende Projektkosten der Migration werden in verschiedenen Budget-Positionen geführt. Eine konsolidierte Sicht auf die Gesamtkosten der Übergangsphase fehlt, bis der Controller nach dem Jahresabschluss zurückrechnet.

Drittens die Fristen-Lücke: Kündigungsfristen für Wartungsverträge, Laufzeiten von AMS-Verträgen, Abschaltzeitpunkte für On-Premise-Systeme und Ramp-up-Meilensteine im RISE-Vertrag liegen in unterschiedlichen Dokumenten. Wer die nächste relevante Frist immer erst dann kennt, wenn sie akut wird, verliert Handlungsspielraum.

Systematisches Monitoring in der Dual-Use-Phase bedeutet deshalb: eine gemeinsame Datenbasis, die Vertragsfristen, Nutzungsdaten und Kostenpositionen beider Systeme zusammenführt und Steuerungsmomente sichtbar macht, bevor sie eintreten.

Was nach der Dual-Use-Periode zur Steuerungsaufgabe wird

Die Dual-Use-Periode endet mit dem vollständigen Abschalten des On-Premise-Systems. Ab diesem Zeitpunkt ist RISE die einzige produktive Umgebung. Die laufende Steuerungsaufgabe verändert sich: An die Stelle der Doppel-Governance tritt die Steuerung eines einzigen, aber komplexen Vertragswerks.

Was bleibt, ist die Datenbasis, die während der Migration aufgebaut wurde. Wer in der Dual-Use-Phase sauber dokumentiert hat, welche Nutzer wann migriert wurden, welche Rollenänderungen vorgenommen wurden und welche Verträge zu welchem Zeitpunkt beendet wurden, hat nach dem Go-Live eine belastbare Ausgangslage für die laufende FUE-Steuerung, den SLA-Abgleich und das ACV-Tracking.

Wer diese Dokumentation nicht aufgebaut hat, beginnt die Post-Go-Live-Steuerung ohne Vergleichsbasis. Budgetabweichungen lassen sich dann nicht mehr auf konkrete Migrationsentscheidungen zurückführen.

Die Frage, wer SAP-Verträge nach der Unterschrift steuert, gilt damit nicht erst nach dem finalen Go-Live. Sie gilt schon in dem Moment, in dem zwei Systeme parallel laufen und Entscheidungen über Nutzung, Berechtigungen, Infrastruktur und Kosten täglich anfallen.

Weiterführende Artikel:

Pillar 7: SAP On-Premise Migration, Maintenance-Ende 2027 und Vertragssteuerung: Hub-Page mit vollständiger Übersicht
On-Prem-Lizenzanrechnung auf RISE: Credits, Mechanik und Verhandlungsposition: Cluster 4: Wie Maintenance-Credits gegen RISE-ACV verrechnet werden
Die neun SAP-Produkttypen und ihre Vertragsstruktur: Pillar 1: Welche Produkttypen in der Migration eine eigene Governance brauchen

Sie steuern gerade eine Migration oder planen den Übergang auf RISE? Ein Vertragscheck schafft Klarheit über Ihre Fristen, Credits und Governance-Lücken in vier Wochen. Festpreis 7.900 EUR.

Erstgespräch vereinbaren