On-Premise Migration und SAP Transition Option: Maintenance-Ende BS7 strategisch steuern

Das Mainstream-Maintenance-Ende für SAP ERP 6.0 EhP 6-8 fällt auf den 31. Dezember 2027. Ab dem 1. Januar 2028 beginnt Extended Maintenance mit einem Aufschlag von zwei Prozentpunkten auf die Maintenance Base. Wer bis dahin auf RISE (PCE) gewechselt hat, trägt diesen Aufschlag nicht. Die Transition Option verlängert den On-Prem-Betrieb bis Ende 2033, kostet aber 20 Prozent Aufschlag auf den vergleichbaren Cloud-Preis und verpflichtet zu einem Max Success Plan. Zwischen diesen Optionen liegen erhebliche Unterschiede in Vertragsmechanik, Lizenzanrechnung und Verhandlungsposition. Wer die Wahl jetzt strukturiert bewertet, behält Handlungsspielraum.

Inhaltsverzeichnis

1. Maintenance-Timeline: Was Ende 2027 bedeutet
2. Drei Szenarien ab 2028: On-Prem, Cloud, Hybrid
3. Extended Maintenance: Mechanik und Kosten
4. Transition Option: Mechanik, Fristen, Aufschlag
5. Die neun SAP-Produkttypen im On-Prem-zu-Cloud-Vergleich
6. Lizenzanrechnung: On-Prem-Credits gegen RISE-ACV
7. Dual-Use-Periode: Governance während der Migration
8. Add-on Product Versions in der Transition Option
9. Shelfware verwerten statt verfallen lassen
10. Vier Steuerungsmomente in der Migrationsphase
11. Vertragssteuerung nach der Unterschrift: Was jetzt beginnt
12. FAQ
13. Nächste Schritte

---

