VMware 2026: Die Lizenz-Falle, die Ihr Budget sprengt

Willkommen bei IT for Business. Ich bin Mirko Peters.

Hier ist die Frage, die fast niemand stellt, bevor das neue VMware-Angebot zur Unterschrift auf dem Tisch liegt: Verlängern Sie da gerade einfach eine bewährte Virtualisierungsplattform, oder unterschreiben Sie stillschweigend den Einstieg in ein völlig neues, deutlich teureres Betriebsmodell? Die echten Kosten stehen nämlich fast nie im ersten Preisfeld, sondern sie verstecken sich in der Lizenzlogik, in der Architektur und vor allem in den Day-2-Operations.

Seien wir ehrlich, gerade für den Mittelstand ist die aktuelle Entwicklung eine echte Zumutung. Wer am Ende schlicht stabile virtuelle Maschinen für sein Kerngeschäft braucht, bezahlt plötzlich teure Teile einer Plattform mit, die er operativ wahrscheinlich niemals einführen wird. Lassen Sie uns kurz das Rauschen ausblenden und die gesamte Ausgangslage für Ihr Unternehmen sauber sortieren.

Warum 2026 zum Problemjahr wird

Das Jahr zweitausendsechsundzwanzig wird nicht deshalb heikel, weil die VMware-Technik plötzlich unbrauchbar geworden wäre, denn das ist nicht der entscheidende Punkt. Das eigentliche Problem liegt darin, dass sich die wirtschaftlichen und vertraglichen Spielregeln so massiv verschoben haben, dass Ihre alten Annahmen nicht mehr tragen, obwohl die Infrastruktur im Keller auf den ersten Blick noch genau dieselbe ist.

Früher konnten viele Betriebe mit unbefristeten Lizenzen und einer laufenden Wartung planen, was die Budgets sehr berechenbar gemacht hat. Sie hatten einmal eine größere Investition, danach folgten planbare Supportkosten, und dazwischen hatten Sie vor allem eines: Zeit. Diese Bequemlichkeit ist nun endgültig vorbei, da neue Lizenzen ausschließlich im Abo-Modell laufen. Damit verschiebt sich nicht nur der Preis nach oben, sondern die gesamte strategische Denkweise ändert sich grundlegend. Aus einer punktuellen Beschaffungsentscheidung wird eine dauerhafte Bindung, die Sie bei jeder Verlängerung unter enormen Druck setzt.

Was bedeutet das konkret für Sie? Wenn Sie heute noch auf historischen Vertragsständen, alten Supportmodellen oder über Jahre gewachsenen Sonderkonstellationen sitzen, dann laufen diese schützenden Puffer jetzt unweigerlich aus. Viele Häuser haben die letzten zwei Jahre bewusst genutzt, um das Thema vor sich herzuschieben, was durchaus verständlich ist, weil das Tagesgeschäft immer lauter drängelt als trockene Lizenzfragen. Nur holt Sie diese Taktik jetzt ein, und zwar genau in dem Moment, in dem der Hardware-Refresh, neue Security-Anforderungen und die Budgetplanung ohnehin gleichzeitig Ihre volle Aufmerksamkeit fordern.

Dazu kommt ein technischer Zeitdruck, den man nicht unterschätzen darf. vSphere sieben ist bereits aus dem Support gefallen, was kein akademischer Hinweis für Ihre Dokumentation ist, sondern eine ganz praktische Risikofrage für Ihre produktiven Umgebungen darstellt. Wer heute noch dort steht, muss zwingend handeln. Die Version vSphere acht verschafft Ihnen zwar etwas Luft, aber eben kein bequemes Jahrzehnt mehr, sondern nur noch ein sehr begrenztes Zeitfenster. Wenn Sie dann nach vorne auf vSphere neun schauen, landen Sie automatisch im neuen Lizenzmodell, und zwar nicht optional, sondern rein systematisch.

Genau hier beginnt das eigentliche Problemjahr zweitausendsechsundzwanzig, denn bis dahin können viele Unternehmen nicht mehr so tun, als sei das alles nur ein Einkaufsthema für später. Es wird jetzt zur harten Grundsatzentscheidung, ob Sie in der Plattform bleiben und in welcher Form das wirtschaftlich überhaupt noch sinnvoll ist. Vielleicht ist es an der Zeit, sich schrittweise von Teilen der Landschaft zu trennen, bevor die nächste Verlängerung Sie finanziell endgültig festnagelt.

