Quitter VMware : ce que coûte vraiment une migration vers Proxmox ou Hyper-V

Depuis la refonte des licences VMware, la même question revient dans les PME marocaines : faut-il payer, ou migrer ?

Les contenus disponibles sur le sujet sont rarement neutres. Ce sont soit des arguments de vente pour Proxmox, soit des défenses de VMware. Cet article prend le problème par l'autre bout : dans quels cas la migration est une bonne décision, et dans quels cas c'est une erreur coûteuse.

---

Faites d'abord l'inventaire — sans lui, aucune décision n'est possible

Avant de comparer quoi que ce soit, il faut savoir ce que vous exploitez réellement :

• Nombre d'hôtes physiques, de processeurs et de cœurs — c'est la base du calcul de licence
• Nombre de machines virtuelles, et lesquelles sont critiques
• Fonctionnalités réellement utilisées : haute disponibilité, migration à chaud, répartition de charge automatique, snapshots, réplication
• Type de stockage : disques locaux, NAS, SAN
• Solution de sauvegarde en place et sa compatibilité avec d'autres hyperviseurs
• Outils de supervision et agents installés sur les hôtes

Ce dernier point est celui qu'on oublie systématiquement, et celui qui fait déraper les plannings.

Le critère décisif est le quatrième. Beaucoup d'entreprises paient pour un niveau de licence dont elles n'utilisent qu'une fraction des fonctionnalités — et la migration se justifie d'autant plus. D'autres dépendent réellement de mécanismes avancés, et la migration devient un projet lourd.

---

Les trois scénarios

Scénario 1 — Rester, et renégocier

Souvent écarté trop vite. Si votre parc est réduit, si vos compétences internes sont exclusivement VMware, et si vous exploitez réellement les fonctionnalités avancées, la migration peut coûter plus cher que l'augmentation de licence — en projet, en formation et en risque.

Pour qui : parc réduit, environnement stable, dépendance réelle aux fonctionnalités avancées, absence de compétence alternative en interne.

Scénario 2 — Migrer vers Proxmox VE

Proxmox est un hyperviseur open source de type 1, basé sur KVM, avec gestion de clusters, haute disponibilité, snapshots, réplication et sauvegarde intégrée. Il prend en charge le stockage local, NFS, iSCSI et Fibre Channel — donc les baies SAN existantes.

C'est l'alternative la plus crédible techniquement, et celle qui supprime le coût de licence par processeur.

Le vrai coût n'est pas nul pour autant : projet de migration, montée en compétence de l'équipe ou du prestataire, reconfiguration des sauvegardes, éventuel support commercial souscrit. Ce sont des coûts réels, simplement d'une autre nature.

Pour qui : parc de taille moyenne, besoin de virtualisation solide sans fonctionnalités exotiques, volonté de sortir d'une dépendance à un éditeur unique.

Scénario 3 — Migrer vers Hyper-V

Si votre environnement est déjà largement Microsoft — Windows Server, Active Directory, Microsoft 365 —, Hyper-V mérite d'être évalué sérieusement. L'hyperviseur est inclus dans Windows Server, les compétences sont plus répandues, et l'intégration avec l'existant est naturelle.

Pour qui : environnements Microsoft homogènes, équipes déjà formées à l'écosystème Windows Server.

---

Comment se compare le coût

La comparaison honnête ne se fait pas sur la ligne « licence », mais sur le coût total sur trois ans, projet et formation compris.

---

Le déroulé d'une migration sans coupure

Une migration bien conduite ne nécessite pas d'arrêt général. Le principe est de faire cohabiter les deux environnements pendant la transition.

1. Inventaire et cartographie des dépendances — quelles VM parlent à quelles autres.
2. Monter le nouveau cluster en parallèle, sans toucher à l'existant.
3. Migrer d'abord une VM non critique, et la laisser tourner plusieurs jours.
4. Reconfigurer et tester les sauvegardes sur le nouvel environnement — avant de migrer quoi que ce soit d'important.
5. Migrer par vagues, du moins critique au plus critique, par fenêtres courtes.
6. Conserver l'ancien environnement quelques semaines, comme filet de sécurité.
7. Revalider le plan de reprise d'activité dans sa totalité.

⚠️ L'erreur classique : migrer les machines virtuelles, constater que tout fonctionne, et découvrir trois semaines plus tard que les sauvegardes ne tournaient plus depuis la bascule. La sauvegarde se teste avant, pas après.

---

Les pièges à anticiper

• Les agents installés sur les hôtes — supervision, antivirus, sauvegarde — ne sont pas tous compatibles avec tous les hyperviseurs. À vérifier en amont, pas en cours de route.
• Les pilotes des machines virtuelles changent : une VM migrée depuis VMware a besoin des pilotes du nouvel hyperviseur pour être performante.
• Les licences des systèmes invités peuvent devoir être réactivées après migration.
• Le stockage partagé doit être revalidé : une baie SAN fonctionne avec Proxmox, mais la configuration multipath et les chemins d'accès sont à reprendre.
• La documentation : si personne ne documente le nouvel environnement, vous aurez simplement changé de dépendance.

---

Ce que fait IPBRIDGE

Nous intervenons sur l'ensemble du parcours : inventaire et audit de l'existant, chiffrage comparatif des trois scénarios, conception du nouvel environnement, migration par vagues, reconfiguration des sauvegardes et revalidation du plan de reprise — puis l'exploitation courante, à Casablanca, Rabat, Marrakech, Agadir, Tanger et Essaouira.

Nous incluons systématiquement le scénario « rester et renégocier » dans le chiffrage, parce qu'il est parfois le bon — et qu'un comparatif qui ne l'envisage pas n'est pas un comparatif.

---

FAQ

Proxmox est-il fiable pour un environnement de production ?

Oui. C'est un hyperviseur de type 1 basé sur KVM, utilisé en production dans des environnements exigeants, avec cluster, haute disponibilité et réplication. La vraie question n'est pas sa fiabilité mais la disponibilité des compétences pour l'exploiter — en interne ou chez votre prestataire.

Peut-on garder sa baie SAN existante en migrant vers Proxmox ?

Oui. Proxmox prend en charge le stockage partagé via iSCSI et Fibre Channel. La baie est généralement conservée ; ce sont la configuration d'accès et le multipath qui sont à reprendre.

Combien de temps prend une migration ?

Cela dépend du nombre de machines et de leur criticité. L'essentiel du temps n'est pas la copie des VM mais les phases d'inventaire, de test des sauvegardes et de validation. Une migration précipitée coûte toujours plus cher qu'une migration étalée.

Faut-il tout migrer d'un coup ?

Non, et c'est déconseillé. Les deux environnements peuvent cohabiter le temps de la transition, ce qui permet de migrer par vagues et de conserver un retour arrière possible.

Que devient notre solution de sauvegarde ?

C'est le point à vérifier en priorité. Certaines solutions supportent plusieurs hyperviseurs, d'autres non. Cette vérification doit être faite pendant l'inventaire — pas après la migration.

---

En résumé

La hausse des licences justifie de poser la question, pas de migrer par réflexe. Faites l'inventaire, chiffrez les trois scénarios sur trois ans, et décidez sur le coût total — pas sur la ligne de licence.

Et quel que soit le scénario retenu, testez les sauvegardes avant de bouger quoi que ce soit.

Demander mon bilan IT gratuit · 📞 +212 771 929102