Oracle-Datenbanken wandern in die Public Cloud, meist per Bring Your Own License. Der Gedanke ist einfach: vorhandene Lizenzen mitnehmen und nur noch Rechenzeit zahlen. In der Praxis lauern hier eigene Fallen, denn Oracle bewertet die Cloud-Lizenzierung anders als das eigene Rechenzentrum. ProLicense, die unabhängige Lizenzberatung, erklärt, worauf es ankommt.

Wie Oracle Cloud-Cores zählt

AWS, Azure und Google Cloud gelten als Authorized Cloud Environments. Dort wendet Oracle nicht die vertraute Prozessor-Kernfaktor-Tabelle an, sondern zählt nach virtuellen CPUs. Bei aktivem Hyperthreading werden zwei vCPUs als eine Prozessorlizenz gewertet, ohne Hyperthreading zählt eine vCPU als eine Lizenz. Weil der Core-Faktor von 0,5 für x86 in der Cloud wegfällt, verdoppelt sich der Lizenzbedarf für dieselbe Hardware schnell gegenüber dem eigenen Rechenzentrum. Wichtig zu wissen: Zu lizenzieren ist die maximale vCPU-Zahl der Instanz, das Abschalten einzelner vCPUs senkt den Bedarf nicht.

Die OCI-Bevorzugung

Oracles eigene Cloud, OCI, fällt nicht unter diese Policy, sondern ist vertraglich über die Servicebeschreibung geregelt. Und sie ist bewusst günstiger gestellt. In OCI deckt eine Lizenz zwei OCPUs ab, was rund vier vCPUs an Rechenleistung entspricht. Dieselbe Last braucht damit in OCI etwa halb so viele Lizenzen wie in AWS oder Azure. Dazu kommen Support Rewards, also Gutschriften auf die Supportkosten. Das ist kein Zufall, sondern Oracles Anreiz, Kunden in die eigene Cloud zu ziehen. Wer bei AWS oder Azure bleibt, muss diesen Unterschied in der Rechnung berücksichtigen.

„In der Cloud verschwindet der Core-Faktor, und plötzlich braucht dieselbe Datenbank doppelt so viele Lizenzen wie im eigenen Haus. In OCI sieht die Rechnung ganz anders aus. Das ist Oracles Anreiz, und man muss ihn kennen, bevor man migriert, nicht danach“, sagt Markus Oberg, Partner der ProLicense.

Policy ist nicht Vertrag

Wie bei der Virtualisierung im eigenen Haus gilt auch in der Cloud: Die Zählregeln stehen in Oracles Cloud-Policy, einem Positionspapier, das Oracle jederzeit ändern kann. Vertraglich bindend sind nur der Rahmenvertrag und das Bestelldokument. Deshalb sollte die zum Zeitpunkt der Migration geltende Fassung der Policy festgehalten und jede Instanz dagegen dokumentiert werden. Wer die Oracle-Lizenzierung in der Cloud sauber gegen den Vertrag hält, hat im Streitfall die besseren Argumente.

Die häufigsten BYOL-Fallen

Immer wieder sind es dieselben Fehler. Die Doppellizenzierung, wenn Support im eigenen Haus und in der Cloud parallel läuft. Die falsche Anrechnung, wenn Hyperthreading und die maximale vCPU-Zahl nicht sauber berücksichtigt werden. Optionen und Packs, die in der Cloud unbemerkt mitgezählt werden. Die unklare Trennung von Nicht-Produktion, die eigentlich anders zu behandeln wäre. Und die Annahme, die Cloud-Policy sei bindend, obwohl sie es nicht ist. Jeder dieser Punkte kann im Audit teuer werden.

„Die Cloud-Policy ist kein Gesetz und kein Vertrag, sie ist Oracles Position. Wer sie kennt und die geltende Fassung dokumentiert, kann überzogene Nachforderungen abwehren. Der teuerste Fehler ist, ohne Lizenzrechnung in die Cloud zu gehen“, sagt Sören Reimers, Rechtsanwalt und Geschäftsführer der ProLicense.

ProLicense rechnet die Cloud-Lizenzierung vor der Migration durch, prüft den Vertrag gegen die Policy und wählt das günstigste Modell, unabhängig von der Cloud. Auch im Oracle-Audit steht ProLicense auf Kundenseite. Ziel bleibt in jedem Fall dasselbe: minimale Kosten bei voller Compliance. Wer Oracle in die Cloud bringen oder eine bestehende Cloud-Lizenzierung prüfen lassen will, erreicht ProLicense unter +49 (0) 40-228 6828-0.