Parallel dazu wurde das Portfolio massiv vereinfacht, zumindest wenn man den Hochglanzbroschüren glaubt. Es gibt weniger Produkte und weniger Auswahl, was auf den ersten Blick aufgeräumt wirkt, in der Praxis aber vor allem weniger Freiheitsgrade für Ihre IT-Strategie bedeutet. Früher konnten Sie einzelne Bausteine passgenau für Ihre Umgebung lizenzieren, während Sie heute zwischen wenigen großen Paketen wählen müssen. Diese sehen strategisch zwar sauber aus, passen aber operativ oft überhaupt nicht zu Ihrem tatsächlichen Bedarf vor Ort.

Für Mittelständler ist diese Situation besonders unangenehm, da große Konzerne meist eigene Lizenzspezialisten und Cloud-Teams haben, um ganze Zielarchitekturen einfach neu aufzubauen. Im Mittelstand sieht die Wirklichkeit anders aus, denn dort beherrschen gewachsene Cluster und kritische Legacy-Systeme das Bild. Da gibt es oft ein Team, das nebenbei auch noch die Security und das Backup stemmen muss, weshalb gerade diese organisch gewachsenen Umgebungen von den starren Regeln am härtesten getroffen werden.

Überlegen Sie mal selbst: Es ist nicht die exotische Enterprise-Landschaft, die zuerst unter Druck gerät, sondern die ganz normale, pragmatische VMware-Umgebung, die jahrelang einfach zuverlässig ihren Dienst getan hat. Genau deshalb wird zweitausendsechsundzwanzig für viele kein Jahr der Technik, sondern das Jahr der unangenehmen wirtschaftlichen Ehrlichkeit. Wenn dieser Zeitdruck erst einmal verstanden ist, müssen wir im nächsten Schritt die eigentliche Kostenmechanik im Detail zerlegen.

Die Lizenzmechanik, die Budgets entgleisen lässt

Schauen wir uns jetzt die Mechanik an, die in vielen Gesprächen erst auffällt, wenn das Angebot als PDF vorliegt und der erste Schreck mühsam verdaut wurde. Früher dachten viele Verantwortliche in Sockeln, was die Planung recht übersichtlich machte. Man kalkulierte zwei CPUs pro Host und drei Hosts im Cluster, legte die bekannte Editionslogik fest und die Sache war erledigt. Heute rechnen Sie stattdessen in physischen Cores, wodurch eine stille Verteuerung beginnt, die viele erst zu spät bemerken.

Der erste kritische Punkt ist die Untergrenze von 16 Cores pro CPU. Das klingt auf dem Papier harmlos, bis man diese Logik auf typische Mittelstands-Hardware überträgt. Wenn Sie CPUs mit weniger als 16 physischen Kernen einsetzen, zahlen Sie trotzdem so, als wären alle 16 vorhanden. Das ist keine technische Optimierung für Ihre Umgebung, sondern schlicht eine kaufmännische Unterkante des Herstellers. Gerade kleinere Hosts, Außenstellen oder ältere Reserveknoten rutschen damit schnell in eine massive Überlizenzierung, obwohl sich an der realen Leistung für Ihre Nutzer absolut nichts verbessert.

Nun könnte man meinen, dass man einfach sauber pro Core abrechnet und das Thema damit erledigt ist. So einfach ist es leider nicht, da im Markt zusätzlich Mindestbestellmengen kursieren, die gerade kleine Nachkäufe und Erweiterungen unnötig kompliziert machen. In großen Umgebungen lässt sich so etwas oft noch im Gesamtvolumen verstecken, doch für den Mittelstand ist diese Entwicklung viel unangenehmer. Wenn Sie einen kleinen Cluster ergänzen oder einen Host tauschen wollen, wird aus einer technisch kleinen Änderung schnell eine wirtschaftlich unverhältnismäßige Bestellung.

Da versteckt sich das eigentliche Risiko für Ihr Budget. Es lauert nicht in der großen Transformation, sondern in den alltäglichen Schritten Ihres IT-Betriebs. Ein Host mehr, ein Refresh in einer Niederlassung oder ein zusätzlicher Knoten für die Ausfallsicherheit greifen heute direkt in die Lizenzgeometrie ein, während diese Dinge früher nach normalem Infrastrukturhandwerk aussahen.

