Gezählt wird, was möglich ist

Lizenzmanagement für SAP und Oracle: warum beide Hersteller Möglichkeit statt Nutzung zählen, wo die maßgeblichen Regeln tatsächlich stehen und was Sie vor einer Cloud-Migration geklärt haben müssen

Management Summary

Strategischer Kontext

Situation. Für SAP- und Oracle-Kunden laufen gerade mehrere Fristen gleichzeitig ab. SAP beendet die Mainstream-Wartung der Business Suite 7 Ende 2027 und bietet danach eine verlängerte Wartung bis Ende 2030 gegen einen Aufschlag an. Oracles Regeln für die Lizenzierung in der Public Cloud tragen den Stand 4. September 2026. Beide Hersteller drängen ihre Bestandskunden in Richtung Abonnement.

Komplikation. Wer migriert, nimmt sein Lizenzinventar mit, und die meisten Organisationen kennen es nicht. Der Lizenzberater Richard Spithoven (SoftwareOne) bringt es in einem Techzine-Interview auf einen Satz: „People don’t know what they don’t know.“ Hinzu kommt ein Befund, der in der Lizenzdiskussion selten ausgesprochen wird: Die Metriken beider Hersteller zählen an vielen Stellen nicht, was Sie nutzen, sondern was Sie nutzen könnten. Und die Regeln, nach denen gezählt wird, stehen oft nicht im Vertrag.

Frage. Wo entsteht bei SAP und Oracle das Lizenzrisiko tatsächlich, und was muss ein Unternehmen wissen, bevor es verlängert, migriert oder in ein Audit geht?

Zentrale Befunde

1. Beide Hersteller zählen an entscheidenden Stellen die Möglichkeit, nicht die Nutzung. Oracle lizenziert Java SE nach Mitarbeitern, und zwar ausdrücklich „not just the actual number of employees that use the Programs“. Ein Fusion-Nutzer zählt „regardless of whether the individual is actively accessing the hosted service“. Eine Oracle-Datenbank auf VMware wird nach der physischen Kapazität bemessen, weil Oracle VMware als Soft Partitioning einstuft. SAP vermisst jedes System und klassifiziert jeden dort angelegten Benutzer. Was folgt daraus? Ein Nutzungsbericht allein beantwortet die Lizenzfrage nicht. Sie brauchen zusätzlich ein Bild davon, wo die Software installiert ist, wer theoretisch darauf zugreifen kann und auf welcher Hardware sie laufen könnte.

2. Die Regel, nach der gezählt wird, steht oft neben dem Vertrag. Oracles Partitioning Policy, sein Dokument zur Datenbanklizenzierung und seine Cloud-Lizenzregeln tragen alle denselben Satz: „for educational purposes only“, „may not be incorporated into any contract“, „subject to change without notice“. Trotzdem entscheiden genau diese Dokumente in der Praxis, wie viele Lizenzen Oracle verlangt. Was folgt daraus? Frieren Sie die Fassung ein, die bei Vertragsabschluss gilt, und verhandeln Sie die Punkte, die für Ihre Architektur entscheidend sind (Virtualisierung, Cloud, Container), in den Vertrag hinein. Eine Policy, die Oracle jederzeit ändern kann, ist keine Planungsgrundlage.

3. Der Wartungsvertrag ist der größere Hebel als der Lizenzkauf. In Oracles aktueller Technology-Preisliste liegt die jährliche Supportgebühr für die Datenbank bei 22 Prozent des Lizenzpreises, und die Verlängerung steigt jedes Jahr um eine Inflationsanpassung, deren Höhe Oracle nicht veröffentlicht. Einzelne Lizenzen aus einem Lizenz-Set zu kündigen ist nicht vorgesehen, und eine Teilkündigung führt zu einer Neubepreisung des Rests. Bei SAP kostet die verlängerte Wartung bis 2030 zwei Prozentpunkte zusätzlich auf die Wartungsbasis. Was folgt daraus? Shelfware kostet vor allem jedes Jahr Wartung. Wer sie loswerden will, muss die Lizenz-Sets und Bestellungen kennen, in denen sie steckt, und die Kündigungsregeln vorher durchrechnen.