Maintenance-Timeline: Was Ende 2027 bedeutet {#maintenance-timeline-was-ende-2027-bedeutet}

Drei Daten strukturieren den Handlungsraum für On-Premise-Betreiber: Ende 2027, der 1. Januar 2028 und der 31. Dezember 2030. Wer diese Eckpunkte kennt, kann Optionen sachlich bewerten. Wer sie nicht kennt, trifft Entscheidungen mit unvollständiger Informationsbasis.

Das Ende von Mainstream Maintenance für SAP ERP 6.0 EhP 6-8 ist kein neues Thema, aber es rückt 2026 und 2027 in den unmittelbaren Planungshorizont. Die Vorlaufzeiten für eine fundierte Entscheidung, ob Cloud-Migration, Extended Maintenance oder Transition Option, liegen bei 12 bis 24 Monaten. Das bedeutet: Wer Ende 2026 keine Entscheidung getroffen hat, verliert Handlungsspielraum.

Was Mainstream Maintenance leistet und was danach nicht mehr gilt

Mainstream Maintenance umfasst Legal Changes (gesetzliche Anforderungen wie steuerliche und regulatorische Updates), Support Packages, Fehlerkorrektur und Problem Resolution. Bis Ende 2027 erhalten SAP ERP 6.0 EhP 6-8-Systeme diesen vollständigen Service-Umfang ohne Aufschlag.

Mit dem Ende von Mainstream Maintenance entfällt kein unmittelbarer Systemstillstand. Die Software läuft weiter. Was entfällt, ist die aktive Weiterentwicklung und die reguläre gesetzliche Pflege. In regulierten Branchen ist das ein relevanter Punkt: Steuerliche Änderungen, Meldepflichten und Compliance-Anforderungen werden nach 2027 nicht mehr automatisch im Rahmen der Standard-Wartung eingespielt.

Welche EhP-Versionen betroffen sind

Nicht alle EhP-Versionen laufen bis Ende 2027. EhP 0-5 hat bereits Ende 2025 das Ende von Mainstream Maintenance erreicht. Diese Systeme befinden sich seit dem 1. Januar 2026 im Customer Specific Maintenance-Modus (CSM), der gesonderte Vereinbarungen erfordert.

EhP 6, 7 und 8 laufen bis zum 31. Dezember 2027 unter Mainstream Maintenance. Das ist die Gruppe, für die Extended Maintenance und Transition Option als strukturierte Verlängerungswege vorgesehen sind.

Solution Manager 7.2 folgt der BS7-Strategie

Solution Manager 7.2 ist eng an die BS7-Maintenance-Strategie gekoppelt. Mainstream Maintenance endet ebenfalls Ende 2027. Extended Maintenance für SolMan 7.2 ist automatisch in der BS7-Extended-Maintenance enthalten und läuft bis Ende 2030. Es wird kein neues SolMan-Release nach 7.2 geben. Der Nachfolger für ALM-Anforderungen ist SAP Cloud ALM, das im RISE-Paket enthalten ist.

NetWeaver BW: Embedded und Standalone im Unterschied

Bei NetWeaver BW ist zwischen eingebettetem und Stand-alone-BW zu unterscheiden. Embedded BW, das als Teil des BS7-Systems betrieben wird, folgt dem BS7-Zyklus. Stand-alone BW hat einen eigenen Maintenance-Zyklus, der in SAP Note 2741041 dokumentiert ist und von der BS7-Timeline abweicht.

Compatibility Scope Use Rights: Vier Konstellationen

Compatibility Items, also Funktionsbereiche, die in S/4HANA nicht mehr in der Standardfunktionalität enthalten sind, unterliegen eigenen Fristen. Vier Konstellationen sind relevant:

1. Nutzung unter Cloud-Subscription: Erweiterte Nutzungsrechte bis 2030
2. On-Prem-S/4HANA mit Cloud-Vertrag (mindestens 50 Prozent der Maintenance Base konvertiert oder ACV mindestens 50 Prozent der Maintenance Base): Erweitert bis 2030
3. On-Prem-S/4HANA mit separat lizenzierter Cloud-Lösung: Erweitert für das spezifische Item
4. Alle anderen Fälle: Ende der Compatibility-Nutzungsrechte Ende 2025

Die relevante SAP Note für die Compatibility Scope Matrix ist SAP Note 2269324.

Schlüsseldaten im Überblick

Datum	Ereignis
Ende 2025	End of Compatibility Scope für nicht qualifizierte On-Prem-S/4HANA-Systeme
31.12.2027	End of Mainstream Maintenance SAP ERP 6.0 EhP 6-8 und SolMan 7.2
01.01.2028	Start Extended Maintenance (+2 Prozentpunkte On-Prem); RISE/PCE-Bedingung
31.12.2030	Ende Extended Maintenance, SolMan Extended, Compatibility Scope Cloud
2031-2033	Transition Option (20 Prozent Aufschlag, Max Success Plan Pflicht)

---

Drei Szenarien ab 2028 {#drei-szenarien-ab-2028}

Ab dem 1. Januar 2028 gibt es für On-Premise-Betreiber drei klar abgrenzbare Wege. Jeder Weg hat eine eigene Vertragsmechanik, ein eigenes Budgetprofil und eigene Steuerungsmomente. Eine Entscheidung ohne Vertragsanalyse ist in keinem der drei Szenarien belastbar.

Szenario 1: Gesamte Landschaft auf RISE (SAP ERP Private Cloud Edition)

Wer die gesamte Systemlandschaft bis zum 1. Januar 2028 in die SAP ERP Private Cloud Edition (PCE) überführt hat, trägt keinen Extended-Maintenance-Aufschlag. Extended Maintenance ist im Subscription-Preis des RISE-Vertrags enthalten. Das ist die strukturell einfachste Lösung, aber sie setzt voraus, dass alle Systeme bis zu diesem Stichtag in PCE betrieben werden.

"Alle Systeme" ist dabei wörtlich zu nehmen: Einzelne Systeme außerhalb von PCE zu lassen und für diese Extended Maintenance zu beantragen, ist grundsätzlich möglich, führt aber zur Parallelstruktur von zwei unterschiedlichen Vertragsregimen. Für die Steuerungsmomente in Nutzung, Berechtigungen, Infrastruktur und Kosten bedeutet das erhöhten Koordinationsaufwand.

Szenario 2: Komplett On-Premise (BS7 Extended Maintenance)

Wer On-Premise bleibt, benötigt ab dem 1. Januar 2028 ein Extended-Maintenance-Addendum zum bestehenden Wartungsvertrag. Die Basis für den Aufschlag ist die Maintenance Base aller BS7 Core Applications, Add-ons und Runtime-Datenbanken. Der Aufschlag beträgt zwei Prozentpunkte auf diese Basis.

Wichtig für die Planung: Extended Maintenance gilt nicht selektiv. Wer Extended Maintenance beantragt, beantragt sie für die gesamte Landschaft. Einzelne Systeme auszuklammern ist nicht möglich. Diese All-or-Nothing-Regel ist einer der häufigsten Irrtümer bei der Planung.

Szenarien 3 und 4: S/4HANA Contract Conversion und Product Conversion

Zwei weitere Wege erlauben eine Optimierung der Maintenance-Base durch gezieltes Aufgeben nicht benötigter Nutzungsrechte:

Bei der S/4HANA Contract Conversion werden klassische ERP-Term-Lizenzen, die noch produktiv sind, umgewandelt. Nicht mehr benötigte Nutzungsrechte können aufgegeben werden, was die Maintenance Base reduziert. Der Extended-Maintenance-Aufschlag von zwei Prozent wird dann auf die reduzierte Basis berechnet.

Bei der S/4HANA Product Conversion werden kumulierte Lizenzen minus bereits konvertierter SKUs zur Berechnungsgrundlage. Die verbliebenen niedrigsten rabattierten SKUs bilden die Basis. Auch hier: zwei Prozent auf die reduzierte Basis.

Was All-or-Nothing bei Extended Maintenance bedeutet

Die All-or-Nothing-Regel ist ein strukturell relevanter Governance-Punkt. Sie bedeutet: Wer auch nur ein On-Premise-System im BS7-Betrieb hat und Extended Maintenance beantragen will, muss das für die gesamte BS7-Landschaft tun. Cherry-Picking nach System ist nicht möglich.

Die praktische Konsequenz: Unternehmen, die einen Stufenplan für die Cloud-Migration haben (zuerst ein Werk, dann das nächste), tragen für die in On-Prem verbleibenden Systeme den vollen Extended-Maintenance-Aufschlag auf die gesamte Basis, nicht nur auf die noch nicht migrierten Systeme.

Der Steuerungsmoment im Bereich Kosten liegt hier in der präzisen Kenntnis der Maintenance Base vor dem Stichtag. Wer nicht weiß, aus welchen Positionen die Maintenance Base besteht, kann weder die Kosten der Extended Maintenance belastbar kalkulieren noch die Optimierungspotenziale durch Lizenzaufgabe strukturiert ausschöpfen.

---

Extended Maintenance: Mechanik und Kosten {#extended-maintenance-mechanik-und-kosten}

Extended Maintenance ist kein automatischer Folgeschritt nach Ende 2027. Es ist ein kostenpflichtiges Addendum mit klaren Bedingungen, einem definierten Scope und einem festen Enddatum.

Zeitraum und Kündigungsfristen

Extended Maintenance läuft vom 1. Januar 2028 bis zum 31. Dezember 2030. Das Addendum kann mit 90 Tagen Frist zum Jahresende gekündigt werden. Am 31. Dezember 2030 endet Extended Maintenance automatisch, unabhängig davon, ob ein Unternehmen bis dahin migriert hat oder nicht.

Nach 2030 gibt es für On-Premise-BS7-Systeme keine strukturierte SAP-Maintenance mehr. Ausnahme: die Transition Option, die aber ein eigenes Vertragsregime darstellt und nicht als Verlängerung von Extended Maintenance konzipiert ist.

Preisstruktur: Was zur Maintenance Base gehört

Der Extended-Maintenance-Aufschlag beträgt zwei Prozentpunkte auf die Maintenance Base. Die Maintenance Base umfasst alle BS7 Core Applications, alle Add-ons und die Runtime-Datenbank.

Ein konkretes Rechenbeispiel: Ein Unternehmen mit 22 Prozent Enterprise Support und einer Maintenance Base von einer Million Euro zahlt ab 2028 24 Prozent auf diese Basis, also 240.000 Euro pro Jahr statt bisher 220.000 Euro. Das ist eine Mehrbelastung von 20.000 Euro pro Jahr oder 60.000 Euro über die drei Jahre Extended Maintenance.

Scope: Was Extended Maintenance leistet und was nicht

Der Scope von Extended Maintenance entspricht dem von Mainstream Maintenance: Legal Changes, Support Packages und Problem Resolution. Was Extended Maintenance nicht liefert: keine neuen Funktionen, kein Innovationszugang, kein Zugang zu AI-Funktionen, kein Pfad in Richtung Cloud. Es ist die Verlängerung des Status quo ohne Weiterentwicklung.

Das ist keine Kritik an Extended Maintenance als Option, sondern eine Beschreibung des Leistungsumfangs, die für die Bewertung relevant ist. Wer Innovationsdruck hat oder regulatory Pflichten hat, die neue Funktionalität erfordern, braucht einen anderen Weg.

Optimierungspotenzial: Maintenance Base durch Lizenzaufgabe reduzieren

Einer der bedeutendsten Steuerungsmomente im Bereich Kosten vor dem Start von Extended Maintenance liegt in der Reduktion der Maintenance Base. Durch gezieltes Aufgeben nicht mehr benötigter Nutzungsrechte kann die Basis erheblich verkleinert werden.

Ein abstraktes Rechenbeispiel zeigt das Optimierungspotenzial:

Maintenance Base vor Optimierung:           1.000.000 EUR
- Nicht benötigte Produkte (z. B. BO):       -200.000 EUR
- ECC-Engines (in S/4HANA abgedeckt):        -500.000 EUR
- User-Reduktion (3.000 auf 300 BW-User):    -270.000 EUR
Verbleibende Maintenance Base:                 30.000 EUR
Extended Maintenance (2%):                        600 EUR/Jahr

Diese Rechnung zeigt: Die Differenz zwischen einer unbereinigten und einer bereinigten Maintenance Base kann den Extended-Maintenance-Aufschlag von einem erheblichen Posten auf einen marginalen Betrag reduzieren. Die Voraussetzung ist eine sorgfältige Bestandsaufnahme der tatsächlich genutzten Nutzungsrechte.

Was Extended Maintenance nicht leistet

Zur Vollständigkeit: Extended Maintenance bietet keinen Zugangspfad zu SAP Business AI, keinen Joule-Zugang, keine neuen BTP-Entitlements und keine Vorbereitung auf S/4HANA-Migration über den Standard-Support hinaus. Unternehmen, die Extended Maintenance wählen, betreiben damit eine Plattform, die sich seit 2016 nicht mehr substantiell weiterentwickelt. Diese Einschätzung ist für die strategische Positionierung und für das CFO-Gespräch relevant.

---

Transition Option: Mechanik, Fristen, Aufschlag {#transition-option-mechanik-fristen-aufschlag}

Die Transition Option ist der letzte strukturierte Verlängerungsweg für Unternehmen, deren IT-Landschaft mehr Zeit für eine vollständige Cloud-Migration benötigt. Sie verlängert den On-Prem-Betrieb über das Ende von Extended Maintenance hinaus bis Ende 2033, aber zu anderen Konditionen.

Was die Transition Option ist

Formal handelt es sich bei der Transition Option um SAP ERP Private Edition im Cloud-Betrieb, konzipiert für Kunden mit EhP 7 oder EhP 8. Die Systeme werden in einer SAP-verwalteten Cloud-Umgebung (Private Cloud Edition) gehostet, behalten aber im Kern die ECC-6.0-Architektur. Die Transition Option ist kein Dauerbetrieb und kein Ersatz für die S/4HANA-Migration.

Subskriptionsfenster und Service-Start

Das Subskriptionsfenster für die Transition Option ist 2028 bis 2030. Das bedeutet: Wer die Transition Option nutzen will, muss den Vertrag zwischen Anfang 2028 und Ende 2030 abschließen. Service-Start ist frühestens der 1. Januar 2031, Maximallaufzeit ist der 31. Dezember 2033.

Diese Fristenkette ist für Entscheidungsverantwortliche relevant, weil sie einen klaren Entscheidungskalender vorgibt. Wer bis Ende 2030 keinen Transition-Option-Vertrag abgeschlossen hat, hat diesen Weg nicht mehr zur Verfügung.

Preisaufschlag: 20 Prozent auf den vergleichbaren Cloud-Preis

Der Preisaufschlag für die Transition Option beträgt 20 Prozent gegenüber dem vergleichbaren Preis einer regulären SAP ERP Private Edition. Ausnahme: Unternehmen, die sich vor Ende 2025 für die Transition Option subskribiert haben, tragen diesen Aufschlag nicht.

Der 20-Prozent-Aufschlag wird auf den Cloud-Preis der vergleichbaren Private Edition berechnet, nicht auf die bisherige On-Prem-Maintenance-Base. Das ist ein wichtiger Unterschied bei der Budgetkalkulation.

Mindestanforderungen: 2 TB und Max Success Plan

Zwei Mindestanforderungen gelten für die Transition Option:

Erstens die Mindestgröße von 2 TB. Systeme unter dieser Größe sind grundsätzlich nicht für die Transition Option qualifiziert.

Zweitens der Max Success Plan Transition Services. Dieser Plan ist bei der Transition Option verpflichtend und erzeugt zusätzliche Kosten über den Grundpreis hinaus. Der Max Success Plan umfasst erweiterte Support- und Beratungsleistungen von SAP, die spezifisch auf Migrations- und Transformationsszenarien ausgerichtet sind.

EhP-Voraussetzung: Nur EhP 7 und EhP 8

Die Transition Option unterstützt ausschließlich EhP 7 und EhP 8 für SAP ERP 6.0. Unternehmen mit älteren EhP-Versionen, also EhP 0 bis 6, müssen vor dem Wechsel in die Transition Option zunächst auf mindestens EhP 7 hochgerüstet werden. Das ist ein separates Projekt, das in die Gesamtplanung einbezogen werden muss.

Was die Transition Option nicht ist

Die Transition Option ist kein Dauerzustand. Sie ist eine befristete Brücke, deren Ende am 31. Dezember 2033 feststeht. Unternehmen, die die Transition Option nutzen, stehen spätestens Ende 2033 vor derselben Migrationsentscheidung, nur mit weniger Vorlaufzeit. Die Transition Option kauft Zeit, sie löst die strategische Herausforderung nicht.

Fristenkette für Entscheidungsverantwortliche

Eine strukturierte Rückwärtsplanung zeigt, welche Entscheidungen wann getroffen werden müssen:

• Bis Ende 2026: Entscheidung über Grundszenario (Cloud vs. On-Prem) auf Basis einer aktuellen Maintenance-Base-Analyse
• Bis Mitte 2027: Vertragsverhandlungen für Extended Maintenance oder RISE-Migration abschließen
• Bis Ende 2027: Systeme in PCE oder Extended-Maintenance-Addendum unterschrieben
• 2028-2030: Subskriptionsfenster für die Transition Option offen, falls benötigt
• 01.01.2031: Service-Start Transition Option
• 31.12.2033: Ende Transition Option, keine weitere strukturierte SAP-Verlängerung

---

Die neun SAP-Produkttypen im On-Prem-zu-Cloud-Vergleich {#die-neun-sap-produkttypen-im-vergleich}

Die Diskussion über Maintenance-Ende und Migration fokussiert sich häufig auf SAP ERP. Der Steuerungsmoment im Bereich Infrastruktur zeigt jedoch: On-Premise betrifft nicht nur ERP. Wer migriert, migriert ein Portfolio aus mehreren Produkttypen, die unterschiedliche Maintenance-Zyklen, unterschiedliche Cloud-Pendants und unterschiedliche Vertragsregime haben.

On-Premise-Kernprodukte und ihre spezifischen Maintenance-Zyklen

Die Kernprodukte im On-Prem-Portfolio, die direkt von der BS7-Maintenance-Timeline betroffen sind, umfassen SAP ERP (EhP 6-8, Mainstream bis Ende 2027), NetWeaver BW als eingebettetes System (folgt BS7-Zyklus) und Solution Manager 7.2 (Mainstream bis Ende 2027, Extended bis Ende 2030).

Jedes dieser Produkte hat eigene Maintenance-Mechaniken und muss separat in die Migrationsstrategie einbezogen werden.

RISE als Migrationsziel: Was enthalten ist und was separat bleibt

RISE with SAP (SAP Cloud ERP Private Edition) bündelt S/4HANA Cloud Private Edition, BTP-Basisentitlements und technischen Betrieb in einem Vertrag. Was im RISE-Paket enthalten ist, hängt von der gewählten Tier-Stufe ab.

Wichtig für die Steuerungsmomente im Bereich Kosten: BTP-Entitlements sind im RISE-Paket in einem Basisumfang vorhanden. Ob dieser Basisumfang für die tatsächliche Nutzung ausreicht, hängt von den geplanten Erweiterungen und Use Cases ab. Zusätzliche BTP-Kapazitäten werden separat beschafft.

Produkttypen mit eigenem Vertragszyklus

Nicht alle SAP-Produkttypen folgen dem RISE-Vertrag automatisch. SuccessFactors, Ariba und Concur haben eigene Cloud-Subscriptions und werden nicht automatisch in eine RISE-Migration einbezogen. Wer migriert, migriert das ERP-Kernsystem, nicht die gesamte SAP-Software-Landschaft in einem einzigen Schritt.

Das bedeutet für den Steuerungsmoment in Kosten: Nach einer RISE-Migration können mehrere separate Vertragsregime nebeneinander existieren, die unterschiedliche Renewal-Termine, unterschiedliche ACV-Profile und unterschiedliche Governance-Anforderungen haben. Eine konsolidierte Steuerung aller SAP-Verträge ist damit wichtiger, nicht weniger wichtig, als vor der Migration.

BTP-Entitlements im RISE-Paket

BTP-Entitlements sind im RISE-Paket enthalten, ihr tatsächlicher Wert hängt jedoch von Edition und Nutzungsintensität ab. Wer BTP für Integrationen, Erweiterungen oder AI-Workloads nutzen will, sollte vor dem Vertragsabschluss prüfen, ob die enthaltenen Entitlements den geplanten Bedarf abdecken. Fehlende Entitlements müssen nachverhandelt oder separat beschafft werden.

Der Steuerungsmoment im Bereich Infrastruktur liegt beim BTP-Portfolio darin, die tatsächliche Nutzung der enthaltenen Entitlements zu kennen. RISE-Verträge enthalten häufig BTP-Services, die lizenziert, aber nicht aktiviert oder genutzt werden. Diese ungenutzten Entitlements sind verlorener Wert, der in regelmäßigen Reviews erkannt und aktiviert oder in Vertragsverhandlungen als Argument für eine Anpassung eingebracht werden kann.

Gleichzeitig gilt: BTP-Kapazitäten, die über den enthaltenen Basisumfang hinausgehen, verursachen zusätzliche Kosten. Wer geplante BTP-Use-Cases erst nach Vertragsabschluss konkretisiert, stellt häufig fest, dass der Basisumfang nicht ausreicht. Eine frühzeitige BTP-Bedarfsanalyse gehört deshalb zur Vorbereitung des RISE-Vertragsabschlusses.

---

Lizenzanrechnung: On-Prem-Credits gegen RISE-ACV {#lizenzanrechnung-on-prem-credits-gegen-rise-acv}

Bestehende SAP ERP- und On-Prem-S/4HANA-Kunden können über das Cloud Extension Program Credits auf einen RISE-Vertrag anrechnen. Das ist einer der bedeutendsten Steuerungsmomente im Bereich Kosten bei einer Migration: Die Höhe der anrechenbaren Credits ist verhandlungsabhängig und zeitgebunden.

Drei Credit-Typen

SAP stellt drei Typen von Credits zur Verfügung:

Maintenance Credits werden gegen künftige On-Prem-Wartungsrechnungen verrechnet. Sie sind relevant für Unternehmen, die den Wechsel zu RISE planen, aber noch laufende Maintenance-Zahlungen haben.

Service Credits werden gegen Services-SKUs verrechnet, zum Beispiel gegen Implementierungs- oder Beratungsleistungen von SAP.

Cloud Credits werden direkt gegen Cloud-Vertragsrechnungen verrechnet, also gegen den ACV eines RISE-Vertrags.

Eligibility: Wer anrechnen darf

Anrechnungsberechtigt sind SAP ERP- und On-Prem-S/4HANA-Kunden, die über das Cloud Extension Program zu RISE oder GROW wechseln. Die Berechtigung ist an das Programm gebunden, nicht automatisch vorhanden.

In der Praxis bedeutet das: Wer die Anrechnung nutzen will, muss das Cloud Extension Program aktiv im Rahmen der Vertragsverhandlung einbringen. Credits entstehen nicht automatisch und werden nicht automatisch kommuniziert. Hier liegt ein konkreter Steuerungsmoment im Bereich Kosten, den eine strukturierte Vorbereitung der Vertragsverhandlung adressiert.

Wie Credits gegen ACV verrechnet werden

Die Verrechnung erfolgt über das Order Form des RISE-Vertrags. Maintenance Credits können als Einmalzahlung gegen den ACV des ersten Vertragsjahres verrechnet werden oder auf mehrere Jahre verteilt werden, je nach Verhandlungsergebnis.

Wichtig: Die Höhe der anrechenbaren Credits ist nicht öffentlich tabelliert. Sie ist verhandlungsabhängig und hängt unter anderem von der Maintenance-Base-Höhe, dem RISE-ACV-Volumen und dem Zeitpunkt der Verhandlung ab.

Warum Frühzeitigkeit die Verhandlungsposition stärkt

Je früher ein Unternehmen in die Verhandlung eintritt, desto mehr Handlungsspielraum besteht auf beiden Seiten. SAP hat ein Interesse daran, Kunden frühzeitig in die Cloud zu bewegen. Dieses Interesse ist am stärksten, wenn das Maintenance-Ende noch 18 bis 24 Monate entfernt ist. Wer 6 Monate vor Ende 2027 verhandelt, verhandelt mit deutlich weniger Optionen und deutlich mehr Zeitdruck.

Was nicht automatisch angerechnet wird

Add-ons, Application Management Services (AMS)-Verträge und Drittpartei-Wartungsverträge werden nicht automatisch in die Credit-Berechnung einbezogen. Wer Add-on-Credits anrechnen will, muss das explizit verhandeln und nachweisen.

Auch Shelfware, also bezahlte, aber ungenutzte Lizenzen, wird nicht automatisch als Credit berücksichtigt. Shelfware ist ein separates Verhandlungsargument, das in Sektion 9 behandelt wird.

Steuerungsmoment Kosten: Verrechnung vertraglich verankern

Der Steuerungsmoment im Bereich Kosten liegt hier in der vertraglichen Verankerung der Credit-Verrechnung. Mündliche Zusagen sind kein Vertragsbestandteil. Was im Order Form steht, gilt. Was nicht im Order Form steht, existiert vertraglich nicht.

Für die vier Rollen, die an dieser Entscheidung beteiligt sind, bedeutet das konkret:

Der Contract Manager verantwortet die Prüfung, ob vereinbarte Credits im Order Form korrekt abgebildet sind und mit welchem Timing die Verrechnung stattfindet.

Procurement verantwortet die Verhandlung der Credit-Bedingungen und die Dokumentation der Verhandlungsbasis, auf die bei späteren Renewal-Verhandlungen zurückgegriffen werden kann.

Controlling verantwortet die budgetäre Planung unter Berücksichtigung der Credit-Verrechnung, damit keine Doppelbelastung aus laufender Maintenance und vollem ACV entsteht.

Executive trägt die Entscheidung, ob der Zeitpunkt der Migration mit dem verfügbaren Credit-Volumen und der strategischen Budgetlage übereinstimmt, oder ob eine zeitliche Verschiebung die Verhandlungsposition verbessert.

Diese Rollen-Perspektiven zeigen: Die Credit-Verhandlung ist kein technisches Detail, sondern ein zentraler Steuerungsmoment, der Koordination zwischen Vertragsmanagement, Einkauf, Controlling und Unternehmensführung erfordert.

---

Dual-Use-Periode: Governance während der Migration {#dual-use-periode-governance-waehrend-der-migration}

In der Migrationsphase laufen On-Premise-System und Cloud-System parallel. Dieser Zeitraum, typischerweise sechs bis 18 Monate, hat eigene Vertragsmechaniken und erzeugt Governance-Anforderungen, die weder der On-Prem-Vertrag noch der RISE-Vertrag allein automatisch abdecken.

Was Dual-Use-Periode bedeutet

Dual-Use bezeichnet den vertraglich geregelten Zeitraum, in dem On-Prem- und Cloud-System gleichzeitig produktiv betrieben werden. SAP erlaubt diesen Parallelbetrieb für eine definierte Übergangszeit, weil Datenmigration, User-Schulung und cutover typischerweise nicht an einem Stichtag abgeschlossen werden können.

Die Länge der Dual-Use-Periode ist vertraglich festzulegen. In der Praxis beobachten wir sechs bis 18 Monate als typischen Rahmen, abhängig von Migrationsumfang, Systemkomplexität und Organisationsstruktur.

Was SAP vertraglich erlaubt und was nicht

Die Nutzungsrechte während der Dual-Use-Periode sind im RISE-Vertrag zu regeln. SAP erlaubt den Parallelbetrieb unter der Bedingung, dass die Nutzer nicht in beiden Systemen gleichzeitig produktiv arbeiten, sondern eines der Systeme als Migrationsumgebung dient.

Was SAP nicht erlaubt: doppelte produktive Nutzung desselben Users in beiden Systemen ohne entsprechende Lizenzierung. Wer das vertraglich nicht sauber abgrenzt, riskiert eine Nachforderung im nächsten Measurement.

Wie FUE-Lizenzierung während der Dual-Use-Periode funktioniert

Die FUE-Lizenzierung (Full Use Equivalent) ist der zentrale Steuerungsmoment im Bereich Nutzung während der Dual-Use-Phase. FUEs normalisieren verschiedene Nutzertypen auf eine einheitliche Vergleichsgröße:

• Developer Access: 1 User entspricht 2 FUE
• Advanced User: 1 User entspricht 1 FUE
• Core User: 5 User entsprechen 1 FUE
• Self-Service User: 30 User entsprechen 1 FUE

Wenn Nutzer während der Dual-Use-Phase auf beiden Systemen rollen-technisch angelegt sind, aber nur auf einem aktiv sind, entscheidet die vertragliche Definition des "aktiven Nutzers" über die Lizenzpflicht. Diese Definition sollte vor Beginn der Dual-Use-Phase schriftlich vereinbart sein.

Billing und Maintenance-Abgrenzung

Wann endet die On-Prem-Maintenance-Pflicht und wann beginnt die volle RISE-ACV-Pflicht? Diese Abgrenzung ist in der Dual-Use-Phase häufig nicht klar geregelt. In der Praxis zeigt sich, dass Unternehmen für einen Teil der Dual-Use-Phase sowohl Maintenance als auch ACV zahlen, weil die vertraglichen Abgrenzungspunkte nicht präzise definiert sind.

Der Steuerungsmoment im Bereich Kosten liegt in der genauen Festlegung des Cut-off-Datums im Order Form: Ab welchem Datum entfällt die On-Prem-Maintenance-Pflicht, und ab welchem Datum beginnt der volle ACV?

Typische Governance-Lücken im Parallelbetrieb

In der Dual-Use-Phase entstehen Governance-Lücken, die sich aus der Verteilung von Nutzern auf zwei Systeme ergeben:

Im Bereich Nutzung: Welche User sind auf welchem System aktiv, und wie werden FUE-Zuordnungen zwischen On-Prem und Cloud gehandhabt?

Im Bereich Berechtigungen: Welche Rollen werden im neuen System neu aufgesetzt, welche werden migriert? Das Rollendesign beeinflusst unmittelbar die FUE-Kosten im Cloud-System.

Im Bereich Infrastruktur: Welcher SLA gilt während der Dual-Use-Phase, und wer ist für Incidents auf welchem System verantwortlich?

Im Bereich Kosten: Welche Billing-Abgrenzungen gelten, und wer überwacht das Einhalten dieser Abgrenzungen?

Diese vier Steuerungsmomente in der Dual-Use-Phase sind die zentralen Governance-Objekte eines strukturierten Migrationsbegleitprogramms.

---

Add-on Product Versions in der Transition Option {#add-on-product-versions-in-der-transition-option}

Nicht alle Add-ons sind in der Transition Option verfügbar. Wer Add-ons im aktuellen ECC-System betreibt, muss vor der Transition-Option-Entscheidung prüfen, welche Add-ons mitgenommen werden können und welche ein S/4HANA-Äquivalent oder eine separate Ablösung benötigen.

Welche Add-on-Kategorien unterstützt werden

Die Transition Option unterstützt ausschließlich EhP 7 und EhP 8 für SAP ERP 6.0. Ältere EhPs müssen vor der Migration auf mindestens EhP 7 gehoben werden. Folgende Add-on-Kategorien sind in der Transition Option verfügbar:

Supply Chain und Logistics: APO 7.0 EhP4 auf ERP 6.0 EhP8 (ausschließlich als Connector, nicht als Stand-alone), EWM 9.5, DMC 6.0.

Finance und Treasury: SAP Revenue Accounting 1.3 (IFRS 15), SAP Treasury and Risk Management (US-Version), SAP CPM 2.0, Financial Task List Management Integration.

HCM und HR: HR Renewal 2.0, SAP Fiori for HCM 2.0, SuccessFactors Employee Central Integration (SFSF EC Integration), Manager Self-Service Add-on, Mobile Add-on for ERP.

Compliance und Invoicing: GINVOICING 2.0 für globale elektronische Rechnungsstellung, SAP Document Builder Management.

Integration und Plattform: SAP Cloud for Customer Integration, SAP CPQ ERP Integration, PLM System Integration, sowie Payment-Connector-Add-ons.

Industrie-spezifisch und Lokalisierung: Utilities-spezifische Add-ons für CEE-Region und weitere Lokalisierungen.

Was nicht in der Transition Option enthalten ist

Nicht alle Add-ons sind in der Transition-Option-Liste enthalten. Ältere EhP-Versionen sind grundsätzlich ausgeschlossen. Add-ons ohne S/4HANA-Äquivalent, die in der Transition-Option-Liste nicht aufgeführt sind, können nicht mitgenommen werden und müssen separat abgelöst werden.

Das S/4HANA Compatibility Pack für Add-ons gilt maximal bis zum 31. Dezember 2030 für Cloud-Subscriptions. Wer Add-ons auf der Basis des Compatibility Packs betreibt, muss diese bis Ende 2030 auf S/4HANA-native Lösungen migrieren.

Sizing-Implikation: Add-ons und ACV

Jedes aktivierte Add-on beeinflusst das Infrastructure Sizing und damit den ACV des RISE-Vertrags. Add-ons wie APO, EWM oder CRM-Integrationen erhöhen die Systemkomplexität und damit die Sizing-Anforderungen.

Der Steuerungsmoment im Bereich Infrastruktur liegt hier: Das Sizing muss vor Vertragsabschluss präzise auf den tatsächlichen Add-on-Bestand abgestimmt sein. Zu konservatives Sizing führt zu Kapazitätsengpässen, zu großzügiges Sizing zu Überkapazität, die den ACV unnötig erhöht.

Add-ons ohne S/4HANA-Äquivalent: Frühzeitige Identifikation

Eine der wichtigsten Governance-Aufgaben vor der Transition-Option-Entscheidung ist die Identifikation aller Add-ons ohne direktes S/4HANA-Äquivalent. Diese Add-ons können in der Transition Option zwar noch betrieben werden, wenn sie in der verfügbaren Liste stehen, müssen aber bis spätestens Ende 2033 auf alternative Lösungen migriert werden. Wer diese Identifikation erst während der Transition Option durchführt, verliert wertvolle Planungszeit.

---

Shelfware verwerten statt verfallen lassen {#shelfware-verwerten-statt-verfallen-lassen}

In On-Premise-Umgebungen entstehen über Jahre Lizenzen, die bezahlt, aber nicht oder nicht mehr vollständig genutzt werden. Diese Shelfware ist bei einer Migration in die Cloud ein strategisches Asset mit einem Zeitfenster für die Verwertung.

Was Shelfware ist und wie sie entsteht

Shelfware sind Lizenzen, für die Maintenance gezahlt wird, obwohl die Nutzungsrechte nicht oder nicht mehr ausgeübt werden. Sie entstehen durch mehrere typische Mechanismen: Unternehmenskonsolidierungen, bei denen Lizenzen aus Übernahmen in das Portfolio wandern, die aber nicht produktiv eingesetzt werden. Funktionale Reorganisationen, bei denen Module abgelöst werden, die Lizenz aber weiterläuft. User-Reduktionen, bei denen die Nutzerzahl sinkt, die lizenzierte Kapazität aber nicht angepasst wird.

In gewachsenen SAP-Landschaften, die über zehn oder mehr Jahre aufgebaut wurden, ist Shelfware kein Ausnahmefall. Sie ist ein strukturelles Ergebnis der Komplexität von ERP-Vertragsportfolios.

Shelfware als Verhandlungsargument

Shelfware kann beim Wechsel zu RISE als Verhandlungsargument eingesetzt werden. Der Mechanismus: Ungenutzte Lizenzen, für die Maintenance bezahlt wird, können als zusätzliches Argument in der Credit-Verhandlung eingebracht werden. SAP hat ein Interesse daran, dass Kunden in die Cloud wechseln. Wer Shelfware nachweisen kann, zeigt gleichzeitig, dass ein Teil der bisherigen Maintenance-Zahlungen keinen operativen Gegenwert hatte.

Die Voraussetzung für dieses Argument ist eine vollständige Bestandsaufnahme: Welche Lizenzen sind im Bestand, welche werden tatsächlich genutzt, und welche werden nur mitgepflegt?

Maintenance-Base-Reduktion durch Lizenzaufgabe

Shelfware kann nicht nur als Verhandlungsargument eingesetzt, sondern auch direkt zur Reduktion der Maintenance Base genutzt werden. Nicht benötigte Nutzungsrechte können vor dem Start von Extended Maintenance aufgegeben werden. Das reduziert die Basis, auf die der Extended-Maintenance-Aufschlag berechnet wird.

Das abstrakte Rechenbeispiel aus Sektion 3 (Reduktion von einer Million Euro auf 30.000 Euro Maintenance Base) zeigt: Der Steuerungsmoment im Bereich Kosten vor dem 1. Januar 2028 liegt nicht nur in der Wahl des Szenarios, sondern auch in der Bereinigung der Basis, auf die das Szenario angewendet wird.

Zeitfenster: Wann Shelfware-Verwertung noch möglich ist

Das Zeitfenster für Shelfware-Verwertung schließt sich mit dem Beginn von Extended Maintenance oder dem Abschluss eines RISE-Vertrags. Wer Shelfware erst nach Vertragsabschluss identifiziert, kann sie in der Regel nicht mehr rückwirkend als Verhandlungsargument einbringen.

Das bedeutet konkret: Die Bestandsaufnahme und Shelfware-Analyse sollte in die Vorbereitungsphase der Vertragsverhandlung fallen, nicht in die Phase nach Vertragsabschluss.

Was systematische Bestandsaufnahme voraussetzt

Eine belastbare Shelfware-Analyse setzt zwei Datenquellen voraus: den SAP Readiness Check, der technische Nutzungsdaten aus dem produktiven System liefert, und ein eigenes Lizenzkataster, das die vertraglich lizenzierten Rechte dokumentiert.

Wer beide Datenquellen zusammenführt, kann systematisch identifizieren, welche Nutzungsrechte lizenziert, aber nicht genutzt werden. Diese Lücke ist der verwertbare Befund.

---

Vier Steuerungsmomente in der Migrationsphase {#vier-steuerungsmomente-in-der-migrationsphase}

Migration verändert nicht die Grundstruktur der Vertragssteuerung. Sie verschiebt die Gewichte zwischen den vier Bereichen, in denen Steuerungsmomente entstehen: Nutzung, Berechtigungen, Infrastruktur und Kosten. In der Migrationsphase sind alle vier Bereiche gleichzeitig aktiv, weil sowohl das bestehende System als auch das neue System Governance-Anforderungen erzeugen.

Nutzung: FUE-Verschiebung beobachten

Der Steuerungsmoment im Bereich Nutzung liegt in der kontinuierlichen Beobachtung der FUE-Verschiebung zwischen On-Prem-Usern und Cloud-Usern. Während der Migration wandern User sukzessive vom On-Prem-System in das Cloud-System. Jede Verschiebung verändert die FUE-Verteilung und damit die Lizenzgrundlage.

In der Praxis zeigt sich, dass FUE-Zuordnungen während der Migration nicht automatisch angepasst werden. Wer die FUE-Verteilung nicht aktiv beobachtet, merkt Abweichungen erst beim nächsten Measurement. Das kann zu Nachforderungen führen oder zu ungenutzten FUE-Kontingenten im On-Prem-Vertrag, die weiter Kosten verursachen.

Berechtigungen: Rollendesign als Lizenzkosten-Faktor

Der Steuerungsmoment im Bereich Berechtigungen liegt im Rollendesign beim Übergang von ECC auf S/4HANA. Rollen, die in ECC breit ausgelegt waren, können in S/4HANA zu einem höheren FUE-Typ führen, wenn die Rollenbreite eine Advanced-User-Lizenz statt einer Core-User-Lizenz erfordert.

Konkretes Beispiel: Ein User, der in ECC eine Reporting-Rolle mit Lesezugriff auf mehrere Module hatte, kann in S/4HANA als Advanced User eingestuft werden, wenn das Rollendesign die Grenzwerte für Core User überschreitet. Das Rollendesign ist damit nicht nur ein IT-Architekturfrage, sondern ein Kostenfaktor.

Der Steuerungsmoment liegt in der Prüfung des Rollendesigns vor dem Go-Live: Welche Lizenzklasse ergibt sich für jeden User-Typ, und entspricht das den Sizing-Annahmen im RISE-Vertrag?

Infrastruktur: SLA-Abgleich und Hyperscaler-Wahl

Der Steuerungsmoment im Bereich Infrastruktur liegt in zwei Aspekten: erstens im SLA-Abgleich zwischen bisherigem On-Prem-SLA und dem RISE-SLA, zweitens in der Verankerung der Hyperscaler-Wahl im Vertrag.

On-Prem-Systeme haben typischerweise individuell vereinbarte SLAs mit dem internen IT-Betrieb. RISE-SLAs sind standardisiert, aber je nach Hyperscaler und Tier unterschiedlich. Ein Abgleich, ob die RISE-SLA-Parameter die bisherigen operativen Anforderungen abdecken, ist vor Vertragsabschluss zu führen.

Die Hyperscaler-Wahl, also ob Azure, AWS oder Google Cloud, beeinflusst nicht nur den technischen Betrieb, sondern auch die verfügbaren komplementären Services und Kosten. Azure ist der größte RISE-Partner, Google Cloud bietet die stärkste Data- und AI-Integration, AWS hat die reifste SAP-Workload-Erfahrung. Diese Wahl sollte im Vertrag verankert sein, um spätere Änderungen ohne Vertragsanpassung zu vermeiden.

Kosten: ACV-Tracking und Credit-Verrechnung

Der Steuerungsmoment im Bereich Kosten in der Migrationsphase umfasst drei Aspekte:

Erstens das ACV-Tracking während der Ramp-up-Phase. RISE-Verträge enthalten häufig ein gestaffeltes Ramp-up-Profil, bei dem der ACV in den ersten Jahren geringer ist und dann auf das volle Niveau anwächst. Wer das Ramp-up-Profil nicht aktiv überwacht, bemerkt Abweichungen vom geplanten Migrationspfad erst, wenn das Profil nicht mehr passt.

Zweitens die Verrechnung von Maintenance-Credits gegen den ACV. Credits, die in der Verhandlung vereinbart wurden, müssen aktiv verfolgt werden, bis sie im Order Form korrekt verbucht sind.

Drittens die Extended-Maintenance-Position: Wer Extended Maintenance für eine Übergangszeit zahlt, weil die Migration noch nicht abgeschlossen ist, muss diese Position als bekannte Budgetgröße führen, nicht als Überraschung auf der nächsten Rechnung.

---

Vertragssteuerung nach der Unterschrift: Was jetzt beginnt {#vertragssteuerung-nach-der-unterschrift}

Die Migration ist ein Projekt mit Anfang und Ende. Die Vertragssteuerung ist eine Dauerdisziplin, die nicht mit dem Migrationsprojekt beginnt und endet, sondern mit dem RISE-Vertragsabschluss einsetzt und über die gesamte Vertragslaufzeit läuft.

Was nach der Migration zur laufenden Steuerungsaufgabe wird

Nach dem Go-Live auf RISE entstehen neue laufende Steuerungsaufgaben, die während des Migrationsprojekts häufig noch nicht im Fokus stehen:

Im Bereich Nutzung: BTP-Credit-Verbrauch, FUE-Entwicklung bei wachsenden Nutzerpopulationen, Overage-Monitoring bei AI-Unit-Kontingenten.

Im Bereich Berechtigungen: Rollenpflege unter dem FUE-Modell, Lizenzklassen-Überprüfung bei Rollen-Änderungen, PCE-Metering-Auswertung.

Im Bereich Infrastruktur: SLA-Monitoring nach RISE-Standard, System-Sizing-Überprüfung bei wachsenden Workloads, Hyperscaler-Betriebsdaten.

Im Bereich Kosten: ACV-Tracking, Derived-Charges-Abgleich, Renewal-Vorbereitung.

Wie FinOptory die Post-Migration-Phase strukturiert

FinOptory strukturiert die laufende Steuerung nach drei Dimensionen:

Assets beschreibt, was im Vertrag steht: Entitlements, ACV, Klauseln, Fristen, Renewal-Termine.

Change beschreibt, was sich verändert: Nutzungsänderungen, SAP-Updates, Rollen-Anpassungen, neue Add-ons, neue Module.

Control beschreibt die laufende Steuerung: 14-Tage-Reviews, Abgleich von Ist und Soll, proaktive Kommunikation vor Steuerungsmomenten.

Wer steuert SAP-Verträge nach der Unterschrift

Die Herausforderung liegt im System, nicht in der Organisation. SAP-Verträge nach der Unterschrift zu steuern, erfordert eine Systematik, die weder das Migrationsprojektteam noch der laufende IT-Betrieb allein aufbaut. Migrationsprojekte enden mit dem Go-Live. Der IT-Betrieb fokussiert auf Systemverfügbarkeit. Die Vertragssteuerung ist eine eigenständige Disziplin, die spezialisiertes Wissen über Vertragsmechaniken, SAP-Produkttypen und Verhandlungslogik verbindet.

Warum Migration und laufende Steuerung dieselbe Datenbasis brauchen

Ein Punkt, der in der Praxis häufig spät sichtbar wird: Migrationsprojekte bauen wertvolles Wissen über die bestehende Vertragsstruktur auf. Sizing-Annahmen, Add-on-Analysen, Credit-Verhandlungen, SLA-Vergleiche. Dieses Wissen sollte nicht mit dem Projektabschluss in Dokumenten verschwinden, sondern in eine laufende Steuerungsstruktur überführt werden. Wer die Datenbasis des Migrationsprojekts für die laufende Vertragssteuerung nutzt, hat einen strukturellen Vorteil gegenüber demjenigen, der nach dem Go-Live von vorne beginnt.

Was der Renewal-Steuerungsmoment mit der Migration zu tun hat

Die erste Renewal-Verhandlung nach dem RISE-Go-Live findet typischerweise drei bis fünf Jahre nach Vertragsabschluss statt. Wer zu diesem Zeitpunkt keine belastbaren Nutzungsdaten, keine dokumentierten Vertragsabweichungen und keine strukturierte Verhandlungsvorbereitung hat, verhandelt ohne Grundlage.

Der Steuerungsmoment vor dem Renewal beginnt nicht kurz vor dem Renewal-Datum, sondern mit dem Tag des Go-Lives. Jedes 14-Tage-Review, jede dokumentierte Abweichung zwischen vertraglich vereinbartem und tatsächlichem Leistungsumfang, jede Nutzungsänderung ist Material für die spätere Verhandlung.

Das ist die strukturelle Begründung dafür, warum die Unterschrift des RISE-Vertrags nicht das Ende der Governance-Aufgabe ist, sondern der Beginn. SAP-Verträge steuern nach der Unterschrift ist kein Aufwand, der nach dem Go-Live endet. Es ist eine Dauerdisziplin, die über die gesamte Vertragslaufzeit läuft.

Vier Rollen, ein Steuerungsmodell

Die laufende Vertragssteuerung nach der Migration berührt vier Rollen, die je unterschiedliche Perspektiven auf die Steuerungsmomente haben:

Der Contract Manager verantwortet die laufende Compliance, die Vertragsstruktur und die Prüfung, ob Leistungsumfang und Abrechnung übereinstimmen. In der Post-Migration-Phase ist die Hauptaufgabe, den neuen RISE-Vertrag in den regulären Review-Zyklus zu integrieren.

Procurement ist verantwortlich für Einkaufsentscheidungen, Konditionen und die Vorbereitung von Renewal-Optionen. Die relevanten Steuerungsmomente im Bereich Kosten liegen hier in der ACV-Entwicklung und in der frühzeitigen Identifikation von Erweiterungsbedarfen, die in die nächste Verhandlung einfließen.

Controlling trägt die Kostenallokation, Rechnungsprüfung und Budgetklarheit. In der Post-Migration-Phase entstehen neue Herausforderungen bei der internen Verrechnung von RISE-Kosten, weil das Subscription-Modell eine andere Zuordnungslogik erfordert als das bisherige Lizenzmodell.

Executive trägt Prioritätsentscheidungen, Freigaben und die strategische Renewal-Entscheidung. Die Steuerungsmomente auf dieser Ebene sind selten, aber bedeutsam: Wer den Renewal-Zeitpunkt erst dann prüft, wenn die Frist naht, hat die strategische Verhandlungsposition bereits weitgehend eingebüßt.

---

FAQ {#faq}

1. Was passiert am 31. Dezember 2027 mit meinem SAP-ERP-System?

Das System läuft weiter. Was endet, ist Mainstream Maintenance: Legal Changes, Support Packages und Fehlerkorrektur im Standard werden nicht mehr automatisch bereitgestellt. Ab dem 1. Januar 2028 ist für den Weiterbetrieb entweder ein Extended-Maintenance-Addendum erforderlich oder der Betrieb unter PCE/RISE, der Extended Maintenance im Subscription-Preis enthält.

2. Was kostet Extended Maintenance und wie wird die Basis berechnet?

Extended Maintenance kostet zwei Prozentpunkte zusätzlich auf die Maintenance Base. Die Maintenance Base umfasst alle BS7 Core Applications, Add-ons und Runtime-Datenbanken. Durch gezieltes Aufgeben nicht benötigter Nutzungsrechte kann die Basis vor dem Start von Extended Maintenance reduziert werden, was den Aufschlag in absoluten Zahlen deutlich verringert.

3. Gilt Extended Maintenance für alle Systeme oder kann ich einzelne ausklammern?

Extended Maintenance gilt für die gesamte On-Premise-BS7-Landschaft. Cherry-Picking nach Systemen ist nicht möglich. Wer Extended Maintenance beantragt, beantragt sie für alle BS7-Systeme.

4. Was ist die Transition Option und wann läuft sie aus?

Die Transition Option ist ein befristetes Cloud-Betriebsmodell für SAP ERP EhP 7 und EhP 8 in der SAP ERP Private Edition. Der Service-Start ist der 1. Januar 2031, das Ende ist der 31. Dezember 2033. Das Subskriptionsfenster liegt zwischen 2028 und 2030.

5. Was kostet die Transition Option im Vergleich zu einem regulären RISE-Vertrag?

Die Transition Option kostet 20 Prozent Aufschlag gegenüber dem vergleichbaren Preis einer regulären SAP ERP Private Edition. Zusätzlich ist der Max Success Plan Transition Services verpflichtend. Kunden, die sich vor Ende 2025 subskribiert haben, zahlen keinen Aufschlag.

6. Kann ich On-Premise-Lizenzen als Credit auf einen RISE-Vertrag anrechnen?

Ja, über das Cloud Extension Program. Drei Credit-Typen stehen zur Verfügung: Maintenance Credits, Service Credits und Cloud Credits. Die Höhe ist verhandlungsabhängig und nicht öffentlich tabelliert. Frühzeitige Verhandlungen stärken typischerweise die Verhandlungsposition.

7. Wie lange ist Dual-Use-Betrieb vertraglich erlaubt?

SAP erlaubt Dual-Use-Betrieb für eine vertraglich definierte Übergangsdauer. Die übliche Praxis liegt bei sechs bis 18 Monaten. Die genaue Dauer und die Nutzungsregelungen während des Parallelbetriebs müssen im RISE-Vertrag festgelegt werden.

8. Was passiert mit Add-ons, die keine S/4HANA-Entsprechung haben?

Add-ons ohne S/4HANA-Äquivalent können in der Transition Option noch betrieben werden, wenn sie in der verfügbaren Add-on-Liste stehen. Sie müssen aber bis spätestens Ende 2033 auf alternative Lösungen migriert werden. Das S/4HANA Compatibility Pack gilt nur bis Ende 2030 für Cloud-Subscriptions.

9. Was ist Shelfware und wie setze ich sie als Verhandlungsargument ein?

Shelfware sind Lizenzen, für die Maintenance gezahlt wird, ohne dass die Nutzungsrechte ausgeübt werden. Beim Wechsel zu RISE kann Shelfware als zusätzliches Argument in der Credit-Verhandlung eingesetzt werden. Die Voraussetzung ist eine vollständige Bestandsaufnahme über SAP Readiness Check und Lizenzkataster.

10. Welche Add-ons sind in der Transition Option verfügbar und welche nicht?

Die verfügbaren Add-ons umfassen Kategorien aus Supply Chain (APO als Connector, EWM), Finance (Revenue Accounting, Treasury), HCM (HR Renewal, SuccessFactors EC Integration), Compliance (GINVOICING) und Integration. Die vollständige Liste ist im SAP Help Portal und in der SAP Customer Evolution Dokumentation zugänglich. Nur EhP 7 und EhP 8 werden unterstützt.

11. Was bedeutet der 1. Januar 2028 als Stichtag für RISE-Kunden?

Für Kunden, deren gesamte Systemlandschaft bis zum 1. Januar 2028 in der SAP ERP Private Cloud Edition betrieben wird, ist Extended Maintenance im Subscription-Preis enthalten, ohne zusätzlichen Aufschlag. Das ist die strukturelle Vereinfachung, die RISE gegenüber On-Prem-Extended-Maintenance bietet.

12. Wie steuere ich SAP-Verträge nach dem Go-Live auf RISE?

Die laufende Vertragssteuerung nach dem Go-Live umfasst die vier Steuerungsbereiche: Nutzung (FUE-Entwicklung, BTP-Credits), Berechtigungen (Rollendesign, Lizenzklassen), Infrastruktur (SLA-Monitoring, Sizing) und Kosten (ACV-Tracking, Derived Charges, Renewal-Vorbereitung). Eine strukturierte 14-Tage-Review-Systematik stellt sicher, dass Steuerungsmomente erkannt werden, bevor sie zu Budgetabweichungen führen.

13. Wie verhält sich Extended Maintenance zur On-Prem-Wahl des Hyperscalers?

Extended Maintenance ist ausschließlich für On-Premise-Betrieb relevant. Wer On-Prem mit Extended Maintenance bleibt, trifft keine Hyperscaler-Entscheidung. Erst beim Wechsel zu RISE oder der Transition Option kommt die Wahl zwischen Azure, AWS und Google Cloud ins Spiel. Diese Entscheidung ist im Vertrag zu verankern und beeinflusst sowohl komplementäre Services als auch die langfristige Kostenstruktur.

14. Was passiert, wenn ich bis Ende 2030 noch nicht vollständig auf S/4HANA migriert bin?

Nach Ende 2030 gibt es für On-Premise-BS7-Systeme ohne Transition Option keine strukturierte SAP-Maintenance mehr. Wer bis dahin weder Extended Maintenance abgeschlossen noch die Transition Option subskribiert hat und noch nicht auf S/4HANA migriert ist, befindet sich in einem Betriebszustand ohne vertragliche Grundlage für regulären SAP-Support. Drittpartei-Wartung ist eine mögliche Option, setzt aber eigene Vertragsstrukturen voraus und deckt typischerweise nicht den vollen Scope von SAP-Support ab.

15. Welche SAP-Tools helfen bei der Vorbereitung der Migrationsentscheidung?

SAP stellt mehrere Tools bereit, die in der Entscheidungsvorbereitungsphase relevant sind: Der SAP Readiness Check liefert technische Systemdaten für Sizing und Custom-Code-Analyse. SAP Signavio Process Navigator unterstützt beim Fit-to-Standard-Abgleich. SAP Cloud ALM ist nach dem Go-Live das ALM-Werkzeug für den RISE-Betrieb. Diese Tools sind im RISE-Vertrag enthalten, werden aber in der Praxis häufig erst nach Go-Live aktiviert statt bereits in der Vorbereitungsphase genutzt.

---

Nächste Schritte {#naechste-schritte}

Das Maintenance-Ende 2027 ist ein konkreter Steuerungsmoment mit einem festen Entscheidungskalender. Wer die Optionen jetzt bewertet, behält Handlungsspielraum für Verhandlung, Planung und Entscheidung.

Vertragscheck buchen: Eine strukturierte Analyse der Maintenance Base, des Credit-Potenzials und der Transition-Option-Eignung in vier Wochen. Festpreis 7.900 EUR. Erstgespräch vereinbaren

FinOptory AI nutzen: Für eine erste Einschätzung der eigenen Maintenance-Timeline und der Optionen steht FinOptory AI auf der Website zur Verfügung. Zur FinOptory AI

Weitere Ressourcen: Für eine vollständige Übersicht über alle neun SAP-Produkttypen und deren Governance-Anforderungen empfehlen wir den Pillar zur SAP Contract Governance. Für Fragen zur Renewal-Vorbereitung verweisen wir auf den Pillar zur Renewal-Steuerung.

---

Bernhard Mändle, Managing Consulting, FinOptory Quellen: SAP Customer Evolution, DSAG AK Lizenzen, SAP Help Portal (help.sap.com), SAP Note 2269324 (Compatibility Scope Matrix), SAP Note 2741041 (NetWeaver BW Maintenance), Redress Compliance, SAP Licensing Experts