Dann kommt die Paketfrage zwischen VVF und VCF dazu. Auf dem Papier wirken das wie zwei einfache Produktlinien, doch in der Praxis reden wir über zwei völlig verschiedene Kostenprofile. VVF ist für viele klassische Virtualisierungsumgebungen der naheliegendere Pfad, weil es näher an dem dran ist, was viele Mittelständler tatsächlich im Rechenzentrum betreiben. VCF geht deutlich weiter und bietet einen umfassenden Plattformansatz. Dort kaufen Sie nicht nur den Hypervisor und die Verwaltung, sondern bezahlen für zusätzliche Bausteine für Storage, Netzwerk und Automatisierung mit.

Das Problem ist hierbei nicht, dass diese Funktionen schlecht wären. Das Problem ist vielmehr die Verwechslung von technischer Möglichkeit und tatsächlichem Bedarf. Nur weil ein Bundle technisch viel kann, heißt das noch lange nicht, dass Ihr Betrieb wirtschaftlich davon profitiert. Wenn Sie keine klare Zielarchitektur mit vSAN oder einem durchgängigen Private-Cloud-Betriebsmodell haben, bezahlen Sie für eine Plattformbreite, obwohl Ihr Alltag weiter aus klassischen VM-Workloads besteht.

Klartext: Sie kaufen oft Teile eines Private-Cloud-Stacks mit, ob Sie diese nun brauchen oder nicht. Genau das verzerrt viele Beschaffungsentscheidungen in den Unternehmen. Im Einkauf wirkt das Angebot sauber, da es definierte Bundles und klare Support-Laufzeiten enthält. Formal ist daran wenig auszusetzen, doch funktional kann es komplett an Ihrem realen Bedarf vorbeigehen.

Hier ist die eigentliche Frage: Kaufen Sie gerade ein Produkt, das zu Ihrer Umgebung passt, oder passen Sie Ihre Umgebung im Kopf an einen Produktkatalog an? Das klingt ähnlich, macht aber wirtschaftlich einen gewaltigen Unterschied. Viele Teams rutschen in genau diesen Denkfehler und fangen an, ihren Bedarf aus dem Bundle heraus zu interpretieren. Das ist der falsche Weg, denn erst kommt die Nutzung und dann das Produkt, nicht umgekehrt.

Angenommen, Sie betreiben überwiegend Standard-Workloads und einige Windows-Server zusammen mit einer gewachsenen SAN-Landschaft. Dann ist die entscheidende Frage nicht, welches Bundle strategisch am modernsten klingt. Die Frage ist vielmehr, welche Funktionen heute produktiv genutzt werden und welche davon innerhalb der Vertragslaufzeit realistisch zum Einsatz kommen. Alles andere ist lediglich teuer eingekaufte Möglichkeit ohne direkten Nutzen.

Genau deshalb sehen Angebote oft besser aus, als sie im harten Betrieb wirklich sind. Der Preis ist sauber ausgewiesen und die Lizenzmetriken sind formal erklärbar. Der Haken liegt woanders, denn das Angebot bildet nicht automatisch Ihre reale Nutzung ab, sondern lediglich das lizenzierbare Portfolio des Herstellers. Das ist aus Sicht des Anbieters logisch, für Sie als Verantwortlichen jedoch gefährlich, wenn dieser Unterschied nicht offen auf dem Tisch liegt.

Seien wir ehrlich: Viele Unternehmen brauchen keinen halben Private-Cloud-Baukasten. Sie brauchen eine tragfähige und stabile Virtualisierungsbasis mit kalkulierbaren Kosten für die nächsten Jahre. Wenn das Angebot darüber hinausgeht, muss der Mehrwert belastbar begründet werden. Das sollte nicht mit Roadmaps oder bunten Folien geschehen, sondern mit einem konkreten Betriebsmodell für Ihr Team.

Aber das ist nur die halbe Wahrheit, denn richtig teuer wird es erst in Kombination mit der Architektur.

Warum gute Architektur nicht automatisch günstige Lizenzierung bedeutet

Jetzt kommt der Teil, an dem viele saubere Infrastrukturkonzepte plötzlich schief aussehen, obwohl sie technisch absolut vernünftig geplant wurden. Über Jahre war die Logik für IT-Leiter relativ klar: Man wollte konsolidieren, modernisieren und die Auslastung verbessern. Wenn Sie Hosts verdichten konnten, galt das als echter Fortschritt für das Unternehmen. Weniger Systeme bedeuteten bessere Performance, weniger Stromverbrauch und deutlich weniger Pflegeaufwand für die Administratoren. Das war aus Architektur- und Betriebssicht meist der richtige Weg.

