« On va migrer le week-end, comme ça personne ne s’en rendra compte. » C’est souvent la première idée qui vient. Et souvent la mauvaise, si tout le reste n’a pas été préparé en amont. Une migration sans interruption ne tient pas au timing, elle tient à la méthode.
1. Cadrage : cartographier avant de bouger quoi que ce soit
Avant de déplacer une seule machine virtuelle, il faut savoir exactement ce qui existe : dépendances entre serveurs, fenêtres de maintenance acceptables, applications critiques qui ne tolèrent aucune coupure. C’est l’étape la plus négligée, et celle qui évite le plus de mauvaises surprises.
2. Conception : prévoir le plan B avant le plan A
Une architecture cible claire, un planning détaillé, et surtout une procédure de retour arrière testée — pas improvisée le jour J si ça tourne mal. Sur une migration de 250 machines virtuelles, le plan de rollback compte autant que le plan de migration lui-même.
3. Exécution : migrer par vagues, pas en bloc
Basculer tout d’un coup maximise le risque. Migrer par lots — en commençant par les services les moins critiques — permet de valider la méthode sur des enjeux faibles avant de s’attaquer aux systèmes sensibles. Les outils de migration à chaud (vMotion, Storage vMotion et équivalents) permettent souvent de déplacer une charge de travail sans même interrompre le service.
4. Stabilisation : la migration ne s’arrête pas à la bascule
Les premiers jours après bascule sont ceux où les problèmes de performance ou de configuration remontent. Une période de surveillance renforcée, avant de passer la main aux équipes internes, évite de découvrir un souci trois semaines plus tard.
C’est cette méthode qui m’a permis de faire migrer 250 machines virtuelles d’une plateforme VxRail/vSphere vers une solution Huawei DCS pour un grand groupe international, sans interruption de service. Le principe reste le même, que vous ayez 250 VMs ou 12.