Nach der Broadcom-Übernahme wechseln viele Unternehmen von VMware auf Nutanix und gehen davon aus, dass das Oracle-Lizenzproblem mit verschwindet. Das ist ein Trugschluss. Oracle behandelt Nutanix AHV grundsätzlich wie VMware, als Soft Partitioning. Ohne die richtige Konstellation wandert die Hard-Partitioning-Falle einfach mit um. ProLicense, die unabhängige Lizenzberatung, ordnet ein, worauf es bei Oracle auf Nutanix ankommt.

Warum Nutanix allein das Problem nicht löst

Oracle erkennt nur wenige Technologien als Hard Partitioning an. Nutanix AHV gehört in der Standardkonfiguration nicht dazu und gilt als Soft Partitioning. Damit greift derselbe Grundsatz wie bei VMware: Lizenzpflichtig ist nicht der genutzte Kern, sondern jeder Core in jedem Knoten des Clusters, auf dem die Datenbank laufen könnte. Ein einziger Oracle-Server auf einem Vierknoten-Cluster kann so eine Forderung über sämtliche Cores aller vier Knoten auslösen. Der Plattformwechsel allein ändert daran nichts.

„Der häufigste Irrtum ist, dass ein Wechsel von VMware auf Nutanix das Oracle-Thema erledigt. Das tut er nicht. Oracle zählt auf AHV genauso den ganzen Cluster. Aus meiner Zeit bei Oracle kenne ich diese Rechnung, und ich weiß, wie man sie sauber begrenzt“, sagt Christian Grave, Geschäftsführer der ProLicense.

Wo der Unterschied wirklich liegt

Entscheidend ist nicht die Plattform, sondern die nachweisbare Eingrenzung. Der belastbare Weg ist ein dedizierter Oracle-Cluster oder ein fest zugeordneter Satz von Knoten, auf dem ausschließlich Oracle läuft. Dann sind nur die Cores dieser Knoten lizenzpflichtig, nicht die des gesamten Clusters. Nutanix bietet dafür saubere Mittel: die feste Zuordnung von Oracle-Workloads, unterbundene Migrationspfade und Speicherknoten, die keine virtuellen Maschinen ausführen und deshalb auch keine Oracle-Lizenz benötigen. Aus einer Forderung über den ganzen Cluster wird so eine Forderung über wenige Knoten.

Was der Nachweis leisten muss

Die Isolation wirkt nur, wenn sie dokumentiert und durchgesetzt ist. Im Audit zählt der Nachweis, nicht die Zusicherung. Dazu gehören die klare Zuordnung der Oracle-Maschinen zu bestimmten Knoten, unterbundene Migrationspfade über die Isolationsgrenze hinweg und eine konsistente, belegbare Konfiguration. Gefährlich wird es, wenn diese Grenze im Betrieb verrutscht: Eine Cluster-Erweiterung, ein Knotentausch oder eine Live-Migration über die Grenze hebt die Verteidigung auf und stellt die volle Forderung wieder her. Deshalb wird die Dokumentation laufend gepflegt und regelmäßig geprüft.

Policy ist nicht Vertrag

Wie bei VMware gilt auch hier: Oracles Haltung zur Virtualisierung steht in der Partitioning Policy, einem Positionspapier, nicht im Vertrag. Maßgeblich ist der Vertrag, und der lizenziert, was installiert und/oder betrieben ist. Wer die Oracle-Lizenzierung von Anfang an sauber aufsetzt und die Auditklausel gegen die Forderung hält, muss die Rechnung über den ganzen Cluster nicht hinnehmen. Am günstigsten ist es, die Lizenzierung schon bei der Migration auf Nutanix mitzuplanen, nicht erst im Audit.

„Die Partitioning Policy ist Oracles Position, nicht der Vertrag. Wer den Oracle-Cluster auf Nutanix von Anfang an sauber isoliert und das dokumentiert, hält die Lizenzbasis klein und die Forderung im Rahmen. Der Fehler passiert fast immer bei der Migration, wenn niemand an die Lizenz denkt“, sagt Sören Reimers, Rechtsanwalt und Geschäftsführer der ProLicense.

ProLicense ist Nutanix-Partner und plant die Oracle-Lizenzierung auf Nutanix von Anfang an mit. Das Team aus Lizenzexperten und Rechtsanwälten grenzt die Basis ein, dokumentiert die Architektur und hält sie gegen den Vertrag, auch im Oracle-Audit. Ziel bleibt in jedem Fall dasselbe: minimale Kosten bei voller Compliance. Wer Oracle auf Nutanix betreibt oder den Umstieg plant, erreicht ProLicense unter +49 (0) 40-228 6828-0.

Microsoft beendet den Support für .NET 8 und .NET 9 am 10. November 2026. Beide Versionen erreichen ihr Supportende am selben Tag. Danach liefert Microsoft für sie keine Sicherheitsupdates mehr, auch nicht für schwere Lücken. Die unabhängige Lizenzberatung ProLicense rechnet damit, dass für viele Unternehmen Herausforderungen entstehen in Sachen Cyber Security und Compliance bezüglich bestimmter Regularien wie DORA, NIS2, BAIT, VAIT und anderen.