4. Die Cloud ändert die Zählweise, nicht das Risiko. In AWS, Azure und Google Cloud gilt Oracles Core-Factor-Tabelle nicht. Zwei vCPUs mit Multithreading ergeben eine Processor-Lizenz. Nach eigener Rechnung auf Basis beider Oracle-Dokumente verdoppelt das den Lizenzbedarf gegenüber derselben Kernzahl auf x86 im eigenen Rechenzentrum. Bei SAP setzt die Umwandlung von On-Premise-Lizenzen in Cloud-Abonnements laut SAP-Material ein Lizenzaudit voraus, das höchstens sechs Monate alt ist. Was folgt daraus? Die Migration ist kein Ausweg aus der Vermessung, sondern ihr Anlass. Rechnen Sie den Lizenzbedarf in der Zielarchitektur, bevor Sie die Instanzgrößen festlegen.

5. Schnittstellen sind Lizenzobjekte. Im Verfahren SAP gegen Diageo forderte SAP rund 54,5 Millionen Pfund an Lizenz- und Wartungsgebühren, weil Diageos Kunden über ein Bestellportal und Diageos Außendienst über eine eigene Vertriebsanwendung indirekt, über SAP PI, auf SAP ERP zugriffen. Das Gericht gab SAP dem Grunde nach recht. SAPs Antwort war 2018 das Modell Digital Access, das neun Typen erzeugter Dokumente zählt. Was folgt daraus? Jede Integration, die in SAP Belege anlegt, gehört ins Lizenzinventar. Wer seine Schnittstellen nicht kennt, kann weder Digital Access bewerten noch ein Audit einschätzen.

Kritische Empfehlungen

Fazit

Lizenzmanagement für SAP und Oracle ist keine Zählübung, sondern eine Übersetzungsarbeit: Sie übersetzen Ihre Architektur in die Metriken des Herstellers, bevor der Hersteller es tut. Wer nur misst, was genutzt wird, misst an den Metriken vorbei. Wer die Regeln nicht einfriert, verhandelt gegen ein bewegliches Ziel. Und wer migriert, ohne sein Inventar zu kennen, nimmt die Unklarheit mit in einen Vertrag, in dem der Hersteller die Nutzung laufend sieht.

Wo die Diskussion gerade steht

Techzine hat im Februar 2026 mit Richard Spithoven von SoftwareOne gesprochen, und das Interview fasst die Lage gut zusammen. Sein Beispiel für Shelfware: „A company that purchased 100 ERP software modules 10 years ago may now only use 40 of them.“ Bezahlt wird die Wartung trotzdem für alle hundert. Zu den Folgen sagt er, Nachforderungen erreichten teils dreistellige Millionenbeträge, der größte Fall, den er gesehen habe, habe bei 1,2 Milliarden Euro gelegen. Worauf sich diese Summe genau bezieht, lässt der Artikel offen. Öffentlich werde das selten, weil Unternehmen es als „admission of failure“ empfänden.

Der Artikel beschreibt außerdem, was sich mit der Cloud ändert. Bei Oracle Fusion erhalte der Kunde jährliche Berichte seines Customer Success Managers über den Zugriff auf Module, und aus einer erwarteten Verlängerung über 2,3 Millionen Euro würden dann 4,2 Millionen. Für RISE with SAP heißt es: „There, too, a CSM regularly generates reports to see who has access to which functionality.“ Und für Migrationsprojekte insgesamt: „In almost all projects where customers move away from on-premise ERP, I see that the costs ultimately go through the roof.“

Zwei Aussagen aus dem Artikel übernimmt dieser Beitrag nicht als Fakt. Die erste lautet, Oracle habe die Supportkosten „from 4 to 8 percent“ erhöht, im Juni 2026 werde ein Anstieg auf 10 Prozent erwartet. Techzine nennt dafür keine Quelle, und Oracles eigene Dokumente nennen den Mechanismus der jährlichen Anpassung, aber keinen Prozentsatz (siehe Befund 3). Die zweite lautet, SAP auditiere jährlich. SAP selbst spricht vom vertraglichen Recht, die Nutzung „at regular intervals“ zu prüfen. Beides kann in der Praxis zutreffen. Belegt ist es in den gelesenen Dokumenten nicht.

Eine Beobachtung zu den Quellen gehört an diese Stelle. Das Problem ist alt. Schon 2014 nannte ein Flexera-Manager im Gespräch mit itassetmanagement.net die indirekte Nutzung „the elephant in the room“ der SAP-Lizenzierung, und dieselbe Quelle beschrieb bereits, dass Oracle VMware als Soft Partitioning behandelt. Zwölf Jahre später sind beide Themen nicht erledigt, sondern in neue Modelle übersetzt.

