Exit VMware vers un cloud suisse : checklist

Sans cette liste, tout cutover est du théâtre. Elle se fait une fois, elle sert à toutes les vagues, et c’est elle qui décide du calendrier.

• Clusters, hôtes et nombre de VMs par cluster
• OS et version de chaque VM, avec les fins de support déjà passées
• Dépendances Active Directory : contrôleurs, DNS, GPO
• VLAN et port-groups, avec les règles de filtrage qui les accompagnent
• Chaîne de sauvegarde actuelle et destination réelle des copies
• RPO et RTO attendus par le métier, pas ceux écrits dans un contrat ancien
• Licences Windows Server et SQL : mode de licence, et ce qui est transférable
• Liens site à site, VPN et adresses IP publiques exposées
• VMs sans propriétaire métier identifié : c’est la ligne qui retarde les projets

Posez votre date de renouvellement Broadcom sur un calendrier et remontez. Ordre de grandeur pour un parc de 40 à 120 VMs : T-16 semaines l’inventaire et le choix des vagues ; T-12 le pilote de 10 à 20 VMs, réseau, backup, une app Windows et une Linux ; T-8 l’import par vagues, en commençant par ce qui tolère trente minutes d’arrêt ; T-4 le cutover des dernières charges, fenêtre par fenêtre ; T-0 l’arrêt de vSphere et la fin du contrat. Sous huit semaines, négociez une prolongation Broadcom courte plutôt que de tenir la date : trois mois de licence coûtent moins qu’un cutover raté un dimanche soir. Et décidez tôt qui exécute (section 9) : c’est la contrainte qui déplace le plus le calendrier.

Le pilote n’est pas une démo : c’est le brouillon du runbook que vos vagues suivront. Il doit donc contenir une fois chaque difficulté que vous rencontrerez cent fois, et rien de plus. Un ingénieur Hidora le cadre avec vous.

• Dix à vingt VMs : assez pour révéler les problèmes, assez peu pour recommencer
• Une application Windows et une Linux, pour éprouver les deux chaînes de licence
• Une charge qui tolère trente minutes d’arrêt annoncé
• Au moins une dépendance Active Directory, sinon le lien site à site n’est pas testé
• Un volume à restaurer, pour valider le restore et pas seulement la sauvegarde
• Un propriétaire métier joignable pendant la fenêtre
• Exclue du pilote : la charge la plus critique, et toute VM dont personne ne connaît la topologie

Hikube importe VMDK, QCOW2 et ISO. Le lift-and-shift conserve l’OS : pas de réécriture applicative obligatoire. Windows Server se relicencie à l’usage. Détail des instances : les instances cloud.

• Deux listes de VMs : arrêt de trente minutes toléré, ou réplication à chaud requise
• vCPU comptés par VM Windows avant le pilote : la licence suit l’usage
• Outils invités VMware retirés, agents de la nouvelle plateforme installés
• Démarrage vérifié après import : réseau, disques montés, services applicatifs
• Ne commencez pas par Kubernetes, sauf si l’application est déjà conteneurisée

Recollez prod, DMZ, backup et admin sur des subnets du VPC Hikube. La micro-segmentation NSX complexe ne se traduit pas toujours 1:1, prévoyez un atelier plutôt qu’une traduction automatique. Détail : le réseau privé VPC.

• Table de correspondance VLAN → subnet, une ligne par réseau
• Plan d’adressage arrêté avant le premier import, pas pendant
• Règles de filtrage réécrites et relues, y compris celles que personne ne revendique
• VPN ou lien site à site monté et testé vers l’Active Directory existant
• Résolution DNS validée dans les deux sens
• IP publiques et enregistrements DNS externes recensés, TTL abaissé avant la fenêtre

Ne « activez pas le backup » le jour du cutover. La sauvegarde dans le tenant suisse remplace la brique Veeam ou on-prem une fois les VMs importées, et les copies restent en Suisse. Détail : la sauvegarde managée.

• Sauvegarde active sur les VMs importées avant leur mise en service
• RPO et RTO de la section 1 reportés en politique de sauvegarde
• Un restore complet exécuté dans le pilote, et chronométré
• Emplacement des copies vérifié : elles restent en Suisse
• Ancienne chaîne de sauvegarde conservée jusqu’à la fin de la dernière vague

Une vague se compose de VMs qui partagent une fenêtre et un propriétaire, et commence par ce qui tolère un arrêt annoncé. À la fin de chaque fenêtre, les points ci-dessous se cochent ou ne se cochent pas : s’il en manque un, c’est un retour arrière, pas une réserve à traiter lundi.

• Fenêtre annoncée, propriétaire métier et ingénieur présents
• La VM démarre et tous ses services répondent
• Une écriture applicative de test est visible en base après le basculement
• Temps de réponse dans l’enveloppe mesurée avant migration, pas « ça a l’air normal »
• Sauvegarde de la VM migrée effectuée et vérifiée
• La supervision remonte la VM et ses alertes sont actives
• Aucun ticket utilisateur lié à la bascule dans les deux heures qui suivent

Un rollback documenté après coup n’en est pas un. Il n’existe que si la source reste démarrable et si l’heure de la décision est fixée avant l’ouverture de la fenêtre, quand personne n’est encore engagé.

• VM source laissée éteinte mais intacte sur vSphere, jamais supprimée pendant la vague
• Heure limite de décision fixée avant l’ouverture de la fenêtre
• Une personne nommée prononce le retour arrière : pas un consensus à trois heures du matin
• Bascule DNS et IP réversible, TTL déjà abaissé
• Données écrites pendant la fenêtre : identifiées, puis rejouées ou perdues sciemment
• vSphere maintenu sous licence jusqu’à la validation de la dernière vague

Un ingénieur Hidora cadre l’inventaire, l’atelier réseau et le pilote : c’est le point de départ dans tous les cas, et le livrable est le runbook du pilote. Pour l’usine, trois configurations. Votre équipe déroule avec ce runbook, si elle a les bras. Ou Hidora déroule en prestation de projet sur SOW, facturée au temps passé ou par jalons, en sus du PAYG. Ou un intégrateur partenaire porte le chantier et garde la relation client. Une équipe de deux ou trois personnes ne tient pas cent VMs en plus de son quotidien : arbitrez au cadrage, pas au dernier week-end.

Deux questions à régler avant de signer, pas après. Le support : supervision et astreinte 24×7 de l’infrastructure côté Hidora, guichet support en jours ouvrables 08:00–18:00 CET en français et en anglais, temps de réponse maximum par priorité (P1 critique, 4 h). Vos OS et vos applications restent sous votre supervision, exactement comme sous vSphere ; le partage exact est sur le périmètre du support. La réversibilité : le contrat organise la restitution en fin de relation, modalités, délai de conservation et frais éventuels y sont définis, et c’est lui qui fait foi (les conditions générales). Techniquement, rien n’est propriétaire : les volumes s’exportent en image disque et le stockage objet est compatible S3. Appliquez cette même checklist à votre futur fournisseur, y compris à nous.