Unter einer Core-basierten Lizenzierung kippt diese Rechnung jedoch an einer entscheidenden Stelle. Mehr Rechenleistung kommt heute oft aus mehr physischen Cores, und genau diese Cores sind nicht nur technische Reserve, sondern direkte Lizenzmasse. Das bedeutet konkret: Was architektonisch effizient aussieht, kann auf der Lizenzseite deutlich schwerer ins Gewicht fallen. Sie bauen also womöglich die bessere Plattform und bekommen am Ende trotzdem die höhere Rechnung präsentiert.

Was bedeutet das für Sie in der Praxis? Nehmen wir den typischen Gedanken bei einem Hardware-Refresh. Alte Hosts kommen raus, dafür ziehen weniger neue Hosts mit deutlich mehr Leistung pro System ins Rack ein. Das klingt nach einer sauberen Lösung, da weniger Geräte die operative Komplexität senken. Nur wenn diese Leistung über sehr große CPUs mit hoher Kernzahl eingekauft wird, wächst Ihre Lizenzlast automatisch mit. Dann sparen Sie vielleicht bei Strom und Wartung, verlieren aber auf der Lizenzseite einen Teil dieses Vorteils wieder, manchmal sogar den Löwenanteil.

Genau deshalb sind weniger Hosts heute nicht mehr automatisch billiger für Ihr Budget. Das ist kontraintuitiv, weil wir über Jahrzehnte gelernt haben, dass Konsolidierung fast immer wirtschaftlich hilft. Im VMware-Modell für das Jahr zweitausendsechsundzwanzig müssen Sie genauer hinschauen. Die relevante Frage ist nicht mehr nur, wie viele Hosts Sie betreiben. Es geht darum, wie sich deren Core-Struktur über den gesamten Cluster verteilt, inklusive der nötigen Reserve für Wachstum und Ausfälle.

Das trifft kleine Cluster im Mittelstand besonders hart. In einer idealen Welt auf PowerPoint baut man Kapazität genau passend für den aktuellen Bedarf. In der Realität brauchen Sie jedoch Puffer für Wartungsfenster, Host-Ausfälle oder unerwartetes Wachstum. Diese Reserve war früher vor allem eine Frage der Hardware-Anschaffung. Heute ist sie gleichzeitig eine permanente Lizenzfrage, da Reservekapazität oft vorab bezahlte Core-Fläche ist, die Sie im Alltag vielleicht gar nicht voll ausnutzen.

Bei kleineren Standorten oder Außenstellen wird das Ganze noch unangenehmer. Dort läuft die Infrastruktur häufig bewusst schlank, weil die Last überschaubar ist und kein großes Team für die Verwaltung bereitsteht. Wenn dann Mindestregeln und die Core-Logik auf diese kleinen Setups treffen, wird aus einer pragmatischen Lösung schnell ein wirtschaftlich schiefer Aufbau. Das liegt nicht daran, dass die Technik schlecht geplant wäre, sondern daran, dass das Lizenzmodell kleine und nüchterne Designs schlichtweg nicht belohnt.

Lassen Sie uns das kurz zerlegen. Architektur entscheidet sich unter diesen Bedingungen nicht mehr nur am Feature-Set des Hypervisors. Sie entscheidet sich an der Geometrie der Umgebung, also der Anzahl der Hosts und der physischen Cores pro CPU. Auch die Ausfallstrategie und die Lastprofile spielen eine tragende Rolle für die Kostenstruktur. Das ist keine Schönheitsfrage für einen Design-Workshop, sondern die Grundlage für Ihre langfristige Planung.

Darum sage ich in solchen Projekten oft: Architektur schlägt Tools. Das Werkzeug kann erst dann sinnvoll bewertet werden, wenn die Form der Umgebung wirtschaftlich trägt. Wenn Ihre Host-Geometrie falsch gewählt ist, rettet Ihnen kein Lizenzbundle der Welt die Rechnung. Und wenn Ihre Reserve falsch eingeplant wurde, wird jede spätere Erweiterung zu einem sehr teuren Nachfassen beim Anbieter.