Befund 1: Gezählt wird die Möglichkeit, nicht die Nutzung

Die intuitive Frage im Lizenzmanagement lautet: Wie viel nutzen wir? Die Metriken beider Hersteller stellen an vielen Stellen eine andere Frage: Wie viel könnten Sie nutzen? Die folgende Übersicht stellt die Stellen zusammen, an denen das im Wortlaut der Hersteller steht.

Der Java-Fall ist der deutlichste. Oracle hat die alten Java-SE-Abonnements am 23. Januar 2023 durch die Universal Subscription ersetzt. Seitdem hängt der Preis nicht mehr an Installationen oder Anwendern, sondern an der Belegschaft. Die Definition umfasst „all of Your full-time, part-time, temporary employees“ und zusätzlich die entsprechenden Beschäftigten von „agents, contractors, outsourcers, and consultants that support Your internal business operations“. Oracles eigenes Rechenbeispiel in der Preisliste: 28.000 Mitarbeiter, davon 5.000 bei Dienstleistern, ergeben 2.268.000 US-Dollar im Jahr. Die Staffel beginnt bei 15 US-Dollar pro Mitarbeiter und Monat. Ein Unternehmen, das Java auf zwanzig Servern betreibt, rechnet damit nicht mehr in Servern, sondern in Köpfen.

Beim Kubernetes-Fall ist die Logik dieselbe, nur technischer. Nicht der laufende Container zählt, sondern der Knoten, auf den das Image gezogen wurde. Ein Cluster mit automatischer Skalierung kann so Lizenzbedarf auf Knoten erzeugen, auf denen die Datenbank nie produktiv lief.

SAP ist an dieser Stelle nicht grundsätzlich anders gebaut. Die Vermessung erfolgt pro System, und die Klassifizierung der Benutzer ist Aufgabe des Kunden vor jeder Vermessung. Die License Administration Workbench führt anschließend die Benutzer einer Person über Systeme zusammen und ordnet ihr „one contractual user type“ zu. Wer Benutzer nicht sauber klassifiziert, lässt die Zuordnung faktisch vom Messergebnis bestimmen.

Es gibt eine wichtige Ausnahme, und sie zeigt, dass es auch anders geht. SAPs Digital Access zählt nur Dokumente, die tatsächlich erzeugt wurden. Lesen, Ändern und Löschen zählen ausdrücklich nicht. Und in RISE with SAP lassen sich Full Usage Equivalents zwischen Nutzungstypen umverteilen, laut SAP-Material ausdrücklich „to avoid shelf-ware during their life-cycle“. Das sind nutzungsnähere Modelle. Sie gelten aber nur dort, wo Sie sie vertraglich haben. Bei den Joule Agents geht SAP diesen Weg gerade weiter und rechnet pro Aktion ab, mit eigenen Tücken für den Business Case (siehe SAP bepreist künftig die Aktion, nicht den User).

Die Entscheidung, die daraus folgt. Bauen Sie Ihr Lizenzinventar in drei Schichten auf: installiert (wo liegt die Software), berechtigt (wer könnte zugreifen) und genutzt (wer greift zu). Erst wenn alle drei vorliegen, können Sie sagen, welche Metrik Sie tatsächlich trifft.

Befund 2: Die Regel steht neben dem Vertrag

Oracles Lizenzvertrag definiert den Processor. Wie diese Definition auf Virtualisierung, Cloud und Container angewendet wird, regeln drei Dokumente, die Oracle auf seiner Website veröffentlicht. Alle drei enthalten sinngemäß denselben Vorbehalt. Die Partitioning Policy formuliert ihn so:

„This document is for educational purposes only and provides guidelines regarding Oracle’s policies in effect as of February 14, 2022. It may not be incorporated into any contract and does not constitute a contract or a commitment to any specific terms. Policies and this document are subject to change without notice.“

Das Dokument zur Cloud-Lizenzierung trägt denselben Vorbehalt, mit dem Stand „policies in effect as of September 4, 2026″. Die Core-Factor-Tabelle ist mit „Updated: Jan 28, 2026″ versehen. Die Partitioning Policy selbst beschreibt sich als Regelung, „to license a sub-capacity of total physical cores as an exception from the contractual Oracle Processor definition“. Die Policy ist also eine Ausnahme, die Oracle gewährt, und keine Zusage, auf die Sie sich berufen können.

