JB ServicesJulien Berton

Fin de support de vSphere 8 le 11 octobre 2027 : un an pour préparer la sortie

Par Julien Berton, architecte IT · Publié le · 7 min de lecture

Le support général de VMware vSphere 8 (ESXi 8.0 et vCenter 8.0) s’arrête le 11 octobre 2027. Il reste donc un an aux entreprises qui exploitent encore cette version pour choisir entre un abonnement Broadcom, une prolongation risquée ou une migration. Un an, c’est à peu près le délai nécessaire pour mener une migration propre, sans précipitation.

Le calendrier n’a rien de nouveau, mais il devient concret. Beaucoup d’infrastructures ont été mises à jour de vSphere 7 vers vSphere 8 en 2025 précisément pour repousser la décision. Cette échéance arrive maintenant, et elle tombe au même moment que le durcissement des exigences de sécurité (NIS2, Cyber Resilience Act). Cet article reprend les dates, les options réalistes et un rétroplanning à engager dès cet automne.

Les dates à retenir

  • 2 octobre 2025 : fin du support général de vSphere 7, après une prolongation de six mois accordée par Broadcom.
  • 11 octobre 2027 : fin du support général de vSphere 8 (ESXi 8.0 et vCenter 8.0).

Après la fin du support général, l’éditeur ne publie plus de mises à jour ni de correctifs de sécurité pour la version concernée dans le cadre du support standard. Un hyperviseur reste pourtant l’un des composants les plus exposés d’une infrastructure : ESXi et vCenter ont fait l’objet ces dernières années de vulnérabilités exploitées, notamment par des groupes de rançongiciels qui chiffrent directement les banques de données. Faire tourner la production sur un hyperviseur qui ne reçoit plus de correctifs n’est pas une option durable.

Pourquoi cette échéance pèse plus que les précédentes

Avant le rachat par Broadcom, une fin de support se réglait par une mise à niveau couverte par le contrat de maintenance. Ce n’est plus le cas. Les licences perpétuelles ont disparu au profit d’abonnements regroupés dans des offres packagées (VMware Cloud Foundation, vSphere Foundation), facturés au cœur avec un minimum par processeur. Une entreprise qui possède des licences perpétuelles vSphere 8 n’a pas de chemin vers une version supportée sans souscrire un abonnement.

L’impact financier a été largement documenté. En mai 2025, l’association européenne des fournisseurs de cloud ECCO a fait état de hausses de tarifs comprises entre 800 % et 1 500 % pour certains de ses membres. Dans les PME et ETI que j’audite, la hausse est rarement de cet ordre, mais elle porte souvent sur des fonctionnalités jamais utilisées.

Les quatre options réalistes

1. Souscrire l’abonnement Broadcom

C’est la voie la plus simple techniquement : mise à niveau vers la version suivante, outils inchangés, équipes déjà formées. Elle se justifie quand l’infrastructure utilise réellement les fonctionnalités avancées incluses dans l’offre (vSAN, NSX, automatisation) ou quand des applications métier ne sont certifiées que sur VMware. Le point de vigilance est le coût sur trois à cinq ans, à comparer à périmètre égal.

2. Rester sur vSphere 8 sans support

Techniquement possible, puisque l’hyperviseur continue de fonctionner. Mais plus aucun correctif ne sera publié, ce qui devient difficile à défendre face à un assureur cyber, à un audit ou, pour les entités concernées, face aux exigences de NIS2 sur la gestion des vulnérabilités. Cette option ne peut servir que de transition courte, avec un hyperviseur isolé et des accès d’administration strictement filtrés.

3. Recourir à un support tiers

Des sociétés proposent un support indépendant des éditeurs pour les versions arrivées en fin de vie. Ce support peut aider à tenir quelques mois de plus, mais il ne produit pas de correctifs officiels pour l’hyperviseur. Il achète du temps, sans traiter le fond du sujet.

4. Migrer vers une autre plateforme