Hinzu kommt die Realität im deutschen Mittelstand, in dem kaum jemand auf der grünen Wiese startet. Sie haben keine perfekte Zielarchitektur ohne Altlasten, sondern meist gewachsene Systeme und Fachverfahren mit speziellen Eigenheiten. Vielleicht läuft eine alte Applikation nur auf einer bestimmten Version zuverlässig, oder Sie haben Standorte mit sehr unterschiedlicher technischer Reife. Diese Landschaften sind vielleicht nicht elegant, aber sie sind die Realität, in der Sie arbeiten müssen. Genau deshalb greifen pauschale Architekturregeln hier oft zu kurz.

Ein theoretisch optimierter Cluster hilft Ihnen wenig, wenn einzelne Workloads nicht einfach verschiebbar sind oder eine Fachanwendung den Standardbetrieb sabotiert. Dann entsteht die typische Situation, in der man nicht alles auf einmal modernisiert, sondern nur stückweise vorgeht. In diesem Stückwerk wird die Lizenzierung heikel, weil jede Zwischenstufe ihre eigene Wirkung auf die Cores und die Reserven hat.

Die nüchterne Konsequenz daraus ist simpel: Sie dürfen Architektur-Effizienz und Lizenz-Effizienz nicht mehr automatisch gleichsetzen. Beides kann zusammenfallen, muss es aber nicht zwingend. Wer das ignoriert, baut sich am Ende eine technisch gute Umgebung mit einer wirtschaftlich falschen Form.

Jetzt wird es interessant, denn genau hier beginnt die eigentliche Wirtschaftlichkeitsrechnung für Ihr Unternehmen.

Die echten Kosten stehen nicht auf dem Angebot

Bis hierhin haben wir über Lizenzlogik und Architektur gesprochen. Jetzt kommt der Teil, der in Geschäftsführungsrunden fast immer zu spät sichtbar wird: der Unterschied zwischen dem reinen Preis und den echten Vollkosten. Der Lizenzpreis ist bei VMware im Jahr zweitausendsechsundzwanzig nur noch die Eintrittskarte. Er sagt Ihnen zwar, was Sie bezahlen müssen, um überhaupt im Spiel zu bleiben, aber er verrät Ihnen noch nicht, was der Betrieb dieser Entscheidung über die Jahre tatsächlich kostet.

Früher konnten viele Unternehmen eine Virtualisierungsplattform noch als größere Investition mit überschaubaren Folgekosten betrachten. Heute verschiebt sich das Bild klar in Richtung einer dauerhaften Bindung. OPEX statt CAPEX klingt für manche Finanzabteilungen erst einmal angenehm, weil die Anfangshürde kleiner wirkt und sich Budgets flexibler verteilen lassen. Nur genau dort liegt die Falle. Wenn Sie aus einer einmaligen Anschaffung eine dauerhafte Zahlungspflicht machen, verlieren Sie mit jeder Vertragsrunde ein Stück Ihrer Beweglichkeit. Sie mieten dann nicht nur Software, sondern Sie mieten eine Abhängigkeit.

Darum ist der Jahrespreis fast immer die falsche Zahl, wenn Sie eine saubere Entscheidung treffen wollen. Was bedeutet das konkret für Sie? Rechnen Sie nicht in zwölf Monaten, sondern kalkulieren Sie in drei, fünf und wenn möglich sieben Jahren. Erst dann sehen Sie, ob ein vermeintlich tragbares Angebot wirklich tragfähig ist oder nur im ersten Jahr freundlich aussieht. Viele Angebote wirken deshalb erträglich, weil sie auf den unmittelbaren Moment der Verlängerung zugeschnitten sind. Die operative Wahrheit beginnt aber erst danach, wenn Erweiterungen, Hardwarewechsel, Schulungen und der laufende Plattformbetrieb dazukommen.

Hinzu kommt ein Punkt, den viele erst bemerken, wenn es bereits hektisch wird. Verspätete Verlängerungen können selbst wieder Kosten auslösen, denn wenn Sie Fristen reißen, verhandeln Sie nicht mehr aus der Ruhe heraus, sondern unter massivem Druck. Und Druck ist in Infrastrukturfragen fast nie billig. Ein möglicher Aufschlag bei zu später Verlängerung ist dabei gar nicht das Hauptproblem, sondern eher das Warnschild. Das eigentliche Risiko ist, dass Sie unter Zeitdruck Entscheidungen abnicken, die Sie mit sechs Monaten Vorlauf ganz anders bewertet hätten.

