Migration des licences VMware Broadcom : Guide stratégique pour 2026

L'acquisition de VMware par Broadcom en 2024 ne fut pas qu'une fusion d'entreprises ; ce fut un changement tactique radical qui a rendu obsolètes les modèles ELA (Enterprise License Agreement) traditionnels de vSphere « à volonté ». Les équipes d'ingénierie abordant 2025 et 2026 doivent cesser de considérer VMware comme un hyperviseur générique et commencer à le traiter comme une charge fiscale héritée à forte marge qui exige une stratégie d'évacuation ou d'optimisation brutale sur trois ans.

La mort de la licence perpétuelle et l'ultimatum VCF

La stratégie de Broadcom est chirurgicalement précise : forcer les entreprises de premier ordre à adopter VMware Cloud Foundation (VCF) et les acteurs du marché intermédiaire à adopter vSphere Foundation (VVF). L'époque des renouvellements de SnS (Subscription and Support) pour les licences perpétuelles est révolue. Si vous exécutez vSphere 7.x ou 8.x avec des clés perpétuelles, votre prochain renouvellement verra probablement une augmentation de prix de 300 % à 600 % alors que vous serez contraint à une facturation par cœur et par abonnement.

Le point de friction technique est le calcul de la densité de cœurs. Broadcom impose un minimum de 16 cœurs par socket CPU. Si vous utilisez des processeurs Xeon Gold/Silver hérités à 8 ou 12 cœurs, vous payez pour du silicium fantôme. Inversement, si vous utilisez des nœuds AMD EPYC 9654 à haute densité avec 96 cœurs par socket, le passage d'une licence basée sur les sockets à une licence basée sur les cœurs est un bain de sang financier. La stratégie 2026 doit inclure un alignement du renouvellement du matériel qui maximise le débit par cœur – pensez à des pièces à 32 cœurs haute fréquence plutôt qu'à des pièces à 64 cœurs basse fréquence pour minimiser les dépenses de licence.

VCF vs. vSphere Standard : La consolidation forcée

Broadcom a effectivement tué le menu « à la carte ». Auparavant, un ingénieur pouvait acheter vSphere Enterprise Plus et ignorer NSX et vSAN. Aujourd'hui, l'ensemble des fonctionnalités est regroupé. Si vous avez besoin de distributed switching ou de DRS, vous êtes contraint d'utiliser VVF ou VCF.