Proxmox VE est l’alternative que je rencontre le plus souvent dans les études de faisabilité : open source, basé sur Debian et KVM, avec haute disponibilité, migration à chaud, stockage Ceph intégré, sauvegarde par Proxmox Backup Server et support professionnel en option. Les dernières versions ont réduit l’écart fonctionnel avec vSphere. La version 9.1, publiée en novembre 2025, a ajouté les instantanés de VM avec TPM virtuel et l’utilisation d’images OCI pour les conteneurs LXC. La version 9.2, publiée en 2026, apporte un équilibreur de charge dynamique pour le cluster, attendu par les équipes habituées à DRS, ainsi que WireGuard dans la pile SDN et le noyau Linux 7.0.

Un an, c’est le délai d’un projet sérieux

Une migration d’hyperviseur ne se résume pas à convertir des disques. Lors de la migration d’un environnement vSphere 8 vers Proxmox VE que j’ai menée, la durée d’arrêt a été de 5 à 30 minutes par VM, mais ce résultat repose sur plusieurs semaines de préparation : inventaire, pilote, pilotes VirtIO installés à l’avance, plan de retour arrière. Pour un parc de quelques dizaines à quelques centaines de VM, un rétroplanning raisonnable ressemble à ceci.

Octobre à décembre 2026 : inventaire et décision

  • Inventaire des hôtes, des VM, des versions et des dépendances applicatives.
  • Liste des fonctionnalités vSphere réellement utilisées (HA, DRS, vMotion, réplication, distributed switches, intégrations de sauvegarde).
  • Vérification de la compatibilité matérielle des serveurs et du stockage existants.
  • Comparaison chiffrée des options sur trois à cinq ans, matériel, licences et temps humain compris.

Janvier à mars 2027 : architecture cible et pilote

  • Conception du cluster (trois nœuds minimum pour le quorum), du stockage (Ceph ou baie existante en NFS ou iSCSI) et du réseau (VLAN, agrégation, réseaux séparés pour le cluster et le stockage).
  • Mise en place de la sauvegarde et de la supervision avant toute bascule.
  • Migration pilote de quelques VM représentatives, avec mesure de la durée d’arrêt réelle et test du retour arrière.

Avril à juillet 2027 : bascule par vagues

  • Regroupement des VM par dépendances applicatives, une fenêtre de maintenance par vague.
  • Conservation des VM d’origine éteintes jusqu’à validation par le métier.
  • Formation des administrateurs en parallèle, pour qu’ils exploitent la plateforme dès les premières vagues.

Août à octobre 2027 : marge et décommissionnement

Garder deux à trois mois de marge avant l’échéance permet d’absorber une application récalcitrante, un retard de livraison matérielle ou une fenêtre de maintenance refusée. C’est aussi le moment de décommissionner proprement l’ancien environnement : effacement des banques de données, retrait des comptes de service et mise à jour de la documentation.

Les cas particuliers à anticiper

  • Applications certifiées uniquement sur VMware : à identifier dès l’inventaire, elles peuvent justifier un petit périmètre VMware conservé ou une négociation avec l’éditeur applicatif.
  • Logiciels sous licence liée au matériel virtuel : un changement d’adresse MAC ou d’identifiant de VM peut invalider une licence.
  • Sauvegarde : vérifier que l’outil en place prend en charge la nouvelle plateforme, ou prévoir Proxmox Backup Server.
  • Réseaux techniques et industriels : les serveurs de supervision GTB, les historiens et les passerelles virtualisées doivent garder les mêmes flux et la même segmentation après migration.

Par où commencer

  1. Relever la version exacte d’ESXi et de vCenter sur chaque site.
  2. Faire le point sur les contrats et les licences en cours.
  3. Lancer un audit de l’infrastructure pour disposer d’un inventaire fiable et d’une comparaison chiffrée.
  4. Décider avant la fin de l’année, afin de garder le temps d’un pilote au premier trimestre 2027.

Pour le détail technique d’une bascule, la méthode de migration en 7 étapes reprend la conversion, le pilote et les pièges les plus fréquents.

Encore sur vSphere 8 ? J’accompagne les entreprises de l’inventaire jusqu’à la formation des administrateurs, avec une bascule par vagues et un retour arrière prévu. Voir l’offre migration VMware → Proxmox.

Sources