VSHIFTVSHIFTSolutions

Analyse

Ces entreprises qui arrêtent VMware… sans avoir encore choisi la suite

Ce qui se passe réellement dans les DSI depuis Broadcom n'est ni une migration massive ni un statu quo serein. C'est quelque chose de plus difficile à nommer : une pause stratégique dans un vacuum de décision.

2026-05-11·10 min de lecture·VSHIFT Solutions
VMwareBroadcomDSIGouvernanceStratégieArchitecture

Ces entreprises qui arrêtent VMware… sans avoir encore choisi la suite

Il existe une situation que les articles sur la migration VMware ne décrivent pas souvent, parce qu'elle est plus difficile à illustrer qu'un avant/après propre : des entreprises qui ont décidé d'arrêter d'avancer avec VMware, sans avoir encore décidé où aller.

Ce n'est ni une migration. Ce n'est pas non plus un statu quo choisi. C'est quelque chose de plus inconfortable — un gel des investissements, une réduction du périmètre, un arrêt des renouvellements longs, une équipe qui évalue des alternatives sans mandat clair pour les mettre en production. Un état d'entre-deux qui, selon ce qu'on observe sur le terrain depuis 18 mois, concerne probablement autant d'entreprises que celles qui ont effectivement commencé à migrer.

Cette réalité mérite d'être décrite honnêtement.

L'arrêt sans successeur désigné

La dynamique la plus courante que l'on voit n'est pas "nous passons de VMware à Proxmox". C'est "nous ne renouvelons pas au-delà de l'existant, et nous verrons".

Concrètement, cela ressemble à :

  • arrêt des nouvelles acquisitions de licences VMware, sans déploiement de solution de remplacement ;
  • gel des projets d'extension de l'infrastructure virtuelle sur VMware ;
  • non-renouvellement des contrats de support au-delà du minimum nécessaire pour couvrir la production actuelle ;
  • refus de s'engager sur VCF (VMware Cloud Foundation) sans évaluation complète des alternatives ;
  • projets infrastructure mis en pause dans l'attente d'une décision d'architecture qui ne vient pas.

Ce n'est pas de l'inertie. C'est une décision rationnelle dans un contexte d'incertitude. On ne veut pas s'engager davantage avec un éditeur dont la trajectoire commerciale est devenue imprévisible. Mais on n'est pas non plus prêt à migrer.

Ce qui bloque réellement

Ce qui empêche ces organisations de passer à l'action n'est pas toujours technique. Et c'est là qu'une partie de l'analyse habituelle rate sa cible.

En surface, on voit des évaluations de Proxmox, de Nutanix, d'OpenStack, parfois de solutions cloud. Des POCs commencés. Des benchmarks réalisés. Des rapports produits. Mais les décisions ne viennent pas.

La raison profonde est souvent organisationnelle. La migration d'un hyperviseur en production ne peut pas être pilotée uniquement par l'équipe infrastructure. Elle demande un sponsor DSI ou DG avec un mandat clair, un budget pluriannuel validé, une coordination avec les équipes applicatives, un accord des métiers sur les fenêtres de maintenance acceptables, et une gouvernance du risque projet.

Obtenir cet alignement dans une grande organisation prend du temps. Et dans le contexte post-Broadcom, beaucoup de décisions de ce niveau ont été gelées par une question simple : "est-ce qu'on migre vers Proxmox, ou est-ce qu'on préfère attendre et voir si Broadcom corrige sa politique commerciale ?"

Cette question n'a pas encore de réponse définitive dans beaucoup d'organisations. Et pendant qu'elle reste ouverte, le projet avance peu.

Ce que l'inventaire révèle quand on commence à regarder

Pour beaucoup d'entreprises, l'impulsion Broadcom a été la première occasion de faire, sérieusement, un inventaire de leur environnement VMware. Et ce que cet inventaire révèle ralentit souvent la décision davantage.

Ce qu'on découvre régulièrement :

Des dépendances non documentées. Des VMs qui s'appellent entre elles sans que personne n'ait cartographié les flux. Des applications qui dépendent de la résolution DNS interne liée à la configuration vCenter. Des backups configurés sur des datastores qui n'existent plus dans la documentation officielle.

Des workloads sans propriétaire. Des VMs en production depuis quatre ans, créées par quelqu'un qui n'est plus dans l'entreprise. Personne ne sait si elles font encore quelque chose d'utile. Personne n'ose les éteindre. Elles ne seront pas migrées avant d'avoir été identifiées.

Des PRA qui n'ont pas été testés. Les plans de reprise documentés supposent des capacités de l'infrastructure qui n'ont pas été vérifiées depuis le dernier changement majeur. Une migration forcée révélerait ces lacunes au pire moment.

Des processus ITSM liés à vCenter. Des scripts, des automatisations CMDB, des flux de monitoring qui exploitent l'API VMware directement. Remplacer l'hyperviseur exige de reconstruire ces intégrations — un travail qui n'a souvent pas été estimé.

Ce que l'inventaire rend visible, c'est en réalité la dette de gouvernance accumulée pendant les années où VMware fonctionnait silencieusement. La technologie masquait les problèmes de processus. La pression Broadcom retire ce masque.

La pause stratégique : ni migration, ni engagement

L'état dans lequel beaucoup d'entreprises se trouvent aujourd'hui peut se décrire ainsi : elles savent que l'ancienne trajectoire est terminée, mais elles ne sont pas prêtes à s'engager sur la nouvelle.

