Ein leicht verständlicher Blick darauf, wie Oracle und Larry Ellison durch Datenbanken, Wechselkosten, Lizenzierung und disziplinierten Enterprise-Vertrieb ein dauerhaftes Vermögen aufgebaut haben.
Larry Ellisons Formel für dauerhaftes Vermögen lässt sich so zusammenfassen: Verkaufe eine geschäftskritische Datenbank, binde sie an mehrjährige Verträge und baue eine Enterprise-Sales-Maschine auf, die Verbleiben sicherer erscheinen lässt als Wechseln.
Das ist eine Business-Story darüber, wie Oracle schwer ersetzbar wurde — kein tiefes technisches Tutorial zu Datenbankinternas. Man muss nicht wissen, wie SQL-Optimizer funktionieren, um zu verstehen, warum Oracle jahrzehntelang eine Geldmaschine war.
„Dauerhaft“ heißt nicht, dass Kunden jede Verlängerung liebten. Es heißt, Oracle positionierte sich so, dass Umsätze tendenziell wiederkehrten.
Dauerhaftigkeit zeigt sich als:
Wenn eine Datenbank unter Abrechnung, Inventar, HR oder Handel liegt, ist sie nicht nur ein weiteres IT-Tool. Sie wird zu einer Abhängigkeit — und Abhängigkeiten sind klebrig.
1) Datenbanken als Basis. Oracle konzentrierte sich auf die „system of record“-Schicht — dort, wo die wertvollsten operativen Daten leben.
2) Lock-In (manchmal unbeabsichtigt). Nicht nur technische Kompatibilität, sondern auch Prozesse, Integrationen, Schulungen und anbieter-spezifische Features, die sich über Jahre anhäufen.
3) Enterprise-Vertrieb. Oracle gewann nicht wie eine Consumer-App. Es gewann durch Beschaffungszyklen, Beziehungen auf Führungsebene und Verträge, die darauf ausgelegt sind, die Beziehung zu verlängern.
Zusammen erzeugten diese Säulen einen Zinseszinseffekt: Jeder neue Deal war nicht nur ein einmaliger Verkauf — er erhöhte die Wahrscheinlichkeit vieler künftiger Zahlungen.
Larry Ellison begann nicht als Software-Prominenter. Seine frühe Karriere war eine praktische Mischung aus Programmierjobs und dem Lernen, wie große Organisationen Technologie tatsächlich kaufen — langsam, vorsichtig und mit Vorliebe für Anbieter, die stabil wirken.
Oracle begann 1977 (als Software Development Laboratories) mit einer klaren These: Das größte Geld in Software würde daraus entstehen, Infrastruktur an große Institutionen zu verkaufen, nicht aus einmaligen kundenspezifischen Systemen. Statt frühen Hobbyisten- oder Konsumentenmärkten nachzujagen, zielten Ellison und seine Mitgründer auf Unternehmen und Behörden ab, die Systeme für Lohnabrechnung, Inventar, Abrechnung und Buchhaltung benötigten.
Damals dominierten Mainframes und zentral verwaltete Daten die IT. Selbst als Client-Server-Setups auftauchten, war die Grundannahme in großen Firmen: Systeme müssen zuverlässig, prüfbar und über Jahre unterstützt sein.
Dieses Umfeld belohnte Software, die zum Standardbestandteil werden konnte — etwas, um das IT-Teams herum bauen konnten. Datenbanken passten perfekt: Sie lagen unter vielen Anwendungen, berührten kritische Daten und rechtfertigten fortlaufende Wartung und Support.
Enterprise-Kunden kaufen nicht wie Einzelpersonen. Sie kaufen über Ausschüsse, Beschaffungsprozesse und mehrjährige Pläne. Das zwingt einen Anbieter dazu, zu betonen:
Es verändert auch das finanzielle Profil. Ein einzelner großer Deal kann Jahre der Produktarbeit finanzieren, erfordert aber eine Vertriebsorganisation, die auf Beziehungen, Nachweisen und Risikominimierung aufgebaut ist.
Oracles frühe Wette war simpel: Gewinne einen Platz im Kern der Unternehmensabläufe, und du verkaufst nicht nur Software — du verkaufst Kontinuität durch Updates, Support und Upgrades, die Organisationen weiterbezahlen, während die Abhängigkeit wächst.
Eine Datenbank ist das system of record eines Unternehmens: der Ort, an dem die „offizielle Wahrheit“ liegt. Kundenkonten, Rechnungen, Inventarzahlen, Lohnbuchungen, Versandstatus — das sind keine bloßen Dateien. Es sind Fakten, auf die das Geschäft angewiesen ist, um bezahlt zu werden, konform zu bleiben und täglich zu operieren.
Mit zunehmender Anzahl an Anwendungen — ERP, CRM, Abrechnung, Supply Chain — teilten diese Anwendungen immer häufiger dieselbe zugrundeliegende Wahrheit. Wenn die Datenbank nicht verfügbar ist, können die Anwendungen, die diese Datensätze lesen und schreiben, ihre Arbeit nicht verrichten. Das macht die Datenbank zu einer zentralen Abhängigkeit statt „nur einem Stück IT“.
Datenbanken werden deshalb klebrig, weil Anwendungen um sie herum geschrieben werden. Mit der Zeit sammelt man:
Wechseln ist nicht wie das Austauschen eines Tabellenkalkulationstools. Man muss große Datenmengen migrieren, Historie erhalten, kritische Workflows neu testen und oft Teile der Anwendung neu schreiben. Selbst wenn die neue Option günstiger ist, kann das Projektrisiko die Einsparungen überwiegen.
Bei geschäftskritischen Systemen ist die Angst nicht „diese Woche etwas langsamer“. Es ist ein Ausfall, der die Auftragsbearbeitung stoppt, oder Datenverlust, der Abstimmungen, Rückerstattungen und regulatorische Probleme erzwingt.
Wenn ein schlechter Tag Millionen kosten kann — oder Vertrauen beschädigt — werden Käufer konservativ. „Funktioniert zuverlässig“ schlägt „neu und vielversprechend“.
IT-Abteilungen werden an Stabilität gemessen. Das treibt sie zu Anbietern mit langer Erfolgsbilanz, ausgereiften Tools und Support-Teams, die schon jede Fehlerart gesehen haben.
Ist diese Entscheidung getroffen, wird die Datenbank zum Anker für den Rest des Stacks — sie zieht Anwendungen, Prozesse und Budgets in ihre Umlaufbahn.
Eine relationale Datenbank ist eine Methode, Geschäftsdaten — Kunden, Rechnungen, Sendungen — in Tabellen (denk an Tabellenkalkulationen) zu speichern, die miteinander verknüpft werden können. Statt in Dateien zu suchen, stellt man Fragen wie „zeige mir alle unbezahlten Rechnungen älter als 30 Tage“ und erhält schnell und konsistent eine Antwort.
SQL (Structured Query Language) ist die gebräuchliche Sprache, um mit relationalen Datenbanken zu sprechen. Weil SQL weit verbreitet ist und breit unterstützt wird, liegt die Annahme nahe, Datenbankprodukte seien austauschbar.
Doch in echten Unternehmen zählt nicht nur, ob ein System SQL versteht. Differenzierung zeigt sich in allem drumherum: wie die Datenbank unter hoher Last reagiert, wie sie sich nach einem Absturz erholt, wie Backups funktionieren, wie Berechtigungen verwaltet werden und wie Teams Performance überwachen und optimieren.
Oracle verkaufte nicht „SQL“. Oracle verkaufte das Versprechen, dass geschäftskritische Systeme weiterlaufen würden.
Selbst wenn ein Wettbewerber Features nachbildet, verteilt sich die Entscheidung zur Standardisierung über Teams, Budgets und Jahre betrieblicher Gewohnheiten. Ist eine Datenbank das Zentrum von Reporting, Integrationen und Compliance, reicht „gut genug“ oft nicht, um zu gewinnen.
Marktdominanz reflektiert meist eine Mischung aus Produktqualität, Risikomanagement und Vertriebsausführung — nicht ein einzelnes Killer-Feature.
Oracle wartete nicht darauf, dass Entwickler eine Kreditkarte zückten. Das Unternehmen lernte, wie große Firmen tatsächlich kaufen: langsam, vorsichtig und mit vielen Beteiligten.
Enterprise-Beschaffung ist Mannschaftssport. Ein typischer Deal zieht IT-Leiter, Security, Finanzen, Recht und die Fachabteilung, die das System betreiben wird, heran. Das bedeutet lange Zeiträume, formale Anforderungen und interne Politik.
Oracle nutzte diese Realität mit Proofs of Concept (PoCs), Referenzkunden und detaillierten Kompatibilitätsbehauptungen. Ein PoC ist nicht nur ein technischer Test — er hilft einem Sponsor, den Kauf vor allen anderen zu rechtfertigen.
Oracle etablierte klassisches Account-basiertes Verkaufen: dedizierte Vertriebsmitarbeiter, benannte Accounts und regelmäßige Business-Reviews lange bevor „ABM“ trendy war.
Das Ziel war nicht nur der erste Vertrag; es war, die Standarddatenbank für das nächste Projekt und das danach zu werden. Vertrauen mit einem CIO oder einem DB-Team kann Budgets, Reorganisationen und kurzfristige Produktunzufriedenheit überdauern.
Supportverträge, Zertifizierungen (DBAs, Entwickler) und Systemintegratoren erzeugen Momentum. Hat ein Unternehmen geschultes Personal, genehmigte Architekturen und einen Partner, der Oracle in- und auswendig kennt, fühlt sich ein Anbieterwechsel risikoreich an.
Partner beeinflussen außerdem, was in RFPs empfohlen wird, welche Skills verfügbar sind und welche Plattformen als „sicher“ gelten.
Verlängerungen können wichtiger sein als neue Logos. Wird Oracle in Kernsysteme eingebettet, wird die jährliche Verlängerung zu einer Frage der Geschäftskontinuität, nicht zu einer neuen Beschaffung. Dann formen Preisgestaltung, Audit-Bedingungen und Vertragsstruktur das Verhalten genauso stark wie Produktfunktionen.
(Für die Mechanik dieses Hebels siehe /blog/how-lock-in-works.)
Vendor-Lock-In benötigt keine böse Absicht. Es ist einfach eine wachsende Abhängigkeit von einem Anbieterprodukt kombiniert mit Wechselkosten, die mit der Zeit steigen. Bei einem Kernsystem wie einer Datenbank kann diese Kombination mächtig werden, weil die Datenbank Anwendungen, Reporting, Sicherheit und den Tagesbetrieb unterfüttert.
Technisches Lock-In entsteht, wenn Systeme Fähigkeiten nutzen, die sich nicht leicht anderswo nachbilden lassen. In Datenbanken zeigt sich das oft in proprietären Features (spezielle SQL-Erweiterungen, Performance-Hinweise, Clustering-Ansätze), anbieter-spezifischem Tooling und tief integrierten Verbindungen zu Anwendungen und Middleware.
Selbst wenn „es ist nur SQL“, sammeln produktive Umgebungen Stored Procedures, Trigger, Backup-Skripte, Monitoring-Agenten und benutzerdefinierte Connectoren. Je mehr von diesem Stack auf eine Datenbank abgestimmt ist, desto schwerer wird eine saubere Migration.
Operatives Lock-In betrifft Menschen und Prozesse. Teams werden auf eine Plattform trainiert, stellen Administratoren mit bestimmten Zertifizierungswegen ein und bauen Runbooks, die spezifisches Verhalten beschreiben — wie Failover funktioniert, wie Upgrades ausgeführt werden, was „normale“ Performance ist.
Mit der Zeit werden auch Compliance- und Audit-Dokumente datenbankspezifisch: Zugriffskontrollen, Verschlüsselungskonfigurationen, Aufbewahrungsrichtlinien und Incident-Response-Schritte. Anbieter zu wechseln heißt dann, Personal umzuschulen, Prozesse umzuschreiben und Kontrollen neu zu validieren.
Vertragliches Lock-In verwandelt Wechselkosten in Kalenderrealität. Mehrjahreslaufzeiten, gebündelte Supportstrukturen, Verlängerungszyklen und unternehmensweite Vereinbarungen machen „wir wechseln nächstes Quartal“ unrealistisch.
Support ist ein großer Hebel: Stützen sich kritische Systeme auf Vendor-Support für Patches und Sicherheitsberatung, fühlt sich das Weggehen an wie das Übernehmen neuen operativen Risikos — besonders wenn Verträge strikte Nutzungsdefinitionen und Strafen enthalten, die Teilmigrationen verkomplizieren.
Oracles Burggraben war nicht nur technisch. Er war finanziell — aufgebaut durch Lizenzmodelle, die die Datenbank genauso sehr im Budget wie in den Systemen verankerten.
Oracle-Lizenzen wurden oft in einigen gebräuchlichen Einheiten verkauft:
Die Kernidee ist einfach: Wird die Datenbank zentral, steigt tendenziell einer dieser Zähler — mehr Cores, mehr Nutzer oder mehr Features.
Wenn Preise viele Stellschrauben haben — Metriken, Ausnahmen, Nutzungsrechte, gebündelte Optionen — verlaufen Verhandlungen zugunsten der Partei, die die Regeln am besten kennt.
Komplexität erschwert es Kunden außerdem, die Gesamtkosten über Jahre zu modellieren, was den Vergleich von Alternativen oder eine sichere Migrationsentscheidung schwächt.
Oracle (wie viele große Anbieter) nutzt Lizenzprüfungen, um zu bestätigen, dass Kunden Software innerhalb der Vertragsbedingungen nutzen. Neutral durchgeführt, schützen Audits beide Seiten.
Praktisch erzeugen Audits aber auch finanzielles Risiko: Wird Nutzung als Überdeployment interpretiert, kann der Kunde schnell nachlizenzieren müssen.
Jährliche Supportverlängerungen — oft als Prozentsatz der Lizenz berechnet — schaffen stetige Einnahmen, auch wenn Neugeschäft zurückgeht. Upgrades und neue Editionen sind ein zweiter Hebel: Kunden zahlen, um aktuell, kompatibel und unterstützt zu bleiben, was den wiederkehrenden Zyklus verstärkt.
Oracle hatte nie keine Konkurrenz. Auffällig ist jedoch, wie oft Kunden Alternativen evaluierten — und dann trotzdem verlängerten.
Früher war IBM der offensichtliche Rivale: DB2 lief bereits dort, wo viele Unternehmen ihre wichtigsten Workloads hatten. Oracles Argument war Portabilität und Performance über Hardwareplattformen hinweg, was wichtig wurde, als Firmen sich vom IBM-Mainframe diversifizierten.
In den 1990ern und 2000ern expandierte Microsoft SQL Server schnell, besonders für Abteilungs- und Mittelstands-Systeme, die Einfachheit und geringere Kosten schätzten. Oft war es „gut genug“ — und für viele neue Anwendungen war es das tatsächlich.
Dann wurde Open Source ernstzunehmend: MySQL dominierte Web-Workloads; PostgreSQL wurde zur Wahl für Teams, die Enterprise-Features ohne Enterprise-Lizenz wollten.
Datenbanken werden nicht isoliert gekauft. Sie sind eingebettet in Geschäftsprozesse, Reporting, Sicherheitsprüfungen, Compliance-Freigaben und Lieferantenbeziehungen.
Bei Einsparungen bei Lizenzkosten mag das Ergebnis real sein, doch oft werden diese Einsparungen durch die Kosten für Retests von Anwendungen, Umschulung von Personal und Übernahme operativen Risikos übertroffen. Für viele Firmen ist die Datenbank auch das am wenigsten sichtbare Element, wenn sie funktioniert — und das, was am stärksten beschuldigt wird, wenn sie es nicht tut. Das macht Entscheider konservativ: Sie zahlen lieber mehr, als das Team zu sein, das „die Abrechnung kaputt gemacht hat“.
Datenmigration ist nur der erste Schritt. Stored Procedures, SQL-Dialektunterschiede, Performance-Tuning, Backup/Restore-Routinen, Monitoring, Drittanbieter-Tooling und zertifizierte Anwendungen können alle auf Oracle-spezifischem Verhalten beruhen. Auch Verträge und Audit-Historie schaffen Reibung.
Cloud-Services verwandelten die Datenbank in ein Abo mit weniger Stellschrauben: AWS RDS/Aurora, Azure SQL und Google Cloud SQL (plus Spanner) reduzieren den Bedarf an spezialisiertem DBA-Workload und machen „probier es aus" leichter. Das ist echte Konkurrenz — weniger über Features, mehr über das Senken von Wechselkosten.
Oracles Antwort war, eigene Managed-Angebote voranzutreiben und zu argumentieren, dass der sicherste Ort für Oracle immer noch bei Oracle ist.
Oracle begann als Datenbankfirma, aber große Unternehmen kaufen selten „nur eine Datenbank“. Sie kaufen Systeme, die Finanzen, HR, Vertrieb und Betrieb steuern — und diese Systeme erzeugen beständige Nachfrage für die darunter liegende Datenbankschicht.
Ein gängiges Muster in der Enterprise-Software ist, den Katalog durch Zukäufe etablierter Anwendungsanbieter zu erweitern und dann das breitere Portfolio an dieselben Entscheider zu verkaufen. Anstatt Deal für Deal als Einzelprodukt zu konkurrieren, kann der Anbieter mehrere Module in einer Beschaffung anbieten: ein Set von Verträgen, ein Account-Team und (oft) ein bevorzugter technischer Stack.
Oracle nutzte langfristig Akquisitionen, um in Geschäftsapplikationen wie ERP und CRM vorzudringen, neben Middleware und anderer Infrastruktur. Das garantiert keine nahtlose Integration, verändert aber, wie ein Kunde Anbieter bewertet: „Können wir uns auf einen Anbieter für mehr unserer Kernsysteme standardisieren?“ wird zur realen Frage.
Betreibt ein Unternehmen kritische Anwendungen auf dem Stack eines Anbieters, wird die Datenbank weniger zu einer separaten Kostenstelle und mehr zur eingebetteten Abhängigkeit. Ist eine ERP-Implementierung für Oracle Database ausgelegt, getestet und unterstützt, ist die sicherste Beschaffungswahl oft, bei der gleichen Datenbank zu bleiben.
Diese Dynamik nennt man Pull-Through: Der Verkauf einer Anwendung erhöht die Wahrscheinlichkeit eines Datenbankverkaufs (und von Verlängerungen), weil Zuverlässigkeit, Supportgrenzen und Upgrade-Planung einfacher sind, wenn die Teile zusammenpassen.
Bündelung heißt, mehrere Produkte zusammenzuverpacken — kommerziell oder operativ — sodass der Kauf von mehr beim selben Anbieter leichter erscheint als das Zusammensuchen von Alternativen.
Eine Plattform-Strategie ist die langfristigere Version: gemeinsame Identitätsverwaltung, Monitoring-Tools, Integrations-Connectoren und standardisierte Deployment-Patterns.
Für Käufer ist der Vorteil weniger Anbieter und klarere Verantwortlichkeiten. Der Kompromiss ist, dass jede zusätzliche Schicht die Wechselkosten später erhöhen kann, weil Datenbank, Middleware und Anwendungen als ein verbundenes System funktionieren.
Jahrzehntelang florierte Oracle mit einem einfachen Muster: Verkauf einer hohen Einmallizenz, dann jährlicher Support. Der Wandel zur Cloud bedrohte diesen Rhythmus. Kunden konnten statt einer Perpetual-Software nun Infrastruktur und Managed-Datenbanken mieten — oft mit schnellerer Beschaffung, leichterer Skalierung und klareren monatlichen Kosten.
Cloud-Plattformen veränderten, wer die Kontrolle über die Betriebsumgebung hat. Läuft die Datenbank auf fremder Infrastruktur — und konkurrierende Datenbanken sind mit einem Klick verfügbar — können Preisgestaltungsmacht und Erneuerungshebel schwächer werden.
Cloud-Einführung veranlasste Finanzteams außerdem, zu abonnementbasierten Ausgaben zu tendieren, wodurch große Lizenzdeals schwerer zu rechtfertigen sind.
Oracle verfolgte zwei parallele Wege:
Für Käufer können Managed-Datenbanken attraktiv sein: Patching und Backups sind automatisiert, Hochverfügbarkeit leichter zu implementieren und Kapazität skaliert ohne langen Hardware-Zyklus.
Selbst wenn sich die Lizenzökonomie Richtung Abo verschiebt, kann der Trade-off sinnvoll sein, wenn es Ausfallrisiken reduziert und interne Teams entlastet.
Wenige große Firmen migrieren alles auf einen Schlag. Es ist üblich, kritische Oracle-Workloads jahrelang On-Prem zu betreiben, während neue Systeme in der Cloud entstehen — manchmal in OCI, manchmal in anderen Clouds und oft mit Integrations-Klebstoff dazwischen.
Oracles Ziel in dieser gemischten Welt ist einfach: Überall dort, wo der Kunde läuft, die Standarddatenbank zu bleiben.
Lock-In ist nicht immer eine Falle, die ein Anbieter stellt; oft ist es eine Nebenwirkung sinnvoller Entscheidungen unter Zeitdruck. Das Ziel ist nicht „niemals verpflichten“ — sondern sich bewusst zu verpflichten und einen Ausstiegsplan zu haben, den man sich leisten kann.
Vor der Unterschrift eine kurze „zukünftige Migration“-Übung machen und sie wie ein echtes Projekt kalkulieren.
Kleine Vertragsklauseln können große Wechselkosten erzeugen.
Achten Sie besonders auf Verlängerungsbedingungen, Support-Preiserhöhungen und Audit-Sprache (was ein Audit auslöst, Fristen und wie Nutzung gemessen wird). Vergewissern Sie sich außerdem, dass Ihr Deployment-Modell — Virtualisierung, Container, DR und Dev/Test — mit den Vertragsdefinitionen übereinstimmt.
Nutzen Sie Benchmarking, um Alternativen auf gleichen Workloads zu vergleichen, nicht nur Marketingzahlen. Rechtsgröße Lizenzen auf aktuellen Bedarf und nahe Wachstumsszenarien statt auf Worst-Case-Projektionen.
Fordern Sie Nutzungs-Transparenz: klare Metriken, Zugriff auf Reporting und das Recht auf Eigenprüfungen.
Wenn Sie Hilfe bei der Kostenprognose brauchen, stimmen Sie das mit Ihrer gesamten Lieferanten-Ausgabenplanung und internen Verrechnungen ab (siehe /pricing).
Eine zeitgemäße Wendung ist, dass Teams Abhängigkeiten schneller als je zuvor aufbauen können. Plattformen für schnelles Entwickeln wie Koder.ai erlauben es, Web-Apps (React), Backends (Go + PostgreSQL) und Mobile-Apps (Flutter) aus einem einfachen Chat-Interface in Tagen statt Monaten hochzufahren.
Diese Geschwindigkeit ist mächtig, aber das gleiche Prinzip gilt: Entscheiden Sie im Voraus, was Sie flexibel hält. Praktische Anti-Accidental-Lock-In-Features sind Source-Code-Export, Snapshots und Rollbacks sowie vorhersehbare Deployment/Hosting-Optionen. (Koder.ai unterstützt all das und bietet außerdem einen Planungsmodus, um Anforderungen zu kartieren, bevor Sie eine große Codebasis generieren.)
Oracles Geschichte ist nicht nur „verkaufe Software an große Firmen“. Sie ist eine Fallstudie darin, wie ein Produkt ein permanenter Teil einer Organisation wird — und wie diese Permanenz zu dauerhaft stabiler Ökonomie wird.
Oracle gewann nicht, indem es nett-zu-haben war. Die Datenbank wurde der Ort, an dem kritische Daten lagen, und das Geschäft formte sich um diese Realität.
Wenn Sie ein Enterprise-Unternehmen bauen, suchen Sie nach Wedges, die:
Die Vorsicht ist wichtig: Je zentraler Sie sind, desto mehr Vertrauen müssen Sie verdienen. Fühlen sich Kunden gefangen, ohne fortlaufenden Wert zu erhalten, werden sie Sie früher oder später herausdesignen.
Oracle zeigt, dass großartige Enterprise-Geschäfte häufig Erneuerungsmaschinen sind, nicht permanente „New-Logo“-Maschinen. Hohe Wechselkosten können Umsätze stabilisieren, aber das beste Signal ist, ob Kunden auch dann verlängern, wenn sie Alternativen haben.
Achten Sie auf:
Lock-In ist nicht nur technisch — es ist operativ und vertraglich. Der Zeitpunkt, Flexibilität auszuhandeln, ist bevor Sie abhängig sind.
Praktische Schritte:
Oracle lieferte echten Wert: Zuverlässigkeit, Performance und einen Standardweg, ernste Geschäfte zu betreiben. Die Kosten zeigen sich, wenn Abhängigkeit Verhandlungsmacht einschränkt oder Veränderungen verlangsamt.
Die moderne Lektion ist, unverzichtbar zu werden, indem man es sich kontinuierlich verdient — und den Kunden gleichzeitig einen realistischen Weg zur Weiterentwicklung lässt. So entstehen langfristige Beziehungen ohne langfristiges Ressentiment.
"Dauerhaft" bedeutet, dass das Geschäftsmodell so gestaltet ist, dass Einnahmen zuverlässig wiederkehren — auch wenn Kunden bei Verlängerungen nicht immer begeistert sind.
Im Fall von Oracle entstand Dauerhaftigkeit durch:
Weil die Datenbank unter den Systemen liegt, die das Geschäft am Laufen halten: Abrechnung, Gehaltsabrechnung, Inventar, Handel, Compliance-Reporting.
Wenn die Datenbank das system of record ist, führen Ausfälle oder Datenverluste zu existenziellen betrieblichen und regulatorischen Risiken — deshalb priorisieren Käufer Stabilität und erprobten Support gegenüber Neuheiten.
Nicht wirklich. SQL ist ein Standard, aber Unternehmen kaufen keine „Syntax“, sie kaufen Ergebnisse: Verfügbarkeit, Wiederherstellung, Performance unter Last, Sicherheitskontrollen, Tooling und Support.
Zwei Produkte können „SQL sprechen“ und sich trotzdem deutlich unterscheiden bei:
Wechselkosten akkumulieren über die Zeit.
Häufige Quellen dafür sind:
Selbst wenn eine Alternative günstiger ist, kann das Migrationsrisiko die Einsparung übersteigen.
Oracle verkaufte an Komitees und in langen Beschaffungszyklen und behandelte Accounts als langfristige Beziehungen.
Typische Taktiken waren:
Oft ist der Erneuerungszeitpunkt dort, wo die Verhandlungsposition am größten ist.
Stützt eine Datenbank Kernprozesse, wird die Verlängerung zur Business-Continuity-Entscheidung, nicht zu einer Neubewertung. Das verwandelt die Frage „Sollen wir kaufen?“ in „Können wir sicher wechseln?“, was deutlich schwieriger ist.
Hier wirken Preisgestaltung, Audit-Klauseln und Support-Policies besonders stark.
Drei Schichten verstärken sich häufig gegenseitig:
Zusammen formen sie die Mechanik des Lock-Ins.
Oracle-Lizenzmodelle haben oft mehrere „Zähler“, und Wachstum erhöht in der Regel mindestens einen davon.
Häufige Hebel sind:
In der Praxis erschwert Komplexität die Langfristprognose der Kosten und erhöht das Risiko unbeabsichtigter Nichtkonformität.
Eine Prüfung (License Review) ist ein Abgleich gegen die Vertragsbedingungen, um Nutzung und Kauf abzugleichen.
Praktisch kann sie bewirken:
Teams reduzieren Risiko durch Deployment-Tracking, Verständnis von Metrik-Definitionen (Virtualisierung, DR, Dev/Test) und klare interne Nutzungsberichte.
Nicht automatisch — die Cloud verändert die Form des Lock-Ins, eliminiert ihn aber nicht.
Managed Services reduzieren die operative Belastung (Patching, Backups, HA), doch man muss weiterhin auf Folgendes achten:
Viele Unternehmen leben jahrelang hybrid und mischen On-Prem-Oracle mit Cloud-Services, während sie versuchen, Exit-Optionen realistisch zu halten.