• VCF (VMware Cloud Foundation) : Inclut vSphere, vSAN (jusqu'à 1TiB par cœur), NSX et Aria Suite. C'est le produit phare de Broadcom. Si vous n'utilisez pas NSX pour la micro-segmentation, vous payez pour du poids mort.
• vSphere Foundation (VVF) : Le « niveau intermédiaire » qui remplace Enterprise Plus. Inclut vSAN (100GiB par cœur), mais ne possède pas les fonctionnalités réseau avancées de NSX.
• vSphere Standard : Dépourvu de distributed switches. Pour toute entreprise avec plus de 10 nœuds, c'est techniquement ingérable pour les charges de travail de production.

Pour les organisations avec des empreintes vSAN à grande échelle, le nouveau modèle d'attribution de droits est particulièrement douloureux. Si votre ratio stockage/calcul est élevé (par exemple, des environnements VDI massifs), la limite de 1 TiB par cœur dans VCF vous force souvent à acheter des licences de capacité vSAN supplémentaires à un prix tel que Pure Storage ou NetApp semblent à nouveau bon marché.

Le pivot Nutanix AHV : Réalités de la migration d'infrastructure

Nutanix est le principal bénéficiaire de l'agression de Broadcom, mais la migration d'ESXi vers AHV n'est pas un « projet de week-end ». La complexité réside dans la pile réseau. Passer des VMware Distributed Virtual Switches (DVS) à Nutanix AHV (basé sur OVS) nécessite une refonte complète de vos configurations de VLAN tagging et LACP.

# Nutanix AHV Network Configuration Example via acli
# Creating a migration bridge for ESXi traffic
net.create br1_migration
net.add_vlan_item br1_migration vlan_id=100
# Ensure MTU parity (9000 for Jumbo Frames if vMotion/Live Migration used)
manage_ovs update_bridge br1 --mtu_size 9000

L'outil Nutanix Move est compétent, mais il échoue sur les disques RDM (Raw Device Mapping) et certaines configurations multi-writer spécifiques. Si vos clusters SQL reposent sur des VMDK partagés via multi-writer, vous devrez les réarchitecturer pour utiliser Nutanix Volumes (iSCSI) ou migrer vers des AlwaysOn Availability Groups. Du point de vue des coûts, Nutanix n'est pas « bon marché » – c'est souvent 15-20 % de moins que les nouveaux tarifs VCF – mais sa valeur réside dans la liberté vis-à-vis de l'écosystème imprévisible et lourd d'audits de Broadcom.

OpenShift et KubeVirt : L'avenir de la sortie full-stack

Le chemin de migration le plus agressif – et le plus techniquement gratifiant – consiste à déplacer les VM dans Red Hat OpenShift Virtualization (utilisant KubeVirt). Cela vous permet de gérer les VM et les conteneurs via un seul Kubernetes control plane. Il élimine la taxe hyperviseur en tirant parti de KVM sous le capot.

Cependant, la réalité de 2026 est que la plupart des entreprises ne sont pas prêtes pour les « VMs as Pods ». Vous perdez la « sensation VCSA » de la gestion par pointer-cliquer. Le networking nécessite Multus CNI pour fournir plusieurs interfaces à une VM, et le stockage exige un fournisseur compatible CSI. Si vous êtes déjà investi dans un workflow Kubernetes automatisé, KubeVirt est le point final logique. Si vous êtes une entreprise utilisant des systèmes Windows hérités, la surcharge de performance de Windows-on-KVM dans OpenShift entraîne toujours une pénalité de latence de 5 à 8 % par rapport aux drivers ESXi matures.

Proxmox VE en entreprise : Plus une blague

Il y a deux ans, mentionner Proxmox dans un data center de Tier-1 vous aurait fait rire de la réunion du CAB (Change Advisory Board). En 2026, c'est une bouée de sauvetage viable pour les DMZ, les environnements de dev/test et les sites edge. L'intégration de Ceph dans Proxmox offre une alternative légitime à vSAN sans coût logiciel.

L'obstacle est le manque de support de sauvegarde « entreprise ». Bien que Proxmox Backup Server (PBS) soit excellent, il ne s'intègre pas avec Veeam ou Commvault avec la même maturité d'API que le VADP de VMware. Les organisations adoptant Proxmox s'éloignent généralement des appliances de sauvegarde centralisées au profit de sauvegardes au niveau des applications ou de snapshots au niveau du système de fichiers. Si vous avez plus de 500 nœuds, la surcharge de gestion due à l'absence d'un « vCenter pour les gouverner toutes » centralisé de Proxmox (la gestion multi-cluster est encore naissante) devient un coût de main-d'œuvre qui peut annuler les économies de licence.

La checklist de migration 2026 : Étape par étape

1. Auditez la densité de vos cœurs : Utilisez PowerCLI pour exporter le nombre de cœurs physiques actuels. Tout hôte avec moins de 16 cœurs doit être décommissionné immédiatement.

   Get-VMHost | Select Name, @{N="Cores";E={$_.ExtensionData.Hardware.CpuInfo.NumCpuCores}}

2. Évaluez l'utilisation de NSX : Si vous n'utilisez pas Distributed Firewall (DFW) ou les overlays VXLAN/GENEVE, vous payez pour des fonctionnalités VCF dont vous n'avez pas besoin.
3. Dimensionnez correctement vSAN : Comparez votre ratio TB/cœur. Si vous dépassez 1 TiB par cœur, passer à un stockage FC ou iSCSI externe pourrait en fait être moins cher sous le nouveau régime de Broadcom.
4. Exécutez un POC sur KubeVirt/OpenShift : Ciblez d'abord les workloads Linux peu critiques. Utilisez le Migration Toolkit for Virtualization (MTV) pour tester les transferts en masse.

L'impact financier : OPEX vs. CAPEX

Broadcom a effectivement mis fin à la planification d'infrastructure basée sur le CAPEX. Tout est maintenant une dépense OPEX récurrente. Pour un environnement de taille moyenne de 2 000 cœurs, un renouvellement VCF se situera probablement entre 700 000 et 1,2 million de dollars par an, selon la densité de votre matériel. En revanche, une empreinte OpenShift ou Nutanix pourrait osciller autour de 500 000 à 800 000 dollars. Le « coût de sortie » – temps des ingénieurs, services professionnels et amortissements matériels – a généralement un ROI de 24 mois. Si vous ne lancez pas la migration d'ici le premier trimestre 2025, vous serez contraint à un renouvellement « le couteau sous la gorge » en 2026.

Nous conseillons à nos clients de maintenir une infrastructure « bi-modale ». Exécutez 20 % de vos applications monolithiques critiques et héritées sur une empreinte vSphere Foundation minimisée, et déplacez les 80 % restants vers une combinaison de cloud public et d'OpenShift on-prem. Cela limite l'influence de Broadcom lors des négociations.

Pour plus d'informations détaillées sur l'optimisation de votre environnement hybride, consultez notre guide sur la minimisation des coûts d'egress de cloud. Si votre équipe a besoin d'un audit technique de votre environnement VMware pour identifier les chemins de migration ou optimiser vos dépenses VCF par nombre de cœurs, consultez nos tarifs de consultation sur techleague.io.