C'est une posture légitime. Elle a sa propre logique :

On continue à opérer l'infrastructure existante. On évite d'investir dans quelque chose qui sera peut-être remplacé dans 18 mois. On réduit le risque de rupture production en ne forçant pas une transformation que l'organisation n'est pas prête à absorber. On achète du temps pour faire l'inventaire, former les équipes, et attendre que le marché des alternatives se stabilise.

Ce que cette posture coûte, c'est de la prévisibilité. Du point de vue de la gouvernance externe (audits, risk management, comités de direction), une infrastructure dont la trajectoire est floue est plus difficile à justifier qu'une infrastructure avec un plan clair — même si ce plan est "nous restons sur VMware encore 3 ans pendant que nous préparons la migration".

Pourquoi certaines migrations ralentissent intentionnellement

Parmi les organisations qui ont officiellement lancé une migration, une partie d'entre elles ralentit délibérément. Non par manque de volonté, mais parce que la réalité de production impose ses propres contraintes.

Une migration hyperviseur en environnement de production critique, avec des workloads applicatifs qui n'ont pas été testés sur la plateforme cible, avec des équipes qui montent en compétence en parallèle des opérations courantes, avec des fenêtres de maintenance limitées par les contraintes métier — cette migration ne peut pas aller vite sans exposer la production à des risques disproportionnés.

Les organisations qui ralentissent intentionnellement font le calcul suivant : mieux vaut deux ans de migration prudente que six mois de migration agressive suivis d'une coupure majeure. Ce calcul est défendable. La pression à la vitesse vient rarement de l'équipe infrastructure elle-même — elle vient des directions financières qui veulent sortir des coûts VMware, ou des équipes IT qui ont communiqué des délais trop optimistes.

Où VMware reste temporairement le choix le moins risqué

Il existe des environnements où rester sur VMware, même temporairement, est objectivement la décision la plus responsable. Ce n'est pas une capitulation — c'est une lecture réaliste des contraintes.

Ces environnements ont en commun :

  • Des applications critiques dont les éditeurs ne certifient pas encore leur produit sur Proxmox ou les alternatives ;
  • Des workloads Windows fortement intégrés à des fonctionnalités VMware spécifiques (vSAN, NSX, DRS) dont le portage nécessite une refonte applicative ;
  • Des équipes sans expérience Linux en profondeur, pour qui opérer Proxmox en production sans support éditeur structuré représente un risque opérationnel réel ;
  • Des architectures DR multisite qui reposent sur des mécanismes de réplication VMware-natifs non disponibles ailleurs sans changement d'approche.

Prétendre que toutes ces situations peuvent être résolues en 6 mois avec la bonne volonté et un POC concluant serait faux. Ce que l'on rencontre dans ces environnements, c'est souvent un plan de migration à 18-36 mois, avec des phases de coexistence explicitement planifiées et des critères précis pour décider quand le basculement est sûr.

Le problème de fond : la maturité opérationnelle

La question centrale que Broadcom a rendue visible n'est pas "quel hyperviseur choisir". C'est "notre organisation est-elle prête à opérer une infrastructure critique sans s'appuyer sur un éditeur qui absorbe la complexité à notre place ?"

VMware has, pendant 15 ans, proposé une réponse à cette question : oui, si vous achetez les bons licences et le bon support, vous avez une infrastructure opérable même avec des équipes de taille modeste. Cette proposition de valeur est réelle. Elle a structuré beaucoup d'organisations.

Proxmox, Openstack, ou d'autres alternatives open-source distribuent la complexité différemment. Elles sont plus flexibles, moins chères en licences, mais elles demandent plus de compétence interne. Elles ne viennent pas avec un account manager Broadcom qui peut escalader un incident P1 à 3h du matin.

Pour certaines organisations, c'est acceptable. Pour d'autres, ce n'est pas encore le cas — pas parce qu'elles manquent de budget, mais parce qu'elles n'ont pas encore les profils techniques et les processus opérationnels pour assumer cette responsabilité.

Ce qui permettra de sortir de cet état intermédiaire

Les organisations qui réussiront à sortir de cette pause stratégique sont celles qui auront traité le problème à la bonne couche.

Ce n'est pas une question d'avoir fait le bon choix technologique. C'est une question d'avoir mis en place les conditions pour que n'importe quelle décision technologique soit exécutable :

  • Un inventaire complet et maintenu de l'environnement existant ;
  • Des propriétaires applicatifs identifiés pour chaque workload ;
  • Des PRA testés et validés sur la plateforme cible avant le basculement ;
  • Une équipe avec les compétences ou le support externe nécessaire pour opérer ce qu'elle va déployer ;
  • Un sponsor avec un mandat et un budget pluriannuel ;
  • Un plan de rollback valide jusqu'à la dernière phase.

Ces conditions ne sont pas spectaculaires. Elles ne font pas de bons titres. Mais ce sont elles qui font la différence entre une migration qui se passe bien et une migration qui génère des incidents pendant six mois.

La réalité de ce que vivent beaucoup d'entreprises aujourd'hui n'est pas un drame. Ce n'est pas non plus un retard inexcusable. C'est une transformation organisationnelle difficile, ralentie par des contraintes réelles, dans un contexte de marché qui n'a pas encore trouvé son équilibre. Le reconnaître honnêtement est le point de départ pour avancer dans la bonne direction.