Warum zwei Versionen am selben Tag auslaufen

Microsoft veröffentlicht jedes Jahr im November eine neue .NET-Version, abwechselnd mit langem und kurzem Supportzeitraum. .NET 8 gehört zu den Versionen mit langem Support, drei Jahre ab Erscheinen. .NET 9 gehört zu denen mit kurzem. Für diese kurze Variante hat Microsoft den Zeitraum von 18 auf 24 Monate angehoben. Damit endet der Support für .NET 9 genau an dem Tag, an dem auch die drei Jahre für .NET 8 ablaufen. Wer bisher beide Versionen parallel betrieben hat, um das Risiko zu verteilen, verliert diesen Abstand.

Die Software läuft weiter, die Updates nicht

Am 11. November arbeiten alle Anwendungen wie am Tag davor. Nichts fällt aus, nichts meldet einen Fehler. Genau deshalb wird die Frist in vielen Häusern unterschätzt. Nach Schwachstellen wird trotzdem weiter gesucht, von Angreifern ebenso wie von der Cyber Security Branche. Neue Lücken in .NET 8 und .NET 9 kommen also weiter ans Licht, nur liefert Microsoft keine Korrektur mehr dafür. Die Prüfwerkzeuge der eigenen IT melden diese Lücken Monat für Monat erneut, ohne dass sich eine davon jemals schließen lässt. Dazu kommt die spätere Neubewertung. Eine Schwachstelle, die heute als wenig gefährlich eingestuft ist, kann Jahre danach auf der Liste der aktiv ausgenutzten Schwachstellen landen, die die US-Behörde CISA führt, und wird damit zum Sofortfall. Bei einer unterstützten Version folgt darauf ein Update. Bei .NET 8 und .NET 9 folgt darauf nichts.

Auditoren fragen nicht nach der neuesten Version

Kein gängiger Standard schreibt vor, die jeweils neueste Software einzusetzen. PCI DSS verlangt, kritische Sicherheitsupdates innerhalb fester Fristen einzuspielen, und den regelmäßigen Nachweis, dass die eingesetzte Software vom Hersteller noch unterstützt wird. ISO/IEC 27001:2022 fordert in Anhang A, Maßnahme 8.8, technische Schwachstellen zeitnah zu behandeln. Fehlt das Update des Herstellers, wird aus einer Routinefrage im Software-Audit ein Befund, der in den Prüfbericht wandert. Cyberversicherer bewerten das ähnlich. Coalition berichtete im Cyber Claims Report 2023, dass Organisationen mit abgekündigter Software dreimal häufiger einen Sicherheitsvorfall meldeten und dass eine einzige offene kritische Schwachstelle die Wahrscheinlichkeit einer Schadenmeldung um 33 % erhöhte.

Zwei Wege, und die Wahl fällt je Anwendung

Ein möglicher Lösungsweg ist jede Anwendung einzeln zu bewerten, statt eine Entscheidung für das gesamte Portfolio zu treffen. Was sich bis zum 10. November realistisch auf .NET 10 umstellen lässt, wird umgestellt. Diese Version unterstützt Microsoft bis November 2028. Für alles andere bleibt Drittsupport. ProLicense liefert dafür als Partner von HeroDevs den Never-Ending Support (NES) für .NET. Dabei tauscht die IT die abgekündigte .NET-Version gegen eine weiter gepflegte Fassung desselben Stands aus, ohne den Programmcode der Anwendungen zu ändern. HeroDevs sitzt in der .NET Security Group, dem Kreis, in dem Microsoft neue Schwachstellen vorab abstimmt, und veröffentlicht seine Korrekturen an denselben monatlichen Terminen wie Microsoft. Zu jeder Lieferung gehört eine signierte Bestätigung darüber, welche Schwachstellen geprüft und behoben wurden. Das ist der Nachweis, nach dem ein Auditor fragt.

„Die teuerste Variante ist die Panikumstellung acht Wochen vor dem Stichtag. Wer eine Anwendung ohnehin in zwei Jahren abschaltet, zahlt sonst für eine Umstellung, die danach niemand mehr braucht. Drittsupport kostet in solchen Fällen einen Bruchteil und hält die Compliance vollständig", sagt Markus Oberg, Partner und Business Development Manager der ProLicense.

Am Anfang steht die Liste