Daraus ergibt sich eine Asymmetrie. Die Dokumente, nach denen Oracle im Audit rechnet, sind für den Kunden nicht einklagbar, und sie ändern sich. Die Cloud-Regeln tragen ein Datum vom September dieses Jahres. Was sich gegenüber der Vorversion geändert hat, weist das Dokument nicht aus.

Bei SAP liegt die entsprechende Stelle in der Preis- und Konditionenliste, auf die die Vermessung ausdrücklich verweist: Benutzer sind „in accordance with the current use and the underlying price list“ zu klassifizieren. Auch hier entscheidet ein Dokument außerhalb des eigentlichen Lizenzvertrags darüber, welcher Nutzertyp welche Tätigkeit abdeckt.

Die Entscheidung, die daraus folgt. Legen Sie zu jedem Vertragsabschluss die dann gültigen Fassungen dieser Dokumente ab, mit Datum. Und verhandeln Sie die Punkte, die Ihre Architektur betreffen, in die Bestellung: welche Virtualisierung als Hard Partitioning akzeptiert wird, welche Cloud-Umrechnung gilt, wie Container gezählt werden. Was in der Bestellung steht, gilt. Was in der Policy steht, gilt, solange Oracle sie nicht ändert.

Befund 3: Die Wartung ist der größere Hebel

Die Oracle Technology Global Price List mit Stand 15. September 2026 weist für die Datenbank Enterprise Edition 47.500 US-Dollar pro Processor-Lizenz aus und daneben 10.450 US-Dollar für „Software Update License & Support“. Für Standard Edition 2 sind es 17.500 und 3.850 US-Dollar. In allen vier Spalten entspricht der Support genau 22 Prozent des Lizenzpreises. Die Preisliste nennt diesen Prozentsatz nicht wörtlich, er ergibt sich aus den Zahlen.

Wichtiger als der Einstiegswert ist, wie er sich fortschreibt. Die Preisliste regelt: „The price of a technical support renewal for Software Update License & Support is the technical support fees paid for the same licenses in the prior year, increased by the Inflationary Adjustment Rate (IAR).“ Wo ein vertraglicher Deckel besteht, gilt der niedrigere Wert. Wie hoch die Inflationsanpassung ist, veröffentlicht Oracle weder in der Preisliste noch in den Support Policies. Die Zahlen, die im Markt kursieren, stammen von Beratern. The Register berichtete 2022 unter Berufung auf zwei Lizenzberatungen von 8 Prozent in den USA, Oracle wollte das nicht kommentieren. Techzines „10 Prozent ab Juni 2026″ ist ohne Quelle.

Die eigentliche Falle liegt in den Oracle Software Technical Support Policies (gültig ab 17. August 2026). Zwei Regeln verhindern, dass Sie Shelfware einfach aus dem Support nehmen:

• Matching Service Levels. „You may not support a subset of licenses within a license set; the license set must be reduced by terminating any unsupported licenses.“ Wer Support für einen Teil nicht mehr will, muss die Lizenzen kündigen.
• Neubepreisung. Werden Lizenzen einer Bestellung teilweise gekündigt, wird der Support für den Rest zum aktuellen Listenpreis abzüglich Standardrabatt neu berechnet. Er übersteigt die bisherige Gebühr für beide Teile zusammen nicht, darf aber auch nicht unter das fallen, was bisher für die verbleibenden Lizenzen gezahlt wurde. Wer beim Kauf einen hohen Rabatt hatte, spart durch die Kündigung also oft deutlich weniger als erwartet.

Wer Support auslaufen lässt und später zurück will, zahlt laut denselben Policies eine Wiederaufnahmegebühr von 150 Prozent der zuletzt gezahlten Jahresgebühr.

Bei SAP liegt der Hebel im Kalender. SAP schreibt: „SAP will provide mainstream maintenance until end of 2027 for SAP Business Suite 7 core applications.“ Danach folgt die verlängerte Wartung: „This comes with a premium of two percent points on the maintenance basis for all support offerings for the scope of SAP Business Suite 7. It will be available for three years from beginning of 2028 until end of 2030.“ Wer sie nicht nimmt, fällt in die Customer-specific Maintenance, deren Umfang SAP auf dieser Seite nicht näher beschreibt.

