Candidat naturel
Workloads standardisés
VM Linux ou Windows supportées, dépendances connues, réseau reproductible et objectifs de disponibilité mesurables.
VMware Exit
Planifier votre VMware Exit
vers Proxmox VE
Décidez sur des preuves : inventaire, compatibilité, POC, architecture cible, migration par vagues et retour arrière documenté.
Critères d'autorisation
Cinq décisions GO/NO-GO avant le décommissionnement VMware
Ces critères viennent avant le planning et les promesses de bascule. Chaque gate produit une preuve vérifiable. Si un critère échoue, la vague ne part pas : le scénario est corrigé, reporté ou exclu.
- 01
Périmètre qualifié
Inventaire, criticité, dépendances, fenêtres de changement et propriétaires applicatifs sont validés.
- 02
Cible démontrée
Le POC mesure performances, réseau, stockage, sauvegarde, HA et exploitation sur des charges représentatives.
- 03
Pilote réversible
Une première vague non critique valide la procédure, le contrôle applicatif et le retour arrière.
- 04
Vagues autorisées
Chaque lot possède un runbook, un responsable, des critères d'arrêt et une preuve de sauvegarde restaurable.
- 05
Sortie VMware
Décommissionnement après stabilisation, documentation, transfert de compétences et accord métier.
Règle de décommissionnement
La source VMware reste disponible jusqu'à la stabilisation de la cible, la validation des restaurations, l'accord technique et applicatif, la remise des runbooks et l'acceptation formelle du responsable métier.
Pourquoi migrer maintenant ?
Un projet VMware Exit ne se résume pas à changer d'hyperviseur. Il doit rendre explicites les raisons économiques, les contraintes techniques et la capacité des équipes à exploiter la cible.
Renouvellements Broadcom et visibilité budgétaire à réévaluer
Dépendance forte à l'écosystème VMware/Broadcom
Élargissement vers VCF : vSphere, vSAN, NSX et opérations intégrées
Décalage possible entre le périmètre VCF proposé et les besoins réels
Risque opérationnel pendant les renouvellements et migrations
Besoin de simplifier l'exploitation et réduire le lock-in
Proxmox est-il la bonne cible pour tout votre parc ?
Pas forcément. Un VMware Exit crédible commence par segmenter le parc : ce qui peut migrer, ce qui exige un POC et ce qui doit rester temporairement sur VMware ou rejoindre une autre cible.
À prouver en POC
Workloads sensibles
Bases à faible latence, appliances, sauvegarde applicative, HA, réplication ou dépendances vSAN/NSX demandent des tests représentatifs.
À arbitrer
Contraintes éditeur
Une certification, une appliance non supportée ou un contrat imposant vSphere peut justifier une trajectoire hybride ou une exception documentée.
Notre approche de migration
ÉTAPE 01
Inventaire & analyse
Cartographie précise : liste des VMs, consommation CPU/RAM/stockage, dépendances réseau, applications critiques identifiées.
ÉTAPE 02
Architecture cible Proxmox
Conception de l'architecture cible selon les contraintes de production et les objectifs de continuité : segmentation et résilience réseau, stratégie de haute disponibilité, architecture de stockage et sizing adapté aux charges réelles — pas à un gabarit générique.
ÉTAPE 03
Migration par vagues
Priorisation des VMs : non-critiques d'abord, critiques en dernier avec maintien de la production VMware parallèle.
ÉTAPE 04
Validation & bascule
Tests applicatifs exhaustifs, validation SLA, bascule contrôlée, décommissionnement VMware après stabilisation.
Les livrables qui rendent le plan exécutable
Vous ne repartez pas avec une recommandation générique, mais avec des éléments utilisables par l'architecture, les opérations, la sécurité, les achats et les responsables applicatifs.
- Cartographie du parc et matrice de compatibilité
- Architecture cible et hypothèses de dimensionnement
- Rapport POC avec critères GO/NO-GO
- Plan de migration par vagues et calendrier de changement
- Runbooks de migration, validation et retour arrière
- Modèle d'exploitation, sauvegarde, supervision et transfert
Questions fréquentes
Combien de temps dure une migration ?
Cela dépend du périmètre, des contraintes de production, des dépendances applicatives et des fenêtres de migration disponibles. Certaines migrations se réalisent par vagues progressives sur plusieurs mois afin de minimiser le risque opérationnel.
Peut-on revenir en arrière si une vague échoue ?
Chaque vague dispose d'un retour arrière défini et testé lorsque le workload le permet. La source VMware n'est retirée qu'après validation technique, applicative et métier.
Faut-il remplacer les serveurs ?
Non systématiquement. Proxmox VE tourne sur du matériel x86 standard. Nous évaluons si le matériel existant est compatible et suffisant.
Vos équipes peuvent-elles maintenir Proxmox seules après la migration ?
C'est notre objectif. Nous fournissons runbooks, documentation opérationnelle et formons vos administrateurs système.
Proxmox remplace-t-il systématiquement vSAN et NSX ?
Non. Les fonctions vSAN et NSX doivent être décomposées par usage : stockage distribué, micro-segmentation, routage, automatisation et observabilité. Le POC valide les équivalences utiles et documente les fonctions qui exigent une autre brique ou une trajectoire hybride.
Comment sécuriser sauvegarde, PRA et support après le VMware Exit ?
La cible inclut une stratégie de sauvegarde testée, des objectifs RPO/RTO, des scénarios de reprise et un modèle de support explicite. Ces éléments sont des critères GO/NO-GO, pas des tâches reportées après la bascule.
Objectiver la décision avant de migrer
Comparez les coûts, examinez nos retours de production et validez votre architecture sur des workloads représentatifs.
Cadrer votre trajectoire VMware Exit
Décrivez votre parc, vos contraintes et votre échéance pour cadrer la prochaine décision utile.
Évaluer mon plan VMware Exit