Sinds Broadcom de overname van VMware afrondde, is de rekensom voor het draaien van gevirtualiseerde infrastructuur veranderd. Permanente licenties zijn verdwenen, het portfolio is samengevoegd tot een handvol abonnementsbundels en de prijsstelling is overgegaan op een per-core-model. Verlengingsoffertes komen breed gedeeld 2x tot 5x hoger terug dan wat teams eerder betaalden. Voor veel CTO’s en architecten in heel Europa is de vraag niet langer “moeten we naar alternatieven kijken”, maar “waar stappen we naartoe over, en in welke volgorde”.
Dit is een draaiboek, geen salespraatje. Wij zijn een engineering-consultancy, geen cloudprovider, dus we hebben geen platform om u op te duwen. Het doel is u de concepten, de open standaarden en een eerlijke kaart van de opties te geven, zodat u een beslissing kunt nemen die bij uw stack past.
Waarom teams VMware verlaten
De drijfveren zijn consistent bij de organisaties waarmee we spreken:
- Kosten. Per-core-licentiëring straft hosts met hoge dichtheid af. Een server met twee sockets en twee 16-core CPU’s die voorheen twee CPU-licenties nodig had, telt nu als 64 cores. Gecombineerd met bundelconsolidatie vallen veel verlengingen ver boven de eerdere uitgaven uit.
- Bundeling. vSphere, vSAN, NSX en de Aria-suite zitten nu verpakt in grote abonnementen zoals VMware Cloud Foundation (VCF) en vSphere Foundation (VVF). Als u alleen vSphere gebruikte, betaalt u mogelijk voor mogelijkheden die u nooit inzet.
- Lock-in en end-of-support-druk. vSphere 7 bereikte in oktober 2025 het einde van de algemene ondersteuning, en vSphere 8 staat gepland voor oktober 2027. Permanente licenties blijven draaien, maar zonder patches en ondersteuning tikt de klok echt door.
- Verstoring van het ecosysteem. Wijzigingen in de programma’s voor partners en Cloud Service Providers (het VCSP-model ging begin 2026 over op uitsluitend-op-uitnodiging) hebben sommige managed-hostingrelaties tot heronderhandeling gedwongen.
Niets van dit alles betekent dat u volgend kwartaal alles eruit moet trekken. Het betekent dat u uw opties moet kennen en een geloofwaardig uitstappad moet hebben.
Er is geen enkele vervanger voor VMware
Dit is het belangrijkste punt in het hele draaiboek. VMware bundelde compute-virtualisatie, opslag (vSAN), netwerken (NSX) en beheer (vCenter, Aria) in één stack. Geen enkel open-sourceproject vervangt dat allemaal met één enkel product. De juiste zet is om opties op workloads af te stemmen, te leiden met open standaarden (KVM, QEMU, libvirt, Ceph, OVN/Open vSwitch, de OCI- en Kubernetes-API’s) en tools te kiezen die bij elke laag passen.
Hier is het brede landschap, gegroepeerd naar waar elke optie uitblinkt. Beschouw deze als representatief, niet uitputtend, en niet als aanbevelingen van de ene tool boven de andere.
VM-first-platformen (het dichtst bij een vCenter-achtige ervaring)
- Proxmox VE - KVM plus LXC, met ingebouwde clustering, live migratie en Ceph-integratie. Sterke fit voor mkb tot midmarket en eenvoudige on-prem-virtualisatie waar eenvoud telt.
- oVirt - de upstream van het voormalige Red Hat Virtualization. Nu door de community onderhouden nadat Red Hat zich terugtrok, en de basis van producten zoals Oracle Linux Virtualization Manager. Een vertrouwd datacenter/cluster/host-model voor teams die de structuur van vCenter waardeerden.
- Harvester - SUSE’s open-source hyperconverged platform gebouwd op Kubernetes, KubeVirt en Longhorn. Geeft u een VM-gerichte UI terwijl het op cloud-native fundamenten daaronder rust.
Private-cloudplatformen (IaaS met multitenancy en self-service)
- OpenStack - de meest capabele en meest modulaire optie, met aparte projecten voor compute (Nova), netwerken (Neutron, doorgaans OVN), opslag (Cinder, Swift) en identiteit (Keystone). Uitstekend op schaal, maar het is werkelijk complex en beloont een bekwaam operations-team.
- Apache CloudStack - een geïntegreerde, opinionated IaaS die sneller op te zetten is dan OpenStack, met multi-hypervisor-ondersteuning en volwassen netwerken. Populair bij serviceproviders en telecombedrijven.
- OpenNebula - lichtgewicht en pragmatisch, goed geschikt voor edge, hybride en kleine tot middelgrote private clouds waar u orkestratie wilt zonder de operationele zwaarte van OpenStack.
Kubernetes-native paden
Als uw roadmap al cloud-native is, kunt u VM’s en containers laten convergeren op één control plane:
- KubeVirt - draait VM’s als Kubernetes-resources. Het is een CNCF-project (dat eind 2025 de graduation review ingaat) met een groeiende gebruikersbasis, en het is de motor achter diverse commerciële virtualisatieproducten.
- Cluster API - declaratieve provisioning en lifecycle-beheer voor Kubernetes-clusters, vaak gecombineerd met KubeVirt of bare metal voor een cluster-as-a-service-model.
Voor bulkmigratie van VM’s naar de Kubernetes-wereld verbindt het open-sourceproject Forklift (de basis van Red Hats Migration Toolkit for Virtualization) met vCenter, inventariseert het VM’s, converteert het schijven en voert het koude of warme migraties uit.
Hoe te kiezen
Begin bij uw workloads en uw team, niet bij een productshortlist. Een paar vragen die de goede fits consistent scheiden van de pijnlijke:
- Wat draait u eigenlijk? Vooral langlevende Windows- en Linux-VM’s? Een VM-first-platform is het pad van de minste weerstand. Al aan het containeriseren? Een Kubernetes-native pad kan twee stacks samenvoegen tot één.
- Heeft u multitenancy en self-service nodig? Zo ja, dan zit u in private-cloudterritorium (OpenStack, CloudStack, OpenNebula) en niet bij een single-tenant hypervisorbeheerder.
- Wat is uw operationele volwassenheid? De kracht van OpenStack gaat gepaard met reële day-2-kosten. Wees eerlijk over de vraag of u de vaardigheden heeft - of zult aannemen, of zult uitbesteden - om het te draaien.
- Welke VMware-functies zijn dragend? vMotion, HA, DRS, vSAN, NSX-microsegmentatie en Site Recovery Manager hebben allemaal open-source-equivalenten, maar die corresponderen zelden één-op-één. Inventariseer de functies waarvan u werkelijk afhankelijk bent, niet de functies waarvoor u een licentie nam.
- De realiteit van opslag en netwerken. De meeste open-source-paden leunen op Ceph voor opslag en OVN/Open vSwitch voor netwerken. Uw bestaande SAN, fabric en segmentatiebeleid hebben een doelbewust ontwerp nodig, geen kopieer-plak.
Een gefaseerde migratieaanpak
Migraties mislukken wanneer ze worden behandeld als een eenmalige cutover. Faseer het werk en verminder het risico bij elke poort.
1. Beoordelen
Bouw een complete inventaris: VM’s, afhankelijkheden, opslaginrichting, netwerk- en beveiligingsbeleid, en licentieblootstelling met datums. Scoor elke workload op tolerantie voor downtime, complexiteit en compliancegevoeligheid. De output is een geprioriteerde migratie-backlog, geen spreadsheet die veroudert.
2. Ontwerpen
Kies het doelplatform(en) per workloadgroep en ontwerp de opslag- en netwerkarchitectuur expliciet. Hier brengt u NSX-beleid in kaart op OVN-securitygroups, vSAN op Ceph en DRS-achtige plaatsing op uw nieuwe scheduler. Bepaal hier ook uw migratiemechaniek: koude versus warme migratie, tooling en rollback.
3. Piloten
Zet het doel op in een lab en migreer 10-20% van workloads die equivalent zijn aan productie. Meet prestatiepariteit, valideer HA-failover, test back-up en herstel, en oefen uw beveiligingsbeleid. Een pilot van twee tot vier weken brengt de verrassingen aan het licht terwijl ze nog goedkoop zijn.
4. Migreren
Verplaats in golven, gesequenced op risico, waarbij u de productie-impact per golf klein houdt (een plafond van 10-15% is een verstandige vuistregel). Begin met stateless dev/test, dan webtiers, dan databases en bedrijfskritische systemen. Houd de oude omgeving als rollbackdoel aan totdat elke golf gevalideerd is.
5. Beheren
Een nieuw platform heeft nieuwe runbooks, monitoring, patchcadans, capaciteitsplanning en DR-procedures nodig. Plan voor kennisoverdracht zodat het team de day-2-operatie in eigen hand neemt in plaats van onbeperkt afhankelijk te zijn van wie de migratie uitvoerde.
Valkuilen om rekening mee te houden
- Het 10%-probleem. Een kleine set VMware-only-applicaties veroorzaakt het grootste deel van de migratielast. Identificeer ze vroeg; zij bepalen uw tijdlijn.
- Netwerken is moeilijker dan compute. vSwitches, port groups en NSX-beleid worden niet rechtstreeks overgezet. VLAN-mismatches en het opnieuw opbouwen van beleid zijn een belangrijke oorzaak van verlengde downtime.
- DR-testen kost maanden, geen weken. Ontdek dit niet vlak voor go-live. Betrek compliance- en DR-stakeholders al in de ontwerpfase.
- Day-2 onderschatten. De licentie die u opzegt wordt vervangen door operationele verantwoordelijkheid. Begroot voor vaardigheden, automatisering en observability.
- Toolmonogamie. Verzet u tegen het standaardiseren op één platform voor alles voordat de pilot het bewijst. Gemengde landschappen zijn normaal en vaak optimaal.
Het EU-soevereiniteitsvoordeel
Voor Europese organisaties, en Duitse in het bijzonder, is deze migratie ook een soevereiniteitskans. Het draaien van open-source-infrastructuur op EU-gehoste capaciteit verwijdert in één keer twee lagen van externe afhankelijkheid: de software wordt niet beheerst door de roadmap of prijsstelling van één buitenlandse leverancier, en de data blijft onder EU-jurisdictie. Die combinatie - open source plus EU-dataresidentie - is precies waar de raamwerken achter de recente Frans-Duitse push voor digitale soevereiniteit en de Cloud Sovereignty-inspanningen van de Europese Commissie naar streven.
Het strategische punt is leverage. Open standaarden betekenen dat uw workloads draagbaar blijven, dat u onderhandelt vanuit een positie van keuze in plaats van afhankelijkheid, en dat uw compliancepositie (GDPR, sectorale dataregels) ingebouwd is in plaats van erop geschroefd. Soevereiniteit is hier een capaciteit waarvoor u ontwerpt, geen vinkje.
FAQ
Is Proxmox een echte vervanger voor VMware?
Voor VM-first-omgevingen, ja. Proxmox VE dekt clustering, live migratie, HA en Ceph-gebaseerde opslag. Het is geen volledige private-cloud-IaaS, dus als u multi-tenant self-service nodig heeft, kijk dan in plaats daarvan naar OpenStack, CloudStack of OpenNebula.
Proxmox versus VMware - wat is het grootste praktische verschil?
Architectuur en ecosysteem. VMware biedt een strak geïntegreerde, single-vendor-stack; Proxmox stelt open componenten samen (KVM, LXC, Ceph). U ruilt vendor-integratie en enterprise-supportcontracten in voor kostenbeheersing, geen per-core-licentiëring en geen lock-in.
Hoe lang duurt een VMware-migratie?
Het hangt af van de omvang van het landschap en het aandeel VMware-only-workloads, maar denk in kwartalen, niet in weken. Een gefaseerd plan met een echte pilot en golfgebaseerde cutover is wat risico en downtime beheersbaar houdt.
Moeten we alles in één keer van VMware af halen?
Nee. Permanente licenties blijven draaien zonder ondersteuning, wat tijd koopt. De meeste teams migreren in golven en houden een krimpende VMware-footprint aan tijdens de overgang.
Kunnen VM’s en containers op één platform draaien?
Ja. KubeVirt draait VM’s als Kubernetes-objecten, waardoor u beide kunt laten convergeren op één control plane. Het past bij teams die al in cloud-native operaties hebben geïnvesteerd.
Waar Rapid Solutions past
Wij zijn een vendor-neutrale engineering-consultancy met kantoren in Amsterdam en Dubai. We verkopen geen platform, dus onze aanbeveling wordt gestuurd door uw workloads, uw team en uw compliancebehoeften - niet door wat wij moeten verzilveren. We helpen met de beoordeling, het doelontwerp, de pilot, de golfgebaseerde migratie en het day-2-operating-model, met overal een open-source-first- en sovereign-by-design-aanpak.
Staat u voor een VMware-verlenging of plant u een uitstap? Neem contact op met Rapid Solutions en we helpen u een migratiepad te bouwen dat past bij de stack die u daadwerkelijk draait.