Für 2031 bis 2033 hat SAP im August 2025 die „SAP ERP, private edition, transition option“ angekündigt, beschrieben als „a time-bound subscription offering designed to provide business continuity from 2031 to 2033″. Das ist keine Wartungsverlängerung im Bestandsvertrag. Voraussetzungen laut SAP: Die Systeme müssen „before December 31, 2030″ auf SAP ERP, private edition on SAP HANA migriert sein, die Option ist „only available in combination with the max success plan“, es gilt ein Minimum von 2 TB, und der Preis liegt „at an uplift compared to the SAP ERP, private edition pricing valid end of 2030″. Der endgültige Preis soll erst 2028 kommuniziert werden.

Die Entscheidung, die daraus folgt. Bewerten Sie Shelfware nicht nach Lizenzwert, sondern nach Wartungsstrom, und schlüsseln Sie sie nach Bestellung und Lizenz-Set auf. Rechnen Sie jede Teilkündigung mit Oracles Neubepreisungsregel durch, bevor Sie sie ankündigen. Und behandeln Sie bei SAP das Jahr 2030 als harte Grenze: Wer danach noch ECC betreiben will, braucht bis dahin eine HANA-basierte Private-Edition-Umgebung und einen Preis, den SAP erst 2028 nennt.

Befund 4: Die Cloud ändert die Zählweise, nicht das Risiko

Oracle erlaubt den Betrieb seiner Software in drei „Authorized Cloud Environments“: AWS (EC2 und RDS), Microsoft Azure und Google Cloud Platform. Dort gelten eigene Regeln:

• „count two vCPUs as equivalent to one Oracle Processor license if multi-threading of processor cores is enabled, and one vCPU as equivalent to one Oracle Processor license if multi-threading of processor cores is not enabled.“
• „When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.“

Im eigenen Rechenzentrum gilt für aktuelle Intel-Xeon- und AMD-EPYC-Prozessoren der Core Factor 0,5. Ein Server mit vier physischen Kernen braucht also zwei Processor-Lizenzen. Dieselben vier Kerne entsprechen in der Cloud bei aktivem Multithreading acht vCPUs, und nach der Cloud-Regel sind das vier Lizenzen. Diese Rechnung ist eine eigene Ableitung aus den beiden Oracle-Dokumenten, keine Aussage von Oracle, und sie setzt voraus, dass jede vCPU ein Hardware-Thread ist, wie es die Zählregel bei aktivem Multithreading unterstellt. Sie zeigt aber die Größenordnung: Bei gleicher Rechenleistung kann sich der Lizenzbedarf verdoppeln. Für die eigene Oracle Cloud gilt eine günstigere Umrechnung. Laut Core-Factor-Tabelle deckt auf x86 eine Processor-Lizenz zwei OCPUs ab.

Auch Standard Edition 2 hat in der Cloud eigene Grenzen: nur auf Instanzen bis acht vCPUs, und je vier vCPUs zählen als ein Socket. Und Lizenzen aus einem Unlimited License Agreement dürfen in diesen Clouds genutzt werden, aber „customers may not include those licenses in the certification at the end of the ULA term“. Wer seine ULA mit dem Ziel ausschöpft, am Ende möglichst viele Lizenzen zu zertifizieren, und parallel in die Public Cloud migriert, arbeitet gegen sich selbst.

Bei SAP ist die Cloud-Seite freundlicher gebaut, aber nicht voraussetzungslos. Das RISE-Material von SAP (Stand März 2021) beschreibt die Metrik Full Usage Equivalents mit Gewichtungen: Ein Nutzer für Advanced Use zählt ein FUE, für Core Use ein Fünftel, für Self-Service Use ein Dreißigstel. SAPs Rechenbeispiel: 40 Advanced-, 75 Core- und 270 Self-Service-Nutzer ergeben 64 FUE. Die Mindestabnahme lag für RISE with SAP S/4HANA Cloud, private edition bei 40 FUE. Ob diese Faktoren in heutigen Verträgen unverändert gelten, ist nicht verifiziert.

Für die Umwandlung bestehender Lizenzen nennt dasselbe SAP-Material unter der Cloud Extension Policy vier Bedingungen, die man vor einer Migration kennen sollte: neue Cloud-Abonnements müssen abgeschlossen werden, die Laufzeit beträgt drei oder fünf Jahre, mit dem Stichtag enden On-Premise-Nutzungsrecht und Wartung („please make sure that you allow for enough time for the transition“), und: „License audit current (6 months old at the most)“. Die Konvertierung setzt also eine aktuelle Vermessung voraus.