Noch teurer wird das Thema in den Day-2-Operations. Seien wir ehrlich: Day eins ist fast nie das Problem. Die Plattform steht irgendwann, die Lizenz ist bestellt und der Vertrag ist unterschrieben. Der Schmerz beginnt erst später im Alltag. Patch-Zyklen müssen geplant werden, Kompatibilitäten brauchen eine Prüfung und Supportfälle müssen sauber eingegrenzt werden. Die Dokumentation muss aktuell bleiben und das Team muss die Plattform nicht nur bedienen, sondern wirklich beherrschen.

Hier zeigt sich, ob Sie ein Paket gekauft haben, das Ihr Betrieb auch wirklich tragen kann. Wenn zusätzliche Komponenten im Bundle zwar theoretisch vorhanden sind, praktisch aber niemand im Team sie sauber aufsetzt oder verantwortet, dann bezahlen Sie nicht nur unnötige Funktionen. Sie bezahlen zusätzliches Betriebsrauschen, mehr Angriffsfläche, mehr Abhängigkeiten und einen höheren Wissensbedarf. Das ist wie ein Werkzeugschrank voller Spezialwerkzeuge, die niemand benutzt, die aber trotzdem gepflegt, verstanden und im Zweifel supportet werden müssen.

Besonders heikel wird es, wenn die Dokumentation dünn ist und der Dienstleister zum alleinigen Gedächtnis Ihrer Umgebung geworden ist. Dann hängt nicht nur die Lizenzierung am Hersteller, sondern der gesamte Betrieb gleich mit am Partner. Das kann sinnvoll sein, wenn Rollen und Verantwortlichkeiten sauber geklärt sind, aber es wird riskant, wenn niemand intern noch belastbar sagen kann, welche Funktionen tatsächlich produktiv genutzt werden. Oft weiß keiner mehr, was nur mitlizenziert ist und was im Ernstfall überhaupt jemand betreiben könnte.

Klartext: Wer Funktionen mitkauft, die nie eingeführt werden, bezahlt keine Zukunftssicherheit. Er bezahlt Strategie-Fantasien als laufende Kosten. Das mag im Workshop noch nach einer tollen Roadmap klingen, aber in der Gewinn- und Verlustrechnung ist es schlicht dauerhafter Mehraufwand ohne echten Gegenwert.

Deshalb sollten Sie jedes VMware-Angebot in zwei Spalten lesen. In Spalte eins steht, was der Hersteller Ihnen verkauft. In Spalte zwei muss stehen, was Ihr Unternehmen davon über die Vertragslaufzeit real nutzt, betreibt und verantwortet. Wenn diese zweite Spalte dünn bleibt, ist das Angebot nicht schlank, sondern schief. Sobald diese Vollkosten sichtbar werden, taucht fast automatisch die nächste Frage auf, die jeder Geschäftsführer irgendwann stellt.

Wann Bleiben vernünftig ist und wann ein Exit sinnvoll wird

Spätestens an diesem Punkt kommt die Frage auf, die viele ungern laut stellen, weil sie sofort Lagerdenken auslöst: Müssen wir jetzt raus aus VMware? Die nüchterne Antwort lautet: nicht automatisch. Ein reflexartiger Exit ist oft genauso unklug wie ein reflexartiges Verlängern, denn auch eine Migration hat ihren Preis, ihre Reibung und ihr ganz eigenes Projektrisiko. Wer so tut, als sei der Ausstieg nur eine kleine technische Umstellung, macht denselben Fehler wie vorher bei der Lizenzverlängerung und unterschätzt die Folgekosten massiv.

Bleiben kann durchaus vernünftig sein. Das gilt vor allem dann, wenn Sie Funktionen nicht nur mitbezahlen, sondern wirklich produktiv nutzen. Wenn vSAN ein tragender Teil Ihrer Storage-Architektur ist oder wenn NSX nicht nur in einer Präsentation vorkommt, sondern Security und Netzwerksegmente tatsächlich darauf aufbauen, dann reden wir über mehr als nur einen Hypervisor. Wenn Sie eine klare VCF-Zielarchitektur mit Automatisierung und standardisiertem Plattformbetrieb verfolgen, wäre ein Wechsel nicht bloß ein Lizenzthema, sondern ein massiver Eingriff in das gesamte Betriebsmodell.

