Firma migriert SQL Server Workload von On-Premise zu AWS. “Wir haben bereits Lizenzen, wir verschieben sie einfach.” Einen Monat später die Rechnung von AWS: volle SQL Server Lizenzkosten in EC2 - plus die On-Premise Lizenzkosten die sie weiter zahlen (Maintenance). Doppelte Zahlung. Oder: Sie hätten BYOL nutzen und nur für Infrastruktur zahlen können.
Cloud-Migration verändert die Software-Lizenzökonomie. On-Premise: Sie kaufen einmal eine Lizenz (perpetual) oder zahlen Subscription, hosten auf eigener Hardware. Cloud: oft ist Lizenzierung in Servicekosten eingebaut (License-Included) - aber das kann teurer sein als BYOL (Bring Your Own License).
Ohne Lizenzplanung kann Migration deutlich mehr kosten als erwartet. Mit guter Planung - kann es eine Gelegenheit zur Optimierung und Einsparung sein.
Was sind die grundlegenden Software-Lizenzmodelle in der Cloud?
License-Included (LI): Cloud-Provider liefert Software mit inkludierter Lizenz. Sie zahlen pro Stunde/Monat Nutzung. Einfaches Modell, keine eigenen Lizenzen zu verwalten. Aber: oft langfristig teurer.
Bring Your Own License (BYOL): Sie haben eigene Lizenzen (perpetual oder Subscription), nutzen sie in der Cloud statt beim Cloud-Provider für Lizenz zu zahlen. Niedrigere Cloud-Kosten (nur Infrastruktur), aber Sie müssen Lizenzen mit entsprechenden Rechten haben.
Subscription vom Cloud-Provider: Sie kaufen Subscription direkt vom Vendor, aber Bereitstellung ist über Cloud. Z.B. Microsoft 365 (Subscription von Microsoft, genutzt mit Azure/überall).
Cloud-native Pricing: Software hat dediziertes Pricing für Cloud, anders als On-Premise. Z.B. Oracle Database in Oracle Cloud vs. On-Premise Licensing sind unterschiedliche Modelle.
Wann macht BYOL Sinn vs. License-Included?
BYOL macht Sinn wenn:
- Sie bestehende Lizenzen mit Software Assurance / aktivem Maintenance haben
- Langfristige Nutzung (3+ Jahre)
- Hohe Auslastung (24/7 Workloads)
- Sie Mobility-Rechte haben (Lizenzbedingungen prüfen)
License-Included macht Sinn wenn:
- Kurzfristige / variable Workloads
- Sie keine bestehenden Lizenzen haben
- Test- / Dev-Umgebungen
- Sie Einfachheit wollen (All-in-One Abrechnung)
Break-even Analyse: Vergleichen: (License-Included Stundensatz × geschätzte Stunden) vs. (BYOL Infrastruktur-Rate × Stunden + Lizenzkosten amortisiert)
Beispiel:
- SQL Server License-Included auf AWS EC2: $1.50/h
- BYOL Infrastruktur: $0.50/h + SQL Server Lizenz ($10.000/Jahr amortisiert)
- Bei 8760h/Jahr: LI = $13.140, BYOL = $4.380 + $10.000 = $14.380 → LI leicht besser
- Aber: mit Software Assurance die Sie bereits bezahlt haben → BYOL ist $4.380 total → viel besser
Wie funktioniert Microsoft-Lizenzierung in Azure vs. AWS vs. GCP?
Azure Hybrid Benefit (AHB): Haben Sie Windows Server oder SQL Server mit Software Assurance? Sie können Lizenzen in Azure ohne zusätzliche Lizenzkosten nutzen - Sie zahlen nur für Compute.
Einsparungen: bis zu 85% für SQL Server, bis zu 40% für Windows Server.
AWS: BYOL möglich für Windows/SQL Server, erfordert aber Dedicated Hosts oder Dedicated Instances. Nicht so einfach wie Azure Hybrid Benefit. License Mobility für einige Microsoft-Produkte.
GCP: Ähnlich - BYOL erfordert Sole-Tenant Nodes. Google bietet auch Cloud SQL mit License-Included.
Microsofts “Azure preferred”: Microsoft gibt bessere Konditionen für Azure als konkurrierende Clouds. Azure Hybrid Benefit ist großzügig, BYOL zu anderen Clouds hat mehr Einschränkungen.
Wie funktioniert Oracle-Lizenzierung in der Cloud - und warum ist es eine Falle?
Oracle-Lizenzierung in der Cloud ist notorisch kompliziert und oft teurer als On-Premise.
Oracle Cloud Infrastructure (OCI): Lizenzierung per OCPU (Oracle Compute Unit). BYOL möglich. Oracle bietet “Rabatte” um zu OCI zu locken.
Oracle auf AWS/Azure/GCP: Oracle verlangt Lizenzierung per vCPU mit spezifiziertem Multiplikator (2 vCPU = 1 Oracle Prozessor). Aber Vorsicht: einige Instance-Typen erfordern mehr Lizenzen als erwartet.
AWS Dedicated Hosts: BYOL für Oracle erfordert Dedicated Hosts (teurer als Shared). Lizenz-Audits können BYOL hinterfragen, wenn nicht auf Dedicated.
Oracle autorisierte Cloud-Umgebungen: Oracle hat eine Liste “autorisierter Clouds”, wo BYOL einfacher ist. AWS, Azure, GCP sind autorisiert, aber Regeln sind detailliert.
Risiko: Ohne sorgfältige Analyse kann Oracle auf AWS 2-3x mehr kosten als On-Premise durch Lizenzierungskomplikationen.
Was sind Mobility-Rechte und wie verifiziert man sie?
License Mobility through Software Assurance (Microsoft): Sie haben Microsoft-Lizenzen mit aktivem SA → Sie können zu “Shared Servers” in autorisierter Cloud verschieben. Aber: erfordert Formular zum Ausfüllen, Cloud-Provider muss auf der Liste sein.
Oracle Mobility: Begrenzt. BYOL hauptsächlich zu OCI. Zu anderen Clouds - spezifische Bedingungen, erfordert oft Dedicated Hosts.
SAP-Lizenzierung in Cloud: SAP erlaubt BYOL zu zertifizierten Cloud-Providern. Erfordert: Erklärung, entsprechender Lizenztyp, Nutzungsmonitoring.
VMware in Cloud: VMware Cloud on AWS, Azure VMware Solution - nutzen Sie Ihre Lizenzen oder kaufen Sie über Cloud. Spezifische Mobility-Programme.
Wie verifizieren:
- License Agreement prüfen - hat es Mobility-Rechte
- Software Assurance Status prüfen (Microsoft)
- Cloud-Provider auf autorisierter Liste prüfen
- Deployment dokumentieren - Audits können Nachweise fordern
Wie plant man Lizenzmigration Schritt für Schritt?
Schritt 1: Inventar Liste aller Software die migriert wird. Welche Lizenzen Sie haben, welche Entitlements, welcher SA/Maintenance-Status.
Schritt 2: Zielarchitektur Wie wird Software in Cloud deployed? Instance-Größen, Regionen, Availability Zones. Das beeinflusst Lizenzierung.
Schritt 3: Lizenzierungsoptionen-Analyse Für jede Software: BYOL möglich? License-Included verfügbar? Bedingungen, Einschränkungen, Kosten.
Schritt 4: Kostenvergleich Vergleichen: aktuelle On-Prem Lizenzkosten + neue Cloud-Infrastrukturkosten + zusätzliche Cloud-Lizenzkosten. Vs. License-Included Gesamtkosten. Vs. neuverhandelte Cloud-native Lizenzierung.
Schritt 5: Rechte-Verifikation Prüfen dass Sie Rechte für BYOL haben. Erforderliche Formulare ausfüllen. Vendors benachrichtigen.
Schritt 6: Vendor-Verhandlung Migration ist Gelegenheit zur Neuverhandlung. “Wir migrieren zu Azure, wir wollen bessere Azure-Konditionen.” Vendors wollen Cloud-Geschäft.
Schritt 7: Implementierung mit Lizenz-Tracking Mit entsprechendem Tagging für Lizenz-Tracking deployen. Nutzung vs. Entitlements monitoren.
Schritt 8: Post-Migrations-Audit Prüfen dass tatsächliches Deployment = geplant. Werden Lizenzen korrekt verwendet?
Was sind häufige Fehler und wie vermeidet man sie?
Annehmen dass BYOL automatisch ist. Ist es nicht. Erfordert: entsprechende Rechte, entsprechendes Deployment (Dedicated Hosts für einige), Dokumentation.
Cloud-Provider-Lizenzierung ignorieren. AWS Marketplace, Azure Marketplace haben Software mit eigener Lizenzierung. Sicherstellen dass Sie das Modell vor Kauf verstehen.
Maintenance/Support vergessen. BYOL ist die Lizenz, aber Support kann separat sein. On-Prem Support-Vertrag deckt möglicherweise Cloud-Deployment nicht ab. Prüfen!
Cloud-native Alternativen nicht erwägen. Statt SQL Server in EC2 - vielleicht Aurora (AWS Cloud-native)? Statt Oracle - vielleicht PostgreSQL? Migration ist Gelegenheit für Wechsel.
Oracle-Komplexität unterschätzen. Oracle in Nicht-Oracle-Cloud ist ein Lizenzierungsminenfeld. Expertenrat empfohlen.
Kein Tagging für Lizenz-Tracking. Cloud-Ressourcen ohne Tags = schwer mit Lizenzen abzugleichen. Alles taggen: Produkt, Version, Lizenztyp.
Wie verhandelt man mit Vendors bei der Migration?
Migrationsmoment nutzen: “Wir migrieren einen großen Teil der Workloads in die Cloud. Wir möchten über Cloud-freundliche Lizenzierung sprechen.” Vendor weiß dass er Geschäft an Cloud-native Alternativen verlieren könnte.
Konsolidieren und verhandeln: Haben Sie Lizenzen bei Microsoft, Oracle, SAP? Während der Migration mit allen sprechen. Vielleicht gibt einer ein besseres Angebot für größeren Anteil.
Nach Migrations-Incentives fragen: Microsoft, Oracle, SAP haben Programme die Migration zu ihren Clouds fördern. Azure Migrate Credits, Oracle Cloud Migration Support.
Laufzeit-Angleichung erwägen: Lizenzen verlängern sich zu verschiedenen Zeiten? Migration ist Gelegenheit für angeglichene Laufzeiten (eine Vendor-Verhandlung pro Jahr, nicht vier).
Benchmark-Daten holen: Was zahlen andere für ähnliche Migration? Berater, Gartner, Peer-Netzwerke nutzen.
Tabelle: Lizenzierungsüberlegungen nach Hauptvendor in Cloud
| Vendor | BYOL Optionen | Beste Cloud für BYOL | Wichtige Überlegungen | Fallstricke |
|---|---|---|---|---|
| Microsoft (Windows Server) | Ja mit SA | Azure (Hybrid Benefit) | 40% Einsparung möglich, einfacher Prozess | AWS/GCP erfordern Dedicated Hosts |
| Microsoft (SQL Server) | Ja mit SA | Azure (Hybrid Benefit) | Bis zu 85% Einsparung | Core-Zählung, Edition-Matching |
| Oracle Database | Begrenzt | OCI bevorzugt | Prozessor-Zählregeln komplex | Nicht-OCI Clouds sehr teuer |
| SAP | Ja mit Bedingungen | Alle großen Clouds zertifiziert | Erfordert Erklärung, richtiger Lizenztyp | Named User vs. Engine Licensing |
| VMware | Über VMware Cloud Programme | AWS, Azure VMware Solution | Subscription oder BYOL | vCPU-Zählung für Lizenzierung |
| Red Hat | Ja | Alle Clouds | Einfaches BYOL, auch Cloud Marketplace | Support-Kontinuität sicherstellen |
Cloud-Migration ohne Lizenzplanung ist ein Rezept für Kostenüberschreitungen. Mit guter Planung, BYOL und Vendor-Verhandlungen - ist es eine Optimierungsgelegenheit. Der Unterschied kann 30-50% der Gesamtkosten sein.
Wichtige Erkenntnisse:
- BYOL kann Cloud-Kosten signifikant reduzieren - erfordert aber entsprechende Rechte
- Azure Hybrid Benefit ist großzügig für Microsoft-Workloads
- Oracle in Nicht-Oracle-Cloud ist teuer - sorgfältig planen
- License Mobility erfordert Verifikation und Dokumentation
- Migration ist Verhandlungsgelegenheit - Vendors wollen Cloud-Geschäft
- Lizenzen in Cloud durch Tagging tracken - Audits sind weiterhin real
- Cloud-native Alternativen erwägen - nicht alles muss Lift-and-Shift sein
Lizenzexpertise früh in der Migrationsplanung einbeziehen. Es ist eine Investition die sich mehrfach auszahlt.
ARDURA Consulting bietet umfassende Software Asset Management-Unterstützung bei Cloud-Migrationen. Wir helfen bei Lizenzplanung, verhandeln mit Vendors und optimieren Software-Kosten in der Cloud. Kontaktieren Sie uns vor Beginn Ihrer Migration.