Die Entscheidung, die daraus folgt. Rechnen Sie den Lizenzbedarf in der Zielarchitektur, bevor Sie Instanzgrößen festlegen, und zwar mit den Cloud-Regeln des Herstellers, nicht mit den On-Premise-Regeln. Planen Sie bei SAP die Vermessung als Teil des Migrationsplans ein, nicht als Risiko daneben. Das Ergebnis dieser Vermessung ist die Grundlage Ihrer Konvertierungsverhandlung.

Befund 5: Schnittstellen sind Lizenzobjekte

Im Verfahren SAP UK gegen Diageo ([2017] EWHC 189 (TCC)) ging es um zwei Anwendungen: das Portal Connect, über das Diageos Kunden und Händler selbst Bestellungen aufgaben, und die Außendienstanwendung Gen2 für Diageos Vertriebsmitarbeiter. Beide griffen über SAP PI auf SAP ERP zu. SAP forderte 54.503.578 Pfund an zusätzlichen Lizenz- und Wartungsgebühren. Das Gericht stellte fest, dass die Nutzer „accessing or using mySAP ERP indirectly through SAP PI“ seien, und verwies die Höhe in ein gesondertes Verfahren, zu bemessen „by reference to the nature and extent of the usage and SAP’s price list“. Die 54,5 Millionen sind die Forderung, nicht der Urteilsbetrag. Zum endgültigen Betrag liegt für diesen Beitrag keine gelesene Quelle vor.

Wie unklar die Lage damals war, zeigt eine Stellungnahme der DSAG aus dem Mai 2017. Vorstand Andreas Oczko sagte der Computerwoche: „Leider gibt es innerhalb der SAP keine klare Definition beziehungsweise Regelung zur indirekten Nutzung.“

Im April 2018 führte SAP das Modell Digital Access ein. Es zählt neun Typen systemseitig erzeugter Dokumente: Verkaufs-, Rechnungs-, Einkaufs-, Service- und Instandhaltungs-, Fertigungs-, Qualitätsmanagement-, Zeitwirtschafts-, Finanz- und Materialbelege. Verkaufs-, Rechnungs-, Einkaufs-, Finanz- und Materialbelege werden auf Positionsebene gezählt, Finanz- und Materialbelege mit dem Faktor 0,2. Maßgeblich ist das erstmals erzeugte Dokument. „read, update, or delete documents are not counted“.

Für den Umstieg bot SAP das Digital Access Adoption Program an. In der Fassung vom April 2020 hatten Kunden zwei Wege: mindestens 115 Prozent des geschätzten Dokumentvolumens lizenzieren und nur das Wachstum bezahlen, oder mindestens 100 Prozent lizenzieren und 90 Prozent Rabatt auf Digital Access erhalten. Das Programm lief damals bis Ende 2021, und SAP schrieb dazu: „Program is unlikely to be extended again“. Ein Lizenzberater meldete später eine unbefristete Verlängerung. Eine aktuelle SAP-Quelle zum Status 2026 lag für diesen Beitrag nicht vor. Wer das Programm nutzen will, sollte den Status bei SAP schriftlich bestätigen lassen.

Die Entscheidung, die daraus folgt. Erstellen Sie ein Schnittstelleninventar, das für jede Integration drei Fragen beantwortet: Legt sie in SAP Dokumente an, welchen der neun Typen, und in welchem Volumen? Mit dieser Liste können Sie Digital Access bewerten, bevor SAP es in einem Audit tut. SAP bietet dafür selbst einen „Digital Access Evaluation Service“ an, der hilft, „estimating the number of documents relevant to the SAP Digital Access licensing model“.

Was Werkzeuge leisten und was nicht

Für SAP und Oracle gibt es spezialisierte Werkzeuge für Software Asset Management. Eine aktuelle Vergleichsseite (StatWharf, September 2026) listet zehn Anbieter für SAP, von SAP-nativen Werkzeugen über spezialisierte Anbieter bis zu breiten SAM-Plattformen. Die Seite weist selbst darauf hin, dass sie auf öffentlicher Produktdokumentation ohne eigene Tests beruht und dass „vendors may pay for inclusion or placement“. Die Einsparversprechen der Anbieter, die dort zitiert werden, übernimmt dieser Beitrag deshalb nicht.

Drei Kategorien lassen sich trotzdem unterscheiden:

