Audit du parc actuel
Avant de planifier, on mesure. L'objectif est d'avoir une cartographie exhaustive de ce qui tourne, sur quoi, sous quelle licence, avec quelle dépendance.
Liste complète VMs / hôtes / clusters / datastores en CSV. Outil : `Get-VM` PowerCLI ou export vCenter natif.
VMware facture désormais au cœur (32 cœurs minimum/socket). Compter avec précision pour comparer aux licences cibles.
vSphere Standard, Enterprise Plus, VVF, VCF ? Date d'expiration ? Subscription post-Broadcom ? C'est le compte à rebours du projet.
Documenter vSwitches standards/distributed, port-groups, dvSwitch, MTU, LAG, NIC teaming. Indispensable pour reproduire dans Proxmox.
vSAN ? FC SAN ? iSCSI ? NFS ? Volumes, snapshots, taux d'occupation, IOPS observés. Conditionne le choix Ceph / ZFS / NFS chez Proxmox.
DRS, HA, vMotion, FT, NSX, vSAN, SRM, Horizon View : noter ce qui doit être remplacé fonctionnellement (Ceph, Corosync, PVE-HA, etc.).
Veeam ? VDP ? Comment sont restaurées les VMs aujourd'hui ? Tests de restore datés ? PBS peut remplacer la majorité des cas.
Windows 2008 R2 ? CentOS 6 ? Ubuntu 14.04 ? Identifier les VMs trop anciennes pour les VirtIO récents — elles devront être stabilisées avant migration.
Top 20 % des VMs qui portent 80 % de la criticité. Ce sont elles qui passent en dernier, après validation parfaite des autres.
Quelle VM dépend de quelle VM ? Bases de données partagées, NFS, fichiers communs. Une migration cassante s'évite avec ce graphe.
Choix de la cible & dimensionnement
Proxmox VE est la cible par défaut chez DYB pour 90 % des migrations sortie-Broadcom. Mais le dimensionnement matériel et les arbitrages stockage / réseau / HA méritent un calcul.
Open-source, GPL, support optionnel. Subscription Proxmox 115 à 1 080 €/CPU/an pour les bug fixes prioritaires. Comparé : Hyper-V, Nutanix AHV, OpenStack.
Compter +20 % de marge sur CPU/RAM (sur-dimensionnement vSphere historique souvent identifié). Cluster 3 nœuds minimum pour HA.
Ceph (équivalent vSAN, distribué, scalable) pour > 5 nœuds. ZFS local répliqué pour 2–3 nœuds. NFS partagé acceptable mais SPOF.
Corosync (HA Proxmox) doit avoir son propre réseau bas-latence (10G recommandé). Séparé du réseau VM et du réseau stockage.
PBS remplace Veeam dans 80 % des cas, gratuit, déduplication globale. Veeam reste pertinent si compatibilité multi-hyperviseurs nécessaire.
Coût matériel (souvent réutilisation possible des hôtes ESXi récents) + projet DYB. Budget signé avant POC.
Préparation infrastructure cible
On bâtit le futur cluster Proxmox EN PARALLÈLE de l'existant VMware. Pas de bascule destructive. Pendant cette phase, vSphere reste en prod.
Disques systèmes en mirror ZFS, séparation des réseaux mgmt/cluster/storage/VM. Chiffrement disque si exigence réglementaire.
Création cluster, ajout nœuds, configuration Corosync sur réseau dédié. Test de basculement HA initial.
Cluster Ceph 3+1 minimum pour réplication, OSDs sur disques dédiés (NVMe ou SSD enterprise). Configuration des pools (1 par usage).
vmbr0 mgmt, bonds LACP avec switches multi-vendor, VLANs reproduits à l'identique. Test connectivité VM par VM.
Datastore dédié (~2× la taille du parc), tests d'écriture, configuration incrémentale et rétention. Réplication offsite optionnelle.
Reproduction des permissions vCenter dans Proxmox : LDAP/AD pour authentification, RBAC pour les permissions par dossier.
Intégration Zabbix / Centreon / Wazuh : SNMP du cluster, métriques Ceph, alerting. Dashboard Grafana pour la direction.
Schéma cluster, procédure d'ajout d'hôte, procédure de restauration, escalade incident. Livré avant la première migration de VM.
POC & validation
On migre 5 à 10 VMs représentatives — un Windows, un Linux récent, un Linux ancien, une base de données, une VM avec snapshot. On valide tout avant d'industrialiser.
Couverture des cas d'usage : OS Windows, OS Linux moderne, OS Linux legacy, base de données, application avec stockage partagé.
Outil : qemu-img convert. Validation des checksums avant/après. Performance lecture/écriture comparée à vSphere.
Windows : install drivers VirtIO depuis ISO Fedora avant bascule. Linux moderne : déjà inclus. Linux legacy : recompilation initrd parfois nécessaire.
Démarrage, performance disque/réseau/CPU, stabilité 72 h, comportement HA (kill nœud), live migration, snapshot, restore PBS.
L'équipe applicative teste : connexion utilisateurs, performance, intégrations, sauvegardes/restores. Go/no-go documenté.
Présentation des résultats POC à la direction. Décision officielle de lancement de la migration de masse, périmètre par lot, planning.
Migration en lots
Pas de big-bang. On migre par lots de 10 à 30 VMs, du moins critique au plus critique. Chaque lot validé avant le suivant. Rollback possible jusqu'à la fin.
Lot 1 : VMs de test/dev. Lot 2 : VMs internes non critiques (DNS, monitoring). Lot 3 : applications standard. Lot 4 : applications critiques. Lot 5 : bases de données et SI cœur.
Date prévisionnelle, fenêtre de bascule (15–30 min par VM standard), responsable côté DYB, contact côté client, plan de retour arrière.
Annonce à J-7 avec impact attendu (coupure courte ou nulle). Note de service. Numéro d'urgence pendant la fenêtre.
Snapshot final côté VMware. Conversion qemu-img incrémentale. Démarrage sur Proxmox. Test connectivité, services, application. Documentation au fil de l'eau.
Backup PBS immédiat sur la VM migrée + test de restore sur cluster pré-prod. Tant que le restore n'est pas validé, la VM n'est pas considérée migrée.
Chaque application est testée par son responsable métier dans les 48 h post-bascule. Anomalies remontées et tracées.
Lots vert/rouge, anomalies traitées, ajustement du processus pour le lot suivant. Comité hebdo de coordination.
Tant que la VM source VMware n'est pas démantelée, retour arrière possible en moins de 30 min. C'est une assurance vie indispensable.
Bascule définitive & cutover
Quand 100 % des VMs sont migrées et validées, on bascule officiellement les flux production : réseau, sauvegardes, supervision, accès utilisateurs.
Plus aucun accès vCenter en lecture/écriture pour les équipes ops. Toutes les opérations passent par l'interface Proxmox.
Désactivation des sondes vCenter dans Zabbix/Centreon. Activation des sondes Proxmox. Validation de l'absence de trous de monitoring.
Si PBS retenu : Veeam désactivé sur les VMs migrées. Validation des chaînes de sauvegarde PBS sur 7 jours minimum avant arrêt complet de Veeam.
Simulation de perte d'un nœud Proxmox + restore d'une VM critique depuis PBS sur cluster vide. Documenté et signé.
Présentation finale, KPIs (downtime cumulé, anomalies, économie réalisée vs estimée). Décision officielle de fin de projet migration.
Annonce à toutes les équipes : la bascule est terminée, les nouveaux flux opérationnels sont en place. Numéro d'urgence reste actif 30 jours.
Schémas finaux, runbook complet, registre des opérations effectuées, formations livrées, contacts. Tout chez le client en clair.
Décommissionnement VMware
Étape souvent oubliée — et pourtant la plus importante côté budget. Tant que vSphere tourne, vous payez. Tant que les hôtes sont configurés en cluster vCenter, vous risquez des erreurs.
On garde vSphere allumé 30 jours après la dernière VM migrée, en lecture seule, pour intervention d'urgence. Aucune VM n'y tourne plus.
Préavis de résiliation, retour des licences, archivage des contrats. Confirmer la fin de la subscription pour le prochain renouvellement.
Export complet : configurations, logs, alarms, audit trail. Conservation 12 mois minimum (audit traçabilité).
Si les hôtes physiques sont réutilisés en nœuds Proxmox supplémentaires : wipe complet, install Proxmox, intégration cluster. Revente sinon.
VM vCenter arrêtée, sauvegardée, archivée puis supprimée. DNS/AD nettoyés. Plus de référence vCenter dans la documentation.
Optimisation post-migration
Une fois en cruise mode sur Proxmox, on tire le maximum de la nouvelle plateforme : densité, automatisation, coûts opérationnels.
Mesurer le ratio CPU/RAM utilisé vs alloué. Souvent, +18 % de densité possible sans dégradation = consolidation matérielle.
Provisioning automatisé des VMs via Terraform Proxmox provider. Configuration via Ansible. Plus de provisioning manuel UI.
Rétention par criticité de VM, vérification automatique mensuelle des restores, alerting si chaîne PBS rompue.
Capacité disponible, prochains hôtes à acheter, évolution Ceph/ZFS, montée de version Proxmox 8 → 9 prévue.
Vérification de l'économie effectivement réalisée vs l'estimation initiale. Inputs pour les prochaines migrations sortie-Broadcom dans le groupe.
Un audit de 30 minutes pour valider votre périmètre.
Vous nous décrivez votre parc, on vous dit ce qui est migrable, ce qui demande une attention particulière, et un ordre de grandeur du projet et du gain. Sans engagement, sans PowerPoint vendeur.
Tout ce qu'on nous demande sur cette checklist
Pour 20–50 VMs sur 2–4 hôtes : 6 à 10 semaines incluant audit, POC, migration en lots et formation. Au-delà de 200 VMs ou avec un cluster vSAN à reconstruire, on bascule sur un projet de 3 à 6 mois découpé en phases.
Oui, c'est même la garantie de zéro risque. Pendant toute la phase de migration, les deux clusters tournent. Une VM est considérée migrée seulement après validation métier ET test de restore PBS. Démantèlement vSphere uniquement après 30 jours de stabilité.
Veeam supporte Proxmox depuis 2024 (Veeam Backup & Replication v12.2+). Mais on recommande Proxmox Backup Server (PBS) : gratuit, déduplication globale, compression Zstd, incrémentales infinies. PBS remplace Veeam dans 80 % des cas avec une économie de licence de 2 000 à 8 000 €/an.
C'est notre cas le plus fréquent. DYB orchestre l'intégralité : audit, POC, migration en lots, formation, exploitation post-bascule. Vos équipes restent décisionnaires sur les arbitrages métier, mais la partie technique est portée par notre équipe Proxmox certifiée.
À 90 % oui. Les phases sont identiques, seule la phase 4 (POC) change : conversion .vhdx au lieu de .vmdk, drivers VirtIO Windows à installer avant bascule. Demandez-nous la version Hyper-V si pertinent pour vous.
Pas encore. Pour l'instant, vous pouvez l'utiliser en ligne — vos cases cochées sont sauvegardées dans votre navigateur (vous pouvez fermer et revenir). Une version PDF arrive prochainement, écrivez-nous pour être notifié.