Anders sieht es aus, wenn Ihre Umgebung im Kern aus klassischen VM-Lasten besteht und die zusätzlichen Bundle-Funktionen im Alltag keine operative Rolle spielen. Dann wird Bleiben riskant, und zwar nicht technisch, sondern rein wirtschaftlich. Sie zahlen fortlaufend für eine Plattformbreite, obwohl Ihr Betrieb weiter schmal bleibt. Das kann eine Zeit lang tragbar wirken, besonders wenn die Mannschaft ausgelastet ist und niemand ein Migrationsprojekt eröffnen will. Nur wächst genau in solchen Situationen die Abhängigkeit still weiter, während der Mehrwert flach bleibt, was kein stabiler Zustand, sondern eine aufgeschobene Entscheidung ist.

Für viele Mittelständler ist deshalb die Teilmigration der sauberste Mittelweg. Das geschieht nicht aus Mutlosigkeit, sondern aus reiner Disziplin. Sie nehmen zuerst die Workloads heraus, die wenig VMware-spezifisch sind, die gut dokumentiert sind und keine unnötigen Seiteneffekte im Betrieb auslösen. Entwicklungsumgebungen, interne Dienste oder weniger kritische Anwendungsserver sind ideale Kandidaten, um Luft zu schaffen. Die kritischen Systeme bleiben zunächst dort, wo das Risiko beherrschbar ist, wodurch Sie Zeit, echte Betriebserfahrung auf der Zielplattform und vor allem eine bessere Verhandlungsposition beim nächsten Renewal gewinnen.

Was bedeutet das konkret bei den Alternativen? Proxmox ist für kostensensitive und pragmatische Umgebungen oft der erste Kandidat, weil der wirtschaftliche Hebel klar ist und die Plattform für klassische Virtualisierung im Mittelstand inzwischen ernsthaft auf dem Tisch liegt. Hyper-V ist naheliegend, wenn Sie ohnehin tief im Microsoft-Stack arbeiten, das Team die Werkzeuge kennt und Windows-zentrierte Betriebsprozesse schon vorhanden sind. Nutanix oder OpenShift spielen in einer ganz anderen Liga. Beide können sinnvoll sein, aber bitte nicht als Fluchtreflex, denn Nutanix braucht eine klare Plattformstrategie und OpenShift erfordert zusätzlich ein belastbares Betriebsmodell.

Nun kommt der Teil, über den Anbieter ungern sprechen. Die Migration selbst ist kein einfacher Klick auf „Importieren“, nach dem dann alles wie gewohnt weiterläuft. Sie müssen das Backup und den Restore neu denken, den Storage sauber neu zuordnen und sämtliche Runbooks anpassen. Das Monitoring muss umgebaut, Betriebsübergaben organisiert und das Team befähigt werden, die neue Plattform nicht nur zu starten, sondern auch im Störfall ruhig zu betreiben. Dazu kommen Tests, Wartungsfenster und das stille Thema Dokumentation, das in fast jedem Projekt viel zu spät ernst genommen wird.

Gerade im Mittelstand ist das relevant, weil ein Migrationsaufwand selten an der reinen Hypervisor-Frage scheitert. Er scheitert meist an den Nebenbedingungen. Wer kennt die Abhängigkeiten der alten Fachanwendung wirklich im Detail? Wer testet den Restore tatsächlich unter Realbedingungen? Welche Appliance reagiert empfindlich auf Treiber, Netzkonfiguration oder Zeitquellen? Wo ist die Betriebsdoku so dünn, dass im Zweifel doch wieder der alte Dienstleister angerufen werden muss? Da wird es richtig riskant.

Deshalb ist die vernünftige Entscheidung oft nicht „bleiben oder raus“, sondern die Frage, wo wir bewusst bleiben und wo wir geordnet aussteigen. Wenn Ihnen das bekannt vorkommt: Sie sind nicht allein, und es ist absolut lösbar. Die Kunst liegt nicht im großen Entweder-oder, sondern in der richtigen Reihenfolge. Bevor Sie also unterschreiben oder migrieren, brauchen Sie keinen Glaubenskrieg und keine Folien-Schlacht, sondern einen klaren Fragenkatalog.

Die Fragen, die Sie vor jeder Verlängerung stellen müssen

Bevor Sie das nächste Renewal einfach abnicken, brauchen Sie keine schicke Produktpräsentation. Sie brauchen bessere Fragen. Dabei geht es nicht um wohlklingende Marketing-Namen, sondern knallhart um die tatsächliche Nutzung, die echten Kosten und Ihre Abhängigkeiten. Lassen Sie uns das kurz zerlegen.