• Werkzeuge des Herstellers. SAPs License Administration Workbench konsolidiert die Vermessungsergebnisse über Systeme und dient dem Auditprozess. Sie optimiert nicht, sie meldet.
• Spezialisierte Optimierer. Sie analysieren tatsächliches Nutzungsverhalten und schlagen günstigere Nutzertypen vor. Ihr Wert hängt davon ab, wie gut sie Ihren Vertrag und Ihre Preisliste abbilden.
• Breite SAM-Plattformen. Sie führen Inventar über viele Hersteller zusammen und sind stark bei Installationsdaten, also genau bei der ersten Schicht aus Befund 1.

Kein Werkzeug liest Ihren Vertrag. Alle vier Befunde oben hängen daran, welche Fassung einer Policy gilt, welche Sonderregel in der Bestellung steht und welche Lizenz-Sets bestehen. Ein Werkzeug liefert das Mengengerüst. Die Übersetzung in Lizenzbedarf bleibt Vertragsarbeit.

Was das für die Geschäftsleitung bedeutet

Das Lizenzrisiko ist ein Architekturrisiko. Ob Oracle auf VMware läuft, ob ein Kubernetes-Cluster automatisch skaliert und welche Integration Belege in SAP anlegt, sind Architekturentscheidungen. Sie werden in der IT getroffen und im Einkauf bezahlt. Wenn beide Seiten nicht miteinander reden, entsteht das Risiko genau dazwischen.

Die Migration ist der teuerste Zeitpunkt für Unwissen. SAP verlangt für die Konvertierung eine aktuelle Vermessung, Oracle rechnet in der Cloud anders als im Rechenzentrum, und beide Hersteller sehen in der Cloud die Nutzung laufend. Wer vorher nicht weiß, was er hat, verhandelt nachher auf Basis der Zahlen des Herstellers.

Die Wartung ist ein Budget, das sich selbst fortschreibt. Sie steigt jährlich, ohne dass jemand eine Entscheidung trifft. Sie zu senken erfordert dagegen Entscheidungen, deren Folgen in Regeln stehen, die kaum jemand liest.

Übersicht für die Geschäftsleitung

Häufige Fragen

Anhang: Methodik

Art der Untersuchung. Primärdokumentenanalyse der Lizenz-, Preis- und Supportdokumente von SAP und Oracle, ergänzt um drei vom Auftraggeber vorgegebene Sekundärquellen.

Angewandte Rahmen. SCQA für die Rahmung sowie ein Abgleich der Metrikdefinitionen beider Hersteller mit der Frage, ob sie Installation, Berechtigung oder Nutzung zählen. Porter, BCG-Matrix, PESTEL und Wertkette wurden geprüft und verworfen, weil sie Branchen- und Portfoliofragen beantworten, nicht Lizenzmechanik.

Quellen und Qualität. Alle Aussagen über SAP- und Oracle-Regeln stützen sich auf Dokumente der Hersteller, am 28. September 2026 direkt abgerufen. oracle.com beantwortet automatisierte Abrufe teils mit HTTP 403, die PDFs wurden deshalb direkt geladen und im Volltext gelesen. Vertragszitate stehen im englischen Original, weil ein übersetztes Vertragszitat kein Beleg mehr ist.

Eigene Ableitungen. Die 22 Prozent Supportquote sind aus den Tabellenwerten der Oracle-Preisliste berechnet. Die Verdopplung des Lizenzbedarfs in der Public Cloud ist aus Core-Factor-Tabelle und Cloud-Lizenzregeln abgeleitet. Beides ist im Text als eigene Rechnung gekennzeichnet.

Grenzen.

1. Das SAP-RISE-Material (FUE-Faktoren, Cloud Extension Policy) stammt vom März 2021. Aktuelle Vertragskonditionen können abweichen.
2. Das Diageo-Urteil wurde über eine Drittwiedergabe gelesen, weil der Originaltext bei bailii automatisierte Abrufe blockt.
3. Oracles Vertragsklausel zur Auditfrist stammt aus öffentlich hinterlegten OLSA-Mustern, nicht aus einem aktuellen Oracle Master Agreement.
4. Der Status des Digital Access Adoption Program für 2026 ist aus SAP-Quellen nicht bestätigt.
5. Das Dokument zur Oracle-Datenbanklizenzierung trägt den Stand August 2019.

