VMware vers Proxmox, comment préparer votre migration ?

Un renouvellement de contrat, une évolution des coûts ou le besoin de reprendre la main sur son infrastructure peuvent conduire à étudier Proxmox VE. Mais une migration depuis VMware ne se résume pas à convertir des disques virtuels. La décision dépend aussi du stockage, du réseau, des sauvegardes et des applications qui doivent continuer à fonctionner. Avant de choisir une méthode de transfert, il faut donc vérifier ce que l’environnement cible devra réellement assurer.

Partir des besoins avant de choisir l’hyperviseur

Identifier ce qui motive le changement

La première question est simple : quel problème cherchez-vous à résoudre ? Un coût de renouvellement, une dépendance contractuelle et une limite technique ne conduisent pas nécessairement à la même réponse. Définissez donc vos objectifs, votre échéance et les fonctions indispensables avant de comparer les plateformes.

Proxmox propose un assistant d’import de VM VMware ESXi. Sa démonstration officielle couvre aussi les adaptations et vérifications après import, notamment autour des pilotes VirtIO. L’outil facilite ainsi le transfert, mais ne valide pas à lui seul le fonctionnement de votre application (présentation officielle de l’assistant d’import).

Inventorier les VM et leurs dépendances

Relever plus que le nombre de machines

Pour chaque VM, documentez le système invité, les ressources, les disques, le mode de démarrage et les interfaces réseau. Relevez également les dépendances particulières : périphérique présenté directement à une VM, chiffrement, licence applicative ou matériel spécifique. Ensuite, identifiez les ajustements à tester sur la cible.

Demandez aussi aux éditeurs de vos applications de confirmer le support de l’environnement envisagé. Une application qui démarre dans un test ne constitue pas, à elle seule, une validation de son support contractuel en production.

Regrouper les machines par service métier

Une application peut dépendre d’une base de données, d’un annuaire, d’un serveur de fichiers et de tâches planifiées. Établissez donc la liste des flux et un ordre de migration. Vous éviterez de traiter indépendamment des machines qui doivent être testées ensemble.

Valider le stockage, le réseau et la disponibilité

Choisir un stockage adapté à la cible

Proxmox VE prend en charge plusieurs architectures, notamment du stockage local et partagé. Les possibilités de snapshots, de réplication ou de déplacement des VM varient selon le choix retenu. Consultez donc les capacités du backend et la documentation de la version cible (guide d’administration Proxmox VE).

Si votre infrastructure utilise vSAN, une baie ou des mécanismes spécifiques, décrivez les fonctions attendues avant de définir leur remplacement. Un projet Ceph, par exemple, doit être dimensionné et exploité comme un système de stockage à part entière. Il ne doit pas être choisi uniquement parce qu’il figure parmi les options disponibles.

Reconstituer les flux réseau

Préparez la correspondance entre les réseaux source et cible : VLAN, bridges, adresses, routage et filtrage. Vérifiez aussi les réseaux de gestion, de stockage et de migration. Les tests doivent confirmer les communications autorisées, mais également le maintien des séparations prévues.

Tester la disponibilité dans des scénarios de panne

Le cluster Proxmox utilise un mécanisme de quorum pour conserver un état cohérent. La documentation décrit notamment les exigences du réseau de cluster. La disponibilité dépend donc de l’architecture retenue, des communications et de l’accès aux disques (documentation du cluster).

Prévoyez ensuite des tests encadrés de perte d’hôte ou de lien réseau. Mesurez le délai de reprise du service et la capacité restante. Un redémarrage automatique de VM après une panne ne signifie pas que l’application n’a subi aucune interruption.

Vérifier les sauvegardes et la restauration

Contrôler les fonctions de votre outil actuel

Changer d’hyperviseur oblige à réexaminer les versions compatibles, les licences et les opérations disponibles. Par exemple, Veeam documente la sauvegarde de VM Proxmox et la restauration de sauvegardes VMware vers Proxmox. Ces possibilités doivent être rapprochées du build et des prérequis réellement déployés (fonctions Proxmox VE dans Veeam).

Les limites comptent autant que la liste des fonctions. Veeam précise notamment que la restauration des paramètres HA des VM n’est pas prise en charge par son plug-in Proxmox. Vérifiez donc ce que votre procédure doit reconstruire après la restauration (limitations documentées par Veeam).

Faire un test avant la bascule

Restaurez une VM pilote dans un environnement isolé, puis contrôlez ses données et son application. Vérifiez également l’accès aux anciennes sauvegardes pendant la transition. Enfin, prévoyez la première sauvegarde de production sur la cible : la migration doit inclure la protection du nouvel environnement.

Préparer le pilote et le retour arrière

Choisir une VM représentative

Un pilote utile ressemble aux charges que vous devrez migrer. Choisissez une machine avec un propriétaire identifié, un test applicatif défini et un risque maîtrisé. Relevez les performances avant et après, puis mesurez le transfert, les adaptations et la validation complète du service.

Pour Windows, contrôlez notamment les pilotes et la configuration des interfaces après import. La démonstration Proxmox présente une étape de démarrage avec VirtIO SCSI et des vérifications dans le gestionnaire de périphériques (exemple officiel d’import d’une VM Windows).

Définir le traitement des données après la bascule

Le retour arrière doit préciser qui décide, jusqu’à quand et selon quels critères. Il doit surtout traiter les données créées sur la cible. Redémarrer simplement l’ancienne VM peut rétablir un état dépassé et faire perdre des transactions récentes.

Découper le projet en vagues

Après le pilote, regroupez les applications selon leur criticité et leurs dépendances. Pour chaque vague, fixez les responsables, les tests et le créneau de décision. Conservez ensuite une période d’observation avant de retirer les ressources source, selon les contraintes de contrat et de sécurité.

Comparer le coût total et le support

Intégrer la transition et l’exploitation

La comparaison doit couvrir une durée commune et un niveau de service comparable. Chiffrez les souscriptions, le matériel, le stockage, la sauvegarde, la formation et les jours d’intervention. Ajoutez aussi la coexistence temporaire des plateformes et le maintien des outils nécessaires au retour arrière.

Lire précisément les engagements de support

Proxmox facture ses souscriptions par socket physique occupé. Les niveaux se distinguent notamment par le support. Au moment de la rédaction, le 24/7 Premium est disponible depuis le 19 octobre 2026, tandis que celui de Standard est annoncé d’ici fin 2026. Un délai de première réponse ne doit pas être confondu avec un délai de rétablissement (offres et conditions de support Proxmox).

Précisez enfin la répartition entre votre équipe, votre prestataire et l’éditeur. Le support du produit et l’exploitation quotidienne de vos applications sont deux responsabilités à organiser dans le projet.

Les conditions à réunir avant la bascule

• Les applications, leurs propriétaires et leurs dépendances sont inventoriés.
• Les compatibilités et conditions de support des éditeurs sont vérifiées.
• Le stockage, les flux réseau et les capacités en cas de panne sont validés.
• La méthode de transfert a été testée sur des VM représentatives.
• Une restauration a été réalisée dans l’environnement cible.
• Le retour arrière prévoit le traitement des nouvelles données.
• Les responsables métiers ont validé les tests et l’interruption acceptable.
• La supervision, la sauvegarde et le support sont prêts pour l’exploitation.