Erstens sollten Sie klären, welche Funktionen Sie heute im echten Betrieb wirklich nutzen. Vergessen Sie das Lizenzblatt oder die Versprechen Ihres Implementierungspartners, denn oft wurden Features zwar aktiviert, aber nie sauber in Ihre Prozesse überführt. Zwischen dem, was Sie teuer eingekauft haben, und dem, was produktiv relevant ist, liegt meistens ein gewaltiges Missverständnis. Wenn Funktionen bis heute nur im Konzept stehen, zahlen Sie für heiße Luft.

Zweitens müssen Sie prüfen, wie viele physische Cores Sie tatsächlich lizenzieren, wenn Sie Puffer und geplantes Wachstum ehrlich einrechnen. Viele IT-Leiter betrachten ihre Umgebungen immer noch aus der VM-Perspektive, was heute schlicht nicht mehr ausreicht. Gehen Sie zurück auf die Hardwareebene, schauen Sie sich jeden Host und jede CPU einzeln an und kalkulieren Sie Ersatzhardware sowie Failover-Kapazitäten präzise mit ein. Sonst rechnen Sie sich eine Umgebung schön, die vertraglich längst über Ihre Grenzen hinausgewachsen ist.

Drittens stellt sich die Frage, was die Plattform über drei bis fünf Jahre kostet und nicht nur im ersten Jahr. An diesem Punkt trennt sich eine strategische Entscheidung von einer Zahl, die lediglich den Einkauf beruhigen soll. Wenn Sie nur auf das Einstiegsjahr schauen, sehen Sie zwar den Preis, aber nicht die langfristige Bindung. Rechnen Sie Laufzeiten, Betriebskosten und notwendige Erweiterungen auf einer einzigen Seite zusammen, denn ohne diese Übersicht fehlt Ihnen die Grundlage für eine vernünftige Unterschrift.

Viertens müssen Sie identifizieren, welche Workloads zwingend an VMware gebunden sind und welche Sie problemlos portieren oder sogar ganz abschalten könnten. Das klingt banal, ist aber oft der entscheidende Wendepunkt für Ihre Flexibilität. In vielen Rechenzentren laufen Systeme nur deshalb mit, weil sie nie jemand aktiv hinterfragt hat. Trennen Sie kritische Abhängigkeiten sauber von Altlasten, damit Sie nicht unnötig Ihre gesamte Beweglichkeit aufgeben.

Fünftens ist entscheidend, was architektonisch passiert, wenn der nächste Hardware-Refresh oder eine Cluster-Erweiterung ansteht. Solche Szenarien sind keine Ausnahmen, sondern der ganz normale Wahnsinn auf der Zeitachse. Wenn Ihre aktuelle Lizenzrechnung nur so lange aufgeht, wie nichts wächst und nichts ausfällt, dann haben Sie keine tragfähige Infrastruktur, sondern lediglich ein starres Standbild. Sie brauchen einen Plan, der Bewegung zulässt.

Sechstens brauchen Sie einen belastbaren Plan B für den Fall, dass Support oder Betrieb teurer werden, als es wirtschaftlich noch Sinn ergibt. Das ist keine leere Drohkulisse, sondern eine notwendige Handlungsoption für jeden Geschäftsführer. Ob das ein Pilotprojekt mit einer Zweitplattform oder ein sauberer Workload-Split ist, spielt erst einmal keine Rolle. Wichtig ist nur, dass Sie nicht erst dann über Alternativen nachdenken, wenn der Druck bereits maximal ist.

Hier ist die eigentliche Frage: Kann Ihr Team diese Punkte heute schon sicher beantworten? Falls nicht, kommt jede Vertragsverlängerung schlicht zu früh. Wenn Ihr Anbieter Ihnen rät, diese Details später zu klären, sollten Sie sich fragen, warum er es plötzlich so eilig hat.

Schluss / Outro

Das war IT for Business.

Seien wir ehrlich: Gute IT entscheidet sich am Ende nicht über das Tool, sondern über die Architektur und die strategischen Weichenstellungen davor.

Wenn Ihnen dieser Klartext gefallen hat, abonnieren Sie den Podcast, damit Sie keine weiteren Einblicke aus der Praxis verpassen.

Falls Sie gerade selbst vor einer Modernisierung stehen, stellen Sie die harten Fragen lieber heute als erst im laufenden Betrieb.

Bis zur nächsten Folge.