Bewusst nicht verwendete Zahlen. Die Supportsteigerungen „4 auf 8 auf 10 Prozent“ (Techzine, ohne Quelle), in Beraterblogs kursierende Konvertierungsgutschriften für die SAP Cloud Extension Policy, Einsparversprechen von SAM-Anbietern aus einer Vergleichsseite mit bezahlter Platzierung und ein kolportierter prozentualer Aufschlag für die verlängerte SAP-Wartung, der sich auf SAPs Seite nicht findet (dort stehen zwei Prozentpunkte auf die Wartungsbasis).

Quellen

1. Berry Zwets: Oracle and SAP license chaos: Understand what you have before you migrate. Techzine, 25. Februar 2026. https://www.techzine.eu/blogs/applications/139071/oracle-and-sap-license-chaos-understand-what-you-have-before-you-migrate/
2. David Foxen: SAP Licensing, is there an elephant in the room? itassetmanagement.net, 13. Juni 2014. https://itassetmanagement.net/2014/06/13/sap-licensing-elephant-room/
3. StatWharf Editorial: SAP License Management Software. September 2026. https://statwharf.com/best/sap-license-management-software/
4. SAP Support: Maintenance 2040. https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html
5. Stefan Steinle: Navigating Your RISE with SAP Journey: Updates for SAP ERP, Private Edition, Transition Option. SAP News, 4. August 2025. https://news.sap.com/2025/08/rise-with-sap-journey-sap-erp-private-edition-transition-option-updates/
6. SAP: SAP Digital Access / SAP Digital Access Adoption Program (DAAP). April 2020. https://news.sap.com/wp-content/blogs.dir/1/files/DAAP_External_FV_050520.pdf
7. SAP SE: RISE with SAP S/4HANA Cloud, Licensing Overview. März 2021. https://assets.dm.ux.sap.com/webinars/sap-user-groups-k4u/pdfs/210316_rise_with_sap_s4hana_cloud_license_overview.pdf
8. SAP Help: Process of System Measurement. https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-US/48/c6eb7b7a004da5e10000000a421937/content.htm
9. SAP Help: License Administration Workbench. https://help.sap.com/doc/saphelp_nw75/7.5.5/en-US/48/c6e74b7a004da5e10000000a421937/content.htm
10. SAP Support: SAP Global Adoption & Experience CoE. https://support.sap.com/en/my-support/systems-installations/glac.html
11. SAP (UK) Ltd v Diageo Great Britain Ltd [2017] EWHC 189 (TCC), Wiedergabe getcaselaw. https://www.getcaselaw.com/case-library/f27ab4ab-6afd-496a-bb72-6fb428fc2aa7
12. Computerwoche: SAP will indirekte Nutzung klären und scheitert. 26. Mai 2017. https://www.computerwoche.de/article/2758821/sap-will-indirekte-nutzung-klaeren-und-scheitert.html
13. Oracle: Partitioning Policy, Stand 14. Februar 2022. https://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf
14. Oracle: Processor Core Factor Table, aktualisiert 28. Januar 2026. https://www.oracle.com/contracts/docs/processor-core-factor-table-070634.pdf
15. Oracle: Database Licensing, Stand 6. August 2019. https://www.oracle.com/a/ocom/docs/database-licensing-070584.pdf
16. Oracle: Licensing Oracle Software in the Cloud Computing Environment, Stand 4. September 2026. https://www.oracle.com/a/ocom/docs/cloud-licensing-070579.pdf
17. Oracle: Java SE Universal Subscription Global Price List, 1. März 2023. https://www.oracle.com/a/ocom/docs/corporate/pricing/java-se-subscription-pricelist-5028356.pdf
18. Oracle: Java SE Universal Subscription FAQ. https://www.oracle.com/java/technologies/java-se-subscription-faq.html
19. Oracle: Technology Global Price List, 15. September 2026. https://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf
20. Oracle: Software Technical Support Policies, gültig ab 17. August 2026. https://www.oracle.com/contracts/docs/057419.pdf
21. Oracle: Fusion Cloud Service Descriptions, gültig ab 10. September 2026. https://www.oracle.com/contracts/docs/oracle-fusion-cloud-service-desc-1843611.pdf
22. Oracle: License and Services Agreement (öffentliches Muster, Oracle EMEA). https://www.oracle.com/us/corporate/pricing/olsa-ire-v122304-070683.pdf
23. Lindsay Clark: Oracle to hike support fees in line with inflation. The Register, 25. Juli 2022. https://www.theregister.com/2022/07/25/oracle_set_to_impose_inflationary

Alle Quellen abgerufen am 28. September 2026.