Cet article s’inscrit dans notre accompagnement migration VMware. Pour le cadre décisionnel complet, voir Sortir de VMware : cinq phases, quatre points de sortie. Pour le détail technique d’une migration unitaire, voir Anatomy of a Cold VM Migration.
Le problème
Quand un DSI demande combien coûte la migration du parc VMware, les devis répondent en euros : licences de la cible, outils de migration, jours de prestation. Personne ne répond en mois. Or c’est le temps — pas l’argent — qui détermine si le projet aboutit ou s’enlise. Les licences se négocient en une semaine. La recette applicative de 200 VMs prend six mois.
Ce que les devis chiffrent
Un devis de migration typique inclut quatre postes : le coût de la plateforme cible (souscriptions Proxmox, licences OpenStack, ou renouvellement VMware Cloud Foundation), l’outillage de conversion (Yonder, virt-v2v, ou un outil éditeur), les jours de prestation d’un intégrateur, et parfois le matériel si l’infrastructure est renouvelée. Ces postes sont visibles, comparables, et négociables.
Ce que les devis ne chiffrent pas
Le temps réel d’une migration se distribue sur cinq phases. Les trois premières consomment la majorité du calendrier avant même que la première VM ne soit convertie.
Phase 1 — Audit et cadrage
Inventaire exhaustif du parc : combien de VMs, quels systèmes invités, quelles dépendances applicatives, quels SLA. Pour 50 VMs, comptez deux à trois semaines. Pour 200 VMs, six à huit semaines. Pour 500 VMs, trois à quatre mois. Ce n’est pas un inventaire technique — c’est une cartographie des contraintes métier. Chaque VM qui dépend d’un certificat, d’une licence liée au matériel, ou d’un agent de monitoring spécifique ajoute du temps. Le cadrage inclut aussi le choix de la cible, la validation de la compatibilité matérielle, et la définition des critères de recette.
Cette phase est la seule dont le résultat ne se perd jamais. Même si la cible change — de Proxmox vers OpenStack, ou retour vers VMware Cloud Foundation — l’inventaire, la cartographie des dépendances et les critères de recette restent valides. Tout le reste recommence à zéro.
Phase 2 — Architecture et pilote
Déploiement de la plateforme cible, configuration du réseau, du stockage, de la sauvegarde, de la supervision. Puis migration d’un lot pilote de 5 à 10 VMs représentatives. Le pilote sert à valider la méthode, à mesurer les temps de conversion réels, et à identifier les problèmes qui n’apparaissent pas dans la documentation. Comptez quatre à six semaines pour un environnement de taille moyenne.
Phase 3 — Vagues de migration
Les VMs sont migrées par vagues, généralement par groupe applicatif. Chaque vague comprend la conversion des disques, l’adaptation du système invité (drivers, réseau, initramfs), le test de démarrage, et la recette applicative. Pour une VM individuelle, la conversion technique prend entre dix minutes et deux heures selon la taille des disques. La recette applicative prend entre une heure et plusieurs jours selon la complexité de l’application.
Le goulot d’étranglement n’est jamais la conversion technique. C’est la fenêtre de maintenance : quand l’équipe métier accepte-t-elle d’arrêter l’application pour la recette ? Pour les applications critiques, ces fenêtres sont rares, courtes, et souvent reportées. C’est là que les calendriers glissent.
Le temps invisible : formation et transfert de compétences
Un poste que les devis ne chiffrent presque jamais : le temps nécessaire pour que l’équipe d’exploitation devienne autonome sur la nouvelle plateforme. Un administrateur VMware expérimenté ne devient pas un opérateur Proxmox ou OpenStack en un jour. Il faut compter la formation formelle (trois à cinq jours pour Proxmox VE, cinq à dix jours pour OpenStack), puis la montée en compétence en conditions réelles : premiers incidents, premières mises à jour, premiers dimensionnements de stockage Ceph. Ce temps n’apparaît dans aucun devis, mais il conditionne la capacité de l’équipe à exploiter le parc après la migration.
Deux autres postes de temps passent souvent inaperçus. La réécriture des procédures d’exploitation — scripts de sauvegarde, runbooks d’incidents, procédures de PCA/PRA — consomme des semaines, surtout dans les environnements soumis à des normes (ISO 27001, HDS, PCI-DSS). Et le suivi post-migration — la surveillance rapprochée des premières semaines de production sur la nouvelle plateforme — mobilise l’équipe au-delà de la date de bascule officielle.
Phase 4 — Décommissionnement
Extinction des anciens hôtes VMware, récupération du matériel, résiliation des contrats de support. Cette phase paraît simple mais prend du temps : il faut s’assurer que chaque VM a été validée en production sur la nouvelle plateforme, que les sauvegardes fonctionnent, que le monitoring est en place, et que personne ne pointe encore vers un ancien hôte. Les dépendances DNS, les scripts de déploiement, les règles de firewall qui référencent les anciennes adresses IP : tout cela doit être nettoyé. Comptez quatre à huit semaines après la dernière vague.
Ordres de grandeur
| Taille du parc | Phase 1 (audit) | Phase 2 (pilote) | Phase 3 (vagues) | Phase 4 (décom.) | Total estimé |
|---|---|---|---|---|---|
| 50 VMs | 2–3 semaines | 3–4 semaines | 4–8 semaines | 2–4 semaines | 3–5 mois |
| 200 VMs | 6–8 semaines | 4–6 semaines | 12–20 semaines | 4–6 semaines | 6–10 mois |
| 500 VMs | 3–4 mois | 6–8 semaines | 6–12 mois | 6–8 semaines | 12–20 mois |
Ces fourchettes supposent une équipe dédiée, un cadrage stable, et des fenêtres de maintenance régulières. Elles ne tiennent pas compte des changements de stratégie en cours de route.
Le piège des deux tiers
Selon une étude CloudBolt de février 2026 portant sur 302 décideurs IT, près des deux tiers des organisations ont changé de stratégie de migration au moins deux fois depuis l’acquisition de VMware par Broadcom. Chaque changement de cap — passer de Proxmox à OpenStack, revenir vers VMware Cloud Foundation, pivoter vers le cloud public — invalide une partie du travail déjà réalisé. L’architecture cible change, les tests pilotes sont à refaire, les procédures de conversion doivent être adaptées.
Le coût de ces changements n’est pas dans les outils ou les licences. Il est dans les mois perdus. C’est pourquoi la phase 1 — le cadrage — mérite un investissement disproportionné par rapport à sa durée apparente. Un cadrage solide réduit la probabilité de changer de cap. Et même si le cap change, l’inventaire et la cartographie survivent.
Rester sur VMware a aussi un coût en temps
Rester sur vSphere 8 jusqu’à la fin de support général (11 octobre 2027) ne coûte rien en migration, mais impose ses propres échéances. La montée vers VMware Cloud Foundation, si elle est choisie, est elle-même un projet de migration : nouveau modèle de licence par cœur, intégration de NSX et vSAN dans un bundle, requalification des procédures d’exploitation. Le renouvellement du contrat Broadcom doit être négocié avant l’échéance, pas après — c’est là que le levier de négociation existe. Et après octobre 2027, un parc vSphere 8 sans support ne reçoit plus de correctifs de sécurité, ce qui pose un problème pour les environnements soumis à des exigences de conformité.
L’option « rester » est légitime. Mais elle n’est pas gratuite en temps. Elle demande un plan documenté avec ses propres échéances.
Ce que cet article ne traite pas
- Les comparatifs de prix de licences VMware, Proxmox, OpenStack (volatils, dépendent du devis Broadcom et de la taille du parc).
- Les détails techniques de la conversion d’une VM individuelle (traités dans l’article sur l’anatomie d’une cold migration).
- Le choix entre Proxmox et OpenStack comme cible (article dédié).
- Le dimensionnement matériel de la plateforme cible.
Si vous avez besoin d’un cadrage pour votre parc, notre prestation d’audit et de conseil en architecture couvre la phase 1 de bout en bout.
Sources : CloudBolt, State of VMware Migration, février 2026 (302 décideurs IT). Broadcom, cycle de vie vSphere 8, fin de support général 11 octobre 2027. EC INTELLIGENCE, retours de missions de migration 2024–2026.
