Inhaltsverzeichnis
- Die Broadcom-Übernahme und was sie VMware-Kunden kostet
- Proxmox VE als Alternative — was es kann (und was nicht)
- Feature-Vergleich: Proxmox vs. VMware
- Was eine Migration realistisch kostet und wie lange sie dauert
- Migrationsablauf in 6 Schritten
- Für wen sich der Wechsel lohnt — und für wen (noch) nicht
- Häufige Fragen
Die Broadcom-Übernahme und was sie VMware-Kunden kostet
Seit Broadcom VMware übernommen hat, ist für viele langjährige Kunden nichts mehr, wie es war. Der Konzern hat das Lizenzmodell in kurzer Zeit grundlegend umgebaut — und die Auswirkungen treffen kleine und mittlere Unternehmen mit voller Wucht.
Die zentralen Änderungen im Überblick:
- Ende der Perpetual-Lizenzen: VMware wird ausschließlich im Abo-Modell verkauft. Die klassischen unbefristeten Kauflizenzen, die viele Unternehmen einmal erworben und über Jahre genutzt haben, wurden gestrichen. Wer weiter Updates und Support will, muss ins Abo wechseln.
- Drastische SKU-Reduktion: Das früher extrem granulare Produktportfolio mit rund 8.000 einzeln bestellbaren Artikeln wurde auf wenige gebündelte Pakete zusammengestrichen. Wer nur einen Teil der Funktionen brauchte, zahlt nun oft für ein großes Bundle mit.
- Verlagerung auf Subskription pro Kern: Die Abrechnung erfolgt in vielen Fällen pro CPU-Kern statt pro Sockel, teils mit Mindestabnahmen. Gerade bei modernen Servern mit hoher Kernzahl summiert sich das erheblich.
In Summe berichten zahlreiche Kunden seither von Preissteigerungen, die je nach Ausgangslage und Konfiguration zwischen etwa 300 und 1.500 Prozent liegen sollen. Diese Spanne ist als von Kunden und Branchenmedien berichtet zu verstehen, nicht als offizielle Herstellerangabe — die tatsächliche Steigerung hängt stark davon ab, welches alte Lizenzmodell mit welchem neuen Bundle verglichen wird.
Der Effekt ist dennoch eindeutig: Ein Setup, das gestern noch mit einer einmaligen Investition und moderaten Wartungsgebühren lief, wird über die Abo-Laufzeit für viele KMU zu einem der teuersten Posten in der IT-Infrastruktur. Und genau das setzt eine Neubewertung in Gang, die vor der Übernahme kaum jemand geführt hätte.
Besonders unangenehm ist die Planbarkeit. Ein Abo-Modell verlagert die Kosten von einer einmaligen, kalkulierbaren Investition zu einer wiederkehrenden Verpflichtung, deren künftige Höhe der Kunde nicht selbst in der Hand hat. Wer heute unterschreibt, weiß nicht, wie sich der Preis bei der nächsten Verlängerung entwickelt. Für ein mittelständisches Unternehmen mit einem festen IT-Budget ist genau diese Unsicherheit oft ein größeres Problem als der absolute Betrag — sie erschwert die mehrjährige Finanzplanung und bindet Kapital, das an anderer Stelle fehlt.
Hinzu kommt ein psychologischer Faktor: Viele IT-Verantwortliche empfinden das neue Modell als Bruch eines jahrelangen Vertrauensverhältnisses. Wer über ein Jahrzehnt in eine Plattform investiert, sie dokumentiert und Personal darauf geschult hat, reagiert sensibel auf abrupte Änderungen der Geschäftsgrundlage. Das erklärt, warum die Wechselbereitschaft aktuell so hoch ist wie nie — es geht nicht nur um Geld, sondern um Kontrolle über die eigene Infrastruktur.
Auch Analysten haben diese Bewegung erfasst. Gartner prognostiziert, dass bis 2028 rund 70 Prozent der VMware-Kunden mindestens die Hälfte ihrer Workloads auf alternative Plattformen verlagern werden. Der Markt ist also in Bewegung — die Frage ist für viele Unternehmen nicht mehr ob, sondern wann und wohin.
Proxmox VE als Alternative — was es kann (und was nicht)
Proxmox VE (Virtual Environment) ist eine Open-Source-Virtualisierungsplattform der österreichischen Proxmox Server Solutions GmbH. Sie kombiniert zwei bewährte Linux-Technologien unter einer gemeinsamen Verwaltungsoberfläche: den KVM-Hypervisor für vollwertige virtuelle Maschinen und LXC für leichtgewichtige Container.
Die wichtigsten Stärken für den Mittelstand:
- Keine Lizenzkosten-Zwang: Proxmox VE ist quelloffen und kann kostenlos betrieben werden. Ein kommerzielles Support-Abo pro CPU-Sockel ist optional und öffnet den Zugang zum stabilen Enterprise-Repository sowie zum Herstellersupport.
- Bewährter Unterbau: KVM und LXC laufen seit vielen Jahren in großen Produktivumgebungen. Proxmox setzt keine exotische Technologie ein, sondern bündelt etablierte Bausteine sauber zusammen.
- Vollständige Web-UI und API: Cluster, VMs, Container, Storage und Backup werden über eine integrierte Weboberfläche verwaltet. Für Automatisierung stehen eine REST-API und CLI-Werkzeuge bereit.
- Integrierte Kernfunktionen: Hochverfügbarkeit, Live-Migration, Snapshots, Backup und mit Ceph eine verteilte Storage-Lösung sind ohne Zusatzlizenzen an Bord.
Ehrlicherweise gehört auch die andere Seite dazu: Das Ökosystem rund um Proxmox ist schlanker als das rund um VMware. Bestimmte Enterprise-Integrationen — etwa tief in vSphere verzahnte Storage-Appliances, spezialisierte Drittanbieter-Backup-Suiten oder fertige Konnektoren mancher Softwarehersteller — sind für Proxmox teils nicht oder nur mit Mehraufwand verfügbar. Wer solche Spezialbausteine im Einsatz hat, muss deren Proxmox-Tauglichkeit vorab konkret prüfen. Für die typische KMU-Landschaft aus Datei-, Datenbank- und Applikationsservern sowie Windows-VMs ist Proxmox jedoch ausgereift und produktionstauglich.
Ein weiterer praktischer Vorteil: Proxmox stellt keine besonderen Anforderungen an die Hardware. Die Plattform läuft auf handelsüblichen x86-Servern und macht Sie unabhängig von einer eng definierten Kompatibilitätsliste. Das senkt nicht nur die Anschaffungskosten für das Ziel-Cluster, sondern erlaubt in vielen Fällen, vorhandene Server nach der Migration weiterzuverwenden, statt sie im Zuge eines Lizenzwechsels vorzeitig auszutauschen.
Aus eigener Erfahrung: Bei Koreva läuft Proxmox produktiv — unter anderem als Basis für unsere GPU-Infrastruktur, auf der wir KI-Workloads lokal betreiben. Wir kennen die Plattform also nicht nur aus Kundenprojekten, sondern aus dem eigenen Tagesbetrieb, inklusive der Punkte, an denen man in der Praxis genauer hinschauen muss — etwa beim Zusammenspiel von Ceph mit dem Netzwerk oder beim Feintuning von Backups. Diese Praxis fließt direkt in unsere Virtualisierungsprojekte ein.
Feature-Vergleich: Proxmox vs. VMware
Der folgende Vergleich stellt die für KMU relevanten Kernbereiche gegenüber. Er soll keine vollständige Feature-Matrix ersetzen, sondern die Entscheidungsfrage beantworten: Deckt Proxmox das ab, worauf es im Alltag ankommt?
| Bereich | Proxmox VE | VMware vSphere |
|---|---|---|
| HA / Hochverfügbarkeit | Integriert im Cluster, ohne Zusatzlizenz | vSphere HA, je nach Edition im Bundle |
| Live-Migration | Laufende VMs zwischen Knoten verschiebbar | vMotion, etabliert und ausgereift |
| Backup | Integriert; Proxmox Backup Server (dedupliziert, inkrementell) | Über vendor- oder Drittanbieter-Lösungen |
| Storage / Ceph | Ceph nativ integriert; ZFS, LVM, NFS, iSCSI | vSAN und breites Storage-Ökosystem |
| Support-Modell | Optionales Abo pro Sockel; Community + Enterprise | Support an Abo-Lizenz gebunden |
| Lizenzkosten | Kostenlos nutzbar; Support optional | Verpflichtendes Abo, pro Kern |
Der Vergleich zeigt: In den entscheidenden Kernfunktionen — Hochverfügbarkeit, Live-Migration, Backup und verteiltem Storage — ist Proxmox voll konkurrenzfähig. Der Unterschied liegt weniger in „kann es das?“ als in der Breite des kommerziellen Ökosystems und der Zahl fertiger Enterprise-Integrationen. Für den Mittelstand ist das in der Praxis selten der ausschlaggebende Faktor.
Was eine Migration realistisch kostet und wie lange sie dauert
Die ehrlichste Antwort vorweg: Das hängt von Ihrer Umgebung ab. Trotzdem lassen sich belastbare Faustwerte nennen, an denen sich eine erste Planung ausrichten kann.
Für die Dauer gilt als Orientierung: Eine Umgebung mit 50 bis 200 virtuellen Maschinen ist bei strukturierter Planung in etwa 8 bis 12 Wochen migriert. Kleinere Umgebungen mit einer Handvoll VMs sind oft in wenigen Tagen umgezogen; große, stark verzahnte Landschaften mit vielen Abhängigkeiten und Compliance-Anforderungen brauchen länger.
Wichtig ist, wo die Zeit tatsächlich hingeht. Das reine Umkopieren der VM-Datenträger ist meist der kleinere Anteil. Den Löwenanteil verschlingen:
- Ist-Aufnahme und Dokumentation der bestehenden Umgebung
- Design und Aufbau des Ziel-Clusters inklusive Storage- und Netzwerkkonzept
- Testläufe, um Kompatibilität von Betriebssystemen, Treibern und Anwendungen sicherzustellen
- Validierung nach jeder Migrationswelle und die Übergabe an den Betrieb
Die Kostenfaktoren lassen sich klar benennen, auch wenn die absoluten Beträge individuell sind: erstens die eingesparten VMware-Abo-Kosten (der eigentliche Treiber des Wechsels), zweitens gegebenenfalls neue oder umgewidmete Hardware für das Ziel-Cluster, drittens der einmalige Projektaufwand für Planung und Durchführung, viertens optional ein Proxmox-Support-Abo für den laufenden Betrieb. Konkrete Euro-Beträge lassen sich seriös erst nach der Ist-Aufnahme kalkulieren — jede Zahl ohne Kenntnis von Kernanzahl, Cluster-Größe und Storage-Konzept wäre geraten.
Zum Einsparpotenzial kursieren in der DACH-Region einzelne Berichte von rund 83 Prozent niedrigeren Kosten nach dem Wechsel. Solche Zahlen sind als berichtete Einzelfälle einzuordnen und nicht auf jede Umgebung übertragbar; sie hängen massiv von der vorherigen VMware-Konfiguration ab. Realistisch ist: Der Wegfall der obligatorischen Abo-Lizenzen ist bei den meisten KMU der größte Kostenhebel.
Migrationsablauf in 6 Schritten
Eine strukturierte Migration folgt einem klaren, wiederholbaren Muster. So sieht der bewährte Ablauf aus:
- Ist-Aufnahme: Vollständige Inventarisierung der bestehenden VMware-Umgebung — VMs, Ressourcen, Betriebssysteme, Anwendungen, Abhängigkeiten, Storage- und Netzwerktopologie sowie eingesetzte Drittanbieter-Werkzeuge (etwa Backup). Hier entscheidet sich, welche Systeme problemlos umziehen und wo Sonderfälle lauern.
- Ziel-Cluster planen: Design des Proxmox-Clusters — Anzahl der Knoten, Storage-Konzept (Ceph, ZFS, NFS), Netzwerksegmentierung, HA-Auslegung und Backup-Strategie. Idealerweise wird das Ziel-Cluster parallel zur bestehenden Umgebung aufgebaut, sodass der Betrieb nicht angetastet wird.
- Test-VM: Eine repräsentative, unkritische VM wird zuerst migriert und ausführlich getestet. So werden Treiberfragen, Boot-Verhalten und Performance geklärt, bevor produktive Systeme angefasst werden.
- Migration in Wellen: Die restlichen VMs werden in Gruppen umgezogen — geordnet nach Abhängigkeiten und Kritikalität. Weniger kritische Systeme zuerst, unternehmenskritische zum Schluss in geplanten Wartungsfenstern. Jede Welle wird abgeschlossen und stabilisiert, bevor die nächste beginnt.
- Validierung: Nach jeder Welle wird geprüft: Laufen die Anwendungen? Stimmen Performance und Erreichbarkeit? Funktionieren Backups und HA im Ernstfall? Erst nach bestandener Validierung gilt eine Welle als fertig.
- Übergabe und Dokumentation: Zum Abschluss stehen eine vollständige Dokumentation der neuen Umgebung, eine Einweisung des Betriebsteams und die Festlegung von Backup- und Monitoring-Routinen. Erst danach wird die alte VMware-Umgebung endgültig stillgelegt.
Dieser Wellen-Ansatz ist der Grund, warum eine Migration den laufenden Betrieb kaum stört. Weil eine saubere Backup-Strategie und eine Rückfall-Option Teil der Planung sind, lässt sich bei Problemen jederzeit auf die alte Umgebung zurückschalten. Diese Absicherung gehört genauso in den Plan wie ein durchdachter IT-Notfallplan, der beschreibt, was passiert, wenn während der Umstellung etwas schiefgeht.
Für wen sich der Wechsel lohnt — und für wen (noch) nicht
Der Wechsel von VMware zu Proxmox ist keine pauschale Empfehlung, sondern eine Abwägung. Es gibt Konstellationen, in denen er sich klar lohnt, und solche, in denen ein voreiliger Umzug mehr Risiko als Nutzen bringt.
Der Wechsel lohnt sich besonders, wenn:
- Die VMware-Abo-Kosten nach der Broadcom-Umstellung spürbar gestiegen sind und die IT-Budgetplanung belasten.
- Die Umgebung aus überwiegend standardisierten Workloads besteht — Datei-, Datenbank- und Applikationsserver, Windows- und Linux-VMs.
- Keine tiefen, unverzichtbaren Abhängigkeiten zu vSphere-exklusiven Enterprise-Integrationen bestehen.
- Intern oder über einen Partner Linux- und Virtualisierungs-Know-how verfügbar ist, das den laufenden Betrieb trägt.
Vorsicht oder Aufschub ist angebracht, wenn:
- Kritische Anwendungen fest auf vSphere-spezifische Funktionen oder zertifizierte Drittanbieter-Integrationen angewiesen sind.
- Laufende Wartungsverträge oder Compliance-Vorgaben kurzfristig an eine bestimmte Plattform gebunden sind.
- Ein großes Migrationsprojekt zeitlich mit anderen kritischen Vorhaben kollidieren würde — dann ist eine geordnete Etappenplanung sinnvoller als ein Hauruck-Umzug.
Ein häufiges Missverständnis sei an dieser Stelle ausgeräumt: Der Wechsel muss nicht alles-oder-nichts sein. In vielen Umgebungen ist ein hybrider Zwischenzustand sinnvoll, in dem der Großteil der Workloads auf Proxmox umzieht, während einige wenige, an vSphere gebundene Spezialsysteme vorerst auf VMware verbleiben. So lässt sich der Löwenanteil der Lizenzkosten einsparen, ohne die problematischen Sonderfälle zu erzwingen. Diese Systeme können später folgen, wenn Alternativen verfügbar oder Verträge ausgelaufen sind.
In der Praxis fällt die Mehrheit der mittelständischen Umgebungen in die erste Kategorie. Die entscheidende Voraussetzung ist immer dieselbe: eine ehrliche Ist-Aufnahme, bevor irgendetwas umgezogen wird. Wer wissen möchte, ob sich der Wechsel im eigenen Fall rechnet, findet in einem unverbindlichen Erstgespräch schnell Klarheit — inklusive einer ersten Einschätzung, welche Systeme problemlos migrieren und wo Sonderfälle zu klären sind.