Vor jeder Entscheidung steht die Bestandsaufnahme: jede Anwendung im Produktivbetrieb, die auf .NET 8 oder .NET 9 läuft, einschließlich interner Werkzeuge und der Systeme, die ein Dienstleister betreibt. Dazu der Vermerk, welche davon regulierte Daten verarbeiten oder in den Prüfumfang von PCI DSS, SOC 2 oder ISO 27001 fallen. ProLicense bewertet diese Liste herstellerunabhängig und bezieht kein Geld von Microsoft. Der Anspruch bleibt in beide Richtungen derselbe: minimale Kosten bei voller Compliance. Unternehmen mit .NET-8- oder .NET-9-Beständen erreichen ProLicense über die Webssite.

In vielen Unternehmen laufen AngularJS, Vue 2, ältere Spring- oder .NET-Versionen in Kernanwendungen. End-of-Life heißt nicht, dass diese Anwendungen stehen bleiben. Ohne Sicherheitspatches werden sie aber zur Angriffsfläche. Sie deshalb sofort neu zu bauen, ist teuer und selten nötig. ProLicense, die unabhängige Lizenzberatung, zeigt, wie sich abgekündigte Frameworks sicher weiterbetreiben lassen.

Was End-of-Life praktisch bedeutet

Erreicht ein Framework das Ende seines Lebenszyklus, stellt das Projektteam die Pflege ein. Es kommen keine neuen Sicherheitspatches mehr, auch wenn später kritische Schwachstellen bekannt werden. Die Anwendung läuft weiter, doch das Risiko wächst leise mit. Jede neue Lücke bleibt offen, und genau darauf zielen Angreifer und Sicherheitsscanner. Im Audit und in Kundenfragebögen taucht die abgekündigte Komponente auf, und dann steht die Frage im Raum, wer sie absichert.

Was Never-Ending Support leistet

Never-Ending Support, kurz NES, schließt genau diese Lücke. Der Anbieter HeroDevs übernimmt die Pflege dort, wo das ursprüngliche Projekt aufgehört hat: Er findet neue Schwachstellen, entwickelt Patches und liefert sie mit garantierten Reaktionszeiten. Technisch ist NES ein Drop-in-Ersatz. In der Praxis genügt es, die Paketreferenz zu ändern und das Projekt neu zu bauen, ohne Änderungen am eigenen Code. Die Anwendung bleibt also, wie sie ist, nur die Sicherheitslücken werden geschlossen. Kein Rewrite, kein Framework-Wechsel.

„Der Reflex ist, eine abgekündigte Anwendung sofort neu zu bauen. Dabei bleibt sie mit Never-Ending Support einfach sicher, ohne dass eine Zeile Anwendungscode angefasst wird. Man tauscht die Bibliothek, nicht die Anwendung, und die Sicherheitslücken sind zu“, sagt Christian Grave, Geschäftsführer der ProLicense.

Für welche Frameworks es das gibt

NES deckt die verbreiteten abgekündigten Frameworks ab. Dazu gehören AngularJS und ältere Angular-Versionen, Vue 2, jQuery, Spring und Spring Boot, .NET und .NET Core, Node.js und Express, Bootstrap, Drupal und Tomcat, dazu über dreißig weitere. Die Patches stammen von Entwicklern, die die jeweiligen Projekte aus eigener Mitarbeit kennen. Wer wissen will, ob das eigene Framework dabei ist, lässt seine Anwendungslandschaft prüfen. Meist stecken mehr abgekündigte Komponenten darin als gedacht.

Never-Ending Support als Brücke zur Migration

NES und Migration sind keine Gegensätze. Eine Migration ist irgendwann sinnvoll, aber sie ist teuer, bindet die besten Entwickler und liefert erst am Ende Sicherheit. Never-Ending Support macht die Anwendung sofort sicher und verschafft die Zeit, die Migration geplant und ohne Druck anzugehen. Aus der erzwungenen Hauruck-Aktion wird ein Projekt, das sich terminieren lässt. In vielen Fällen ist NES deshalb genau die Brücke, die ein Unternehmen braucht.

„Wir zwingen niemanden in eine sofortige Migration. Never-Ending Support hält die Anwendung sicher, und das Unternehmen entscheidet selbst, wann und ob es migriert. Diese Brücke ist oft günstiger als jedes überstürzte Projekt“, sagt Markus Oberg, Partner der ProLicense.

ProLicense ist Reseller von HeroDevs und liefert Never-Ending Support direkt. Dazu berät ProLicense, welche abgekündigten Frameworks in den Systemen stecken und für welches davon welcher Weg der sicherste und günstigste ist. Ziel bleibt in jedem Fall dasselbe: minimale Kosten bei voller Compliance. Wer seine Anwendungslandschaft prüfen lassen will, erreicht ProLicense über die Kontaktseite oder unter +49 (0) 40-228 6828-0.

Vier Regelwerke, ein Befund

