Migration VMware à Paris et en petite couronne : une demande simple, un devis gratuit

Sortir de vSphere, ou en réduire l’usage

La migration consiste à transférer des machines virtuelles d’un environnement VMware vers une autre plateforme de virtualisation, vers un hébergement en cloud, ou à réduire la part de l’existant qui reste chez VMware. Elle ne se résume pas à copier des disques : chaque machine porte des dépendances réseau, des pilotes et des sauvegardes qui doivent suivre.

Ce qui change vraiment

Le passage d’un hyperviseur à un autre modifie les outils invités, la configuration réseau, le stockage et la chaîne de sauvegarde. Les VMware Tools doivent être retirés et remplacés par les pilotes de la cible, comme les pilotes VirtIO sous Proxmox VE ou les services d’intégration sous Hyper-V. Sur un serveur Windows, le pilote de stockage de la cible s’installe avant la conversion, sans quoi la machine refuse de démarrer faute de trouver son disque. Sur un serveur Linux, le nom des interfaces réseau peut changer et casser une configuration d’adresse fixe. Les instantanés en cours se consolident avant toute conversion des disques. Le choix de la cible, qu’il s’agisse de Proxmox VE, de Microsoft Hyper-V, de Nutanix AHV, d’un cloud ou d’un modèle hybride, dépend des applications, des compétences disponibles et du coût d’exploitation, bien plus que du seul prix des licences.

Plusieurs situations font naître le projet, et elles se recoupent souvent :

• Un renouvellement de licences qui bouscule le budget : depuis le rachat de VMware par Broadcom, l’offre est passée à des abonnements regroupés, et les nouvelles conditions obligent à comparer l’existant avec d’autres solutions.
• Des hôtes ESXi en fin de support : des serveurs vieillissants que le constructeur ne couvre plus rendent chaque panne plus difficile à résoudre.
• Une infrastructure héritée sans documentation : un ancien prestataire a monté le cluster, et personne ne sait précisément quelles machines dépendent de quoi.
• Une application critique difficile à basculer : l’ERP ou la messagerie ne peut pas être coupé sans préparation, et l’équipe redoute un retour arrière improvisé.
• Une sauvegarde liée à VMware : l’outil qui protège les machines devra lui aussi être remplacé, et le projet doit l’intégrer dès le départ.
• Une équipe qui ne connaît que vSphere : la cible demande une montée en compétence ou un accompagnement, sans quoi l’exploitation après migration reste fragile.
• Un stockage partagé saturé : les performances se dégradent, et la migration devient l’occasion de revoir l’architecture plutôt que de la reproduire à l’identique.

Un projet de migration se découpe en trois temps, et la qualité de chacun conditionne le suivant. Le planning précis se fixe au devis, une fois l’existant connu.

Avant la bascule : inventaire et maquette

Le prestataire recense les hôtes, les machines virtuelles, le stockage, les réseaux virtuels et les dépendances entre applications. Il compare ensuite les cibles possibles au regard des contraintes de licence et d’exploitation. Une maquette convertit quelques machines représentatives pour valider les pilotes, les performances et la sauvegarde avant toute mise en production.

Pendant la bascule : lots et fenêtres d’intervention

Les machines migrent par lots, dans un ordre qui respecte les dépendances et les fenêtres d’intervention convenues. Pour chaque lot, la procédure de retour arrière est écrite avant la bascule, les utilisateurs sont informés, et le contrôle applicatif se fait avant de passer au lot suivant. Chaque machine connaît une courte coupure au moment de sa bascule.

Après la bascule : sauvegarde, supervision et passation

La sauvegarde et la supervision sont adaptées au nouvel environnement, puis une restauration est testée réellement. Le schéma de l’architecture cible, les procédures d’exploitation et la passation à l’équipe qui exploitera la plateforme complètent la prestation.

Deux propositions peuvent annoncer le même périmètre et pourtant ne pas se valoir. Une offre sérieuse justifie la cible par les applications réellement présentes, et non par une liste de fonctionnalités. Elle détaille le plan de bascule lot par lot, avec le retour arrière de chacun, plutôt qu’une date unique.

Elle précise aussi le sort de la sauvegarde : quels outils sont adaptés, comment les restaurations seront testées, et qui en vérifie le résultat. Enfin, elle indique qui exploitera la nouvelle plateforme, avec quelle documentation et quelle période d’accompagnement. Ces points de comparaison pèsent souvent davantage que l’écart entre deux montants.

• Choisir la cible sur le seul prix des licences : comparer aussi le coût d’exploitation, les compétences internes et la compatibilité des applications.
• Migrer sans maquette : tester d’abord quelques machines représentatives permet de découvrir les problèmes de pilotes ou de performance hors production.
• Supprimer la machine source trop tôt : le retour arrière le plus simple consiste à rallumer la machine d’origine, restée éteinte côté VMware jusqu’à la validation applicative du lot. Elle ne se supprime qu’une fois la cible validée et sauvegardée.
• Oublier la sauvegarde : l’outil de sauvegarde doit savoir protéger la cible, et une restauration réellement testée sur le nouvel hyperviseur reste la seule preuve que la protection est en place.
• Basculer tout en une fois : les lots, avec une procédure de retour arrière pour chacun, limitent l’impact d’une erreur à une partie du parc.
• Ne pas documenter l’existant : sans inventaire et sans schéma, la bascule repose sur la mémoire d’une personne, qui peut partir avant la fin du projet.

Une maquette est-elle prévue avant la bascule de production, et quelles machines représentatives seront testées ? Le prestataire doit pouvoir dire lesquelles, et ce que la maquette doit prouver avant de passer à la suite.

Quelle procédure de retour arrière est écrite pour chaque lot ? Une réponse précise indique que la migration a été pensée comme un processus réversible, et non comme un pari sur une seule nuit.

La sauvegarde et la supervision sont-elles adaptées et testées sur la cible ? Demandez comment une restauration sera vérifiée, et qui la valide.

Qui exploitera la nouvelle plateforme, avec quelle documentation ? La réponse conditionne la réussite du projet bien après la bascule, et elle doit figurer dans l’offre.