DORA gilt im Finanzsektor seit Januar 2025 und verlangt ein Risikomanagement für Informations- und Kommunikationstechnik, das unterstützte Software voraussetzt. Die BaFin-Anforderungen aus BAIT und VAIT führen abgekündigte Software als Prüfungsfeststellung. In Deutschland gilt NIS2 seit dem 6. Dezember 2025 über das NIS2-Umsetzungsgesetz, in Österreich beginnt die Anwendung des NISG 2026 am 1. Oktober 2026. Der Cyber Resilience Act verpflichtet Hersteller seit dem 11. September 2026 zur Meldung aktiv ausgenutzter Schwachstellen, die volle Anwendbarkeit folgt im Dezember 2027.

Hersteller melden, ohne patchen zu können

Für Softwarehäuser, Maschinenbauer und Medizintechnikhersteller verschärft sich die Lage. Wer ein Produkt mit digitalen Elementen ausliefert, muss eine ausgenutzte Schwachstelle melden. Steckt in diesem Produkt eine abgekündigte Komponente, existiert kein Patch, den der Hersteller nachreichen könnte.

„Im Audit zählt nicht die Absicht, sondern der Nachweis. Ein Migrationsprojekt im Plan ersetzt keinen Patch. Ohne dokumentierte Absicherung bleibt die Feststellung im Bericht stehen“, sagt Markus Oberg, Partner und Business Development Manager der ProLicense.

Versicherer fragen genauer nach

Cyberversicherer prüfen nach einem Vorfall, ob abgekündigte Software dazu beigetragen hat, und kürzen Leistungen häufiger. ISO 27001 und SOC 2 verlangen für Komponenten ohne Support einen dokumentierten Plan zur Risikominderung. PCI DSS v4 bewertet jede solche Komponente im Zahlungsumfeld als Abweichung.

Austausch unter Lizenzmanagern

Markus Oberg ist zugleich Chairman der Lighthouse Alliance, einer herstellerunabhängigen Community von Software-Lizenzmanagern und IT-Einkäufern im DACH-Raum. Der Umgang mit abgekündigten Komponenten betrifft dort Mitglieder aus Finanzwirtschaft, Industrie und öffentlicher Verwaltung gleichermaßen.

Bewertung im Einzelfall

Welche Komponenten betroffen sind und wie viele Anwendungen daran hängen, klärt ProLicense im Einzelfall. Die Beratung ist Partner von HeroDevs für den DACH-Raum und bewertet unabhängig, ob Drittsupport, Migration oder eine Kombination die geringeren Kosten bei voller Compliance ergibt. Unternehmen wenden sich dafür direkt an ProLicense.

Vier Monate bis zum Supportende

Spring Boot ist das verbreitetste Framework für Java-Geschäftsanwendungen. In Banken, Versicherungen, Industrieunternehmen und öffentlicher Verwaltung tragen damit gebaute Anwendungen häufig Kernprozesse. Broadcom hat den kommerziellen Support für die 2er-Generation mehrfach verlängert, zuletzt bis Ende 2026. Danach steht für diese Anwendungen kein Herstellersupport mehr zur Verfügung. Auch frühe Stände der Nachfolgegeneration sind abgekündigt, darunter Spring Boot 3.0 bis 3.3.

Migration dauert länger als das verbleibende Zeitfenster

Der Wechsel auf Spring Boot 3 ist kein gewöhnliches Versionsupdate.Er setzt Java 17 voraus. Dazu kommt die Umstellung von javax auf jakarta, die sich durch den gesamten Programmcode zieht. Betroffen sind sämtliche Abhängigkeiten einer Anwendung, auch die von Drittanbietern. In gewachsenen Anwendungslandschaften dauern solche Projekte nach Erfahrung aus der Beratungspraxis zwischen zwölf und 36 Monaten. Vier Monate reichen dafür nicht.

„Wer die Migration erst begonnen hat, steht im Januar trotzdem ohne Support da. Das Projekt läuft weiter, der Schutz nicht. Genau diese Lücke muss überbrückt werden, bevor sie entsteht“, sagt Christian Grave, Geschäftsführer der ProLicense.

Was Lizenzmanager jetzt prüfen sollten

Der Status lässt sich ohne tiefe technische Prüfung feststellen. Die Frage an Entwicklung oder Betrieb lautet, auf welcher Java- und welcher Spring-Boot-Version die Kernanwendungen laufen. Jeder Stand, der mit 2. beginnt, fällt unter das Supportende. Wer zusätzlich noch Java 8 oder Java 11 einsetzt, steht vor einem zweiten Modernisierungsschritt.

Drittsupport als Übergang

Für abgekündigte Open-Source-Komponenten liefert HeroDevs Sicherheitspatches, die ohne Änderung am Code eingebunden werden. ProLicense ist Partner von HeroDevs für den DACH-Raum und begleitet Unternehmen bei Bewertung, Umfang und Verhandlung. Ob Drittsupport, Migration oder eine Kombination günstiger ausfällt, hängt vom Einzelfall ab. Unternehmen klären das im persönlichen Gespräch.

Das Ziel von ProLicense bleibt in beiden Fällen dasselbe: minimale Kosten bei voller Compliance.

Nach jeder Preiserhöhung stellen Unternehmen dieselbe Frage: Kommen wir ganz von Oracle weg? Die ehrliche Antwort lautet selten sofort und komplett, aber fast immer schrittweise und deutlich günstiger. Ein Ausstieg ist kein einzelnes Projekt, sondern ein Weg in Etappen. Entscheidend sind die richtige Reihenfolge und die Compliance auf jedem Schritt. ProLicense, die unabhängige Lizenzberatung, zeigt, wie das gelingt.

Warum der Big Bang selten funktioniert

Oracle-Datenbanken stecken tief in den Kernprozessen. Eine vollständige Ablösung auf einen Schlag dauert lange, bindet Ressourcen und schafft neue Risiken. Wer alles gleichzeitig angeht, verliert Zeit und Geld. Realistischer ist ein Stufenplan: Zuerst kommen die schnellen, risikoarmen Hebel, die sofort Kosten senken. Danach folgen die großen Brocken, geplant und ohne Zeitdruck. So finanziert der Ausstieg sich in Teilen selbst.

Die Ebenen des Ausstiegs

Ein Oracle-Exit hat mehrere Ebenen, und jede ist ein eigener Hebel. Beim Support führt der Weg von Oracle zu Drittsupport. Bei Java tritt eine Alternative an die Stelle von Oracle Java. Die Datenbank selbst lässt sich auf PostgreSQL und andere Open-Source-Optionen umziehen. Bei der Virtualisierung geht es um VMware, Nutanix und die Hard-Partitioning-Frage. Und der Lizenzbestand bietet einen eigenen Hebel, weil sich ungenutzte Lizenzen über den Gebrauchtmarkt verkaufen lassen.

Die richtige Reihenfolge

Die Kunst liegt in der Reihenfolge. Zuerst kommen die Hebel, die schnell und ohne großes Risiko wirken: der Wechsel auf Drittsupport, die Ablösung von Oracle Java und der Verkauf ungenutzter Lizenzen. Diese Schritte senken die Kosten sofort und schaffen Budget. Erst danach folgen die größeren Projekte auf der Middleware- und der Datenbank-Ebene, die mehr Zeit brauchen. Die Ersparnis der frühen Schritte zahlt die späteren. So entsteht ein Ausstieg, der sich rechnet, statt einer teuren Migration auf Verdacht.

Compliance auf dem Weg

Jeder Schritt muss vertragskonform sein. Wer Support teilweise abbaut, stößt auf Repricing und Matching Service Levels Regelungen. Wer Lizenzen reduziert, zieht Oracles Aufmerksamkeit auf sich. Ein unsauberer Ausstieg ist eine Einladung zum Audit. Deshalb wird der Weg rechtlich begleitet, und die Oracle-Lizenzierung an jeder Stelle gegen den Vertrag gehalten. Der Exit senkt Kosten nur dann wirklich, wenn er die Compliance an keinem Punkt bricht.

ProLicense plant den Exit

ProLicense ist ein Team aus Lizenzexperten und Rechtsanwälten und plant den Ausstieg realistisch. Es priorisiert die Hebel, finanziert den Weg über die frühen Einsparungen und hält die Compliance an jeder Stelle. So wird aus dem vagen Wunsch, von Oracle wegzukommen, ein geordneter Plan mit sichtbaren Ergebnissen ab dem ersten Schritt. Ziel bleibt in jedem Fall dasselbe: minimale Kosten bei voller Compliance. Wer eine Exit-Strategie für die eigene Umgebung will, erreicht ProLicense unter +49 (0) 40-228 6828-0.

„Weg von Oracle heißt nicht, morgen alles abzuschalten. Es heißt, in der richtigen Reihenfolge vorzugehen. Die schnellen Hebel wie Drittsupport und Java bringen sofort Geld, und dieses Geld finanziert die großen Schritte. So wird der Ausstieg bezahlbar“, sagt Markus Oberg, Partner der ProLicense.

„Der gefährlichste Fehler beim Ausstieg ist, die Compliance zu vergessen. Jede Reduktion, jede Teilkündigung hat vertragliche Folgen. Wir begleiten jeden Schritt rechtlich, damit aus dem Sparprogramm kein Audit wird“, sagt Sören Reimers, Rechtsanwalt und Geschäftsführer der ProLicense.

Läuft die Garantie einer Server-, Storage- oder Netzwerk-Hardware aus, drängen Hersteller wie Dell EMC, HPE, Cisco oder NetApp zu teuren Wartungsverträgen oder gleich zum Neukauf. Technisch läuft die Hardware oft noch jahrelang. Genau hier setzt Third-Party-Maintenance an, kurz TPM, die herstellerunabhängige Wartung. ProLicense, die unabhängige Lizenzberatung, rechnet den Unterschied zwischen TPM und OEM auf.

Wo der OEM teuer wird

Nach Garantieende steigt die OEM-Wartung deutlich. Dazu kommen erzwungene End-of-Life-Termine, an denen der Hersteller Support einstellt und einen Neukauf nahelegt, oft lange bevor die Hardware wirklich am Ende ist. Support-Stufen werden gebündelt, auch wenn ein Unternehmen nur einen Teil braucht, und der Verhandlungsspielraum ist gering. Das Ergebnis ist eine Wartungsrechnung, die in keinem Verhältnis zum tatsächlichen Bedarf steht.

Was TPM anders macht

Ein TPM-Anbieter wartet Server, Storage und Netzwerk aller großen Hersteller, unabhängig vom Logo auf dem Gerät. Für Multi-Vendor-Umgebungen gibt es damit einen Ansprechpartner statt vieler. Abgeschriebene Hardware lässt sich über das offizielle Ende hinaus weiter betreiben, die Service-Level liegen auf OEM-Niveau, und die Reaktion ist oft schneller. Der Preis liegt typisch 30 bis 40 % unter der OEM-Wartung. Die Ersparnis lässt sich in neue Technik oder andere Vorhaben investieren.

Was TPM nicht leistet

Zur Ehrlichkeit gehört die Abgrenzung. TPM liefert keine neuen Firmware- oder Software-Releases des Herstellers und ersetzt nicht die Garantiephase eines Neugeräts. Sein Feld ist der Post-Warranty-Betrieb: Hardware, die aus der Garantie gelaufen ist, Legacy-Systeme und Geräte, die der Hersteller abgekündigt hat. Für neue Systeme in der Garantie ist der OEM der richtige Weg, für alles danach spielt TPM seine Stärke aus.

„Der Hersteller nutzt das Garantieende als Verkaufsanlass. Dabei läuft die Hardware technisch weiter. Mit Third-Party-Maintenance sparen Unternehmen 30 bis 40 % und betreiben ihre Systeme so lange, wie sie wollen, statt sich zum Neukauf drängen zu lassen“, sagt Markus Oberg, Partner der ProLicense.

Wann sich der Wechsel rechnet

Der Wechsel lohnt sich vor allem, wenn die OEM-Wartung ausläuft, wenn Legacy- oder abgekündigte Hardware im Betrieb ist, bei einer Konsolidierung des Rechenzentrums oder in gewachsenen Multi-Vendor-Landschaften. In all diesen Fällen ist die OEM-Wartung teuer oder gar nicht mehr verfügbar, während TPM die Systeme zuverlässig weiter am Laufen hält.

Die Brücke zum Software-Drittsupport

TPM ist die Hardware-Variante eines Prinzips, das ProLicense auf der Software-Ebene seit Langem verfolgt. Dort holt ProLicense Unternehmen aus teuren Oracle-Supportverträgen und führt sie in den Drittsupport. Auf der Hardware-Ebene übernimmt das ein spezialisierter Wartungspartner. Als Partner von Park Place Technologies, dem weltgrößten TPM-Anbieter, stellt ProLicense den Kontakt her und ordnet die Hardware-Wartung in die Gesamtstrategie ein. So entsteht ein durchgängiges Drittsupport-Konzept über Software und Hardware.

„Wir denken Software und Hardware zusammen. Raus aus dem teuren Oracle-Support, raus aus der teuren OEM-Wartung, in beiden Fällen ohne Qualitätsverlust. Für die Hardware bringen wir mit Park Place den weltgrößten Anbieter mit an den Tisch“, sagt Markus Oberg, Partner der ProLicense.

Ziel bleibt in jedem Fall dasselbe: minimale Kosten bei voller Compliance. Wer einen TPM-Kostencheck für die eigene Hardware will, erreicht ProLicense über die Kontaktseite oder unter +49 (0) 40-228 6828-0.

Oracle-Datenbanken auf VMware zu betreiben, ist technisch Alltag und lizenzrechtlich eine der teuersten Fallen im Rechenzentrum. Der Grund ist ein Begriff, den viele erst im Audit kennenlernen: Hard Partitioning. Oracle erkennt VMware nicht als Hard Partitioning an, und daraus entsteht ein Risiko, das schnell in die Millionen geht. ProLicense, die unabhängige Lizenzberatung, ordnet die Lage ein.

Hard Partitioning gegen Soft Partitioning

Oracle erkennt nur wenige Technologien als Hard Partitioning an, mit denen sich die lizenzpflichtige Core-Zahl wirksam begrenzen lässt. VMware gehört nicht dazu und gilt für Oracle als Soft Partitioning. Damit greift der Grundsatz: Nicht die tatsächlich genutzten Cores sind lizenzpflichtig, sondern alle, auf denen die Datenbank potenziell laufen könnte. Aus der Frage, wo Oracle läuft, wird die Frage, wohin es laufen könnte. Genau diese Verschiebung treibt die Forderung.

Wie weit die Forderung reicht

Die Reichweite hat sich mit den vSphere-Versionen ausgeweitet. In frühen Versionen endete die Grenze am einzelnen Host, ab vSphere 5.1 zieht Oracle das gesamte vCenter heran, ab Version 6.0 sogar verbundene vCenter. Funktionen wie vMotion, DRS und Storage vMotion vergrößern den Kreis der Hosts, die eine VM erreichen könnte, zusätzlich. Auf einer modernen Umgebung bedeutet das im Extremfall: Ein einziger kleiner Oracle-Server auf einem großen Cluster kann eine Lizenzforderung über Dutzende oder Hunderte Cores auslösen. Genau hier setzen Auditoren an, oft mit Blick in die vCenter-Protokolle.

„Oracle argumentiert mit jedem Host, den eine VM theoretisch erreichen könnte. Aus acht genutzten Cores werden so schnell einhundertzwanzig“, sagt Christian Grave, Geschäftsführer der ProLicense.

Policy ist nicht Vertrag

Der entscheidende Punkt für die Verteidigung: Oracles Haltung zu VMware steht in der Partitioning Policy, einem Positionspapier, nicht im Vertrag. Das Dokument trägt sogar den Hinweis, dass es nicht Vertragsbestandteil werden darf. Maßgeblich ist der Vertrag, und der lizenziert, was installiert und/oder betrieben ist, nicht, was theoretisch laufen könnte. In dieser Lücke zwischen Policy und Vertrag findet jede Verteidigung statt. Wer die Auditklausel und den eigenen Vertrag sauber dagegenhält, muss die überzogene Forderung nicht hinnehmen.

Ändert die neue VMware-Subscription etwas?

Viele hoffen, dass sich mit dem Wechsel von Broadcom auf die VCF-Subscription auch die Oracle-Lage entspannt. Das ist nicht der Fall. Oracles Haltung hat sich nicht bewegt: VMware bleibt Soft Partitioning, ob ein Unternehmen alte Perpetual-Lizenzen nutzt oder das neue VCF-Abo. VMware selbst trifft dazu keine Aussage, aus Broadcoms Sicht ist die Oracle-Lizenzierung allein Sache des Kunden. Einen Segen des Herstellers, der die Forderung entschärft, gibt es nicht. Im Gegenteil verschärft die Umstellung die Lage, denn zu den ohnehin cluster-weiten Oracle-Lizenzen kommen jetzt deutlich höhere VMware-Kosten, zwei Kostenlinien auf derselben Umgebung.

Darin steckt aber auch ein Hebel. Weil das VCF-Abo pro Core große, gemischte Cluster ohnehin teuer macht, lohnt sich die Konsolidierung auf kleine, dedizierte Oracle-Cluster jetzt doppelt. Sie senkt die VMware-Kosten und grenzt zugleich die Oracle-Lizenzbasis ein. Wer seine VMware-Landschaft wegen Broadcom ohnehin umbaut, sollte diesen Moment nutzen, um die Oracle-Umgebung sauber zu isolieren und die Architektur zu dokumentieren.

Wie man das Risiko eingrenzt

Die einzige belastbare Verteidigung ist die Isolation. Oracle-Workloads gehören auf dedizierte Hosts oder einen eigenen Cluster, mit klarer Trennung, unterbundenen Migrationspfaden und eigenem Speicher. Die Architektur wird dokumentiert, denn im Audit zählt der Nachweis, nicht die Zusicherung. Parallel wird die Oracle-Lizenzierung gegen den Vertrag geprüft. Wo es passt, kann eine anerkannte Partitionierung oder der Wechsel auf eine Alternative wie Nutanix mit sauberem Konzept das Risiko dauerhaft senken. ProLicense analysiert die Umgebung und legt den Weg fest, der zur konkreten Situation passt.

„Die Partitioning Policy ist Oracles Position, nicht das Gesetz und nicht der Vertrag. Wir prüfen jede Forderung gegen den Wortlaut des Vertrags und die reale Architektur. Mit sauberer Isolation und der richtigen Dokumentation schrumpft die Forderung oft auf einen Bruchteil“, sagt Sören Reimers, Rechtsanwalt und Geschäftsführer der ProLicense.

Ziel bleibt in jedem Fall dasselbe: minimale Kosten bei voller Compliance. Wer seine Oracle-auf-VMware-Umgebung vor dem nächsten Oracle-Audit prüfen lassen will, erreicht ProLicense unter +49 (0) 40-228 6828-0.