Migration VMware vers Azure

En 2026, la question n'est plus « faut-il migrer VMware vers Azure ? » mais « par quelle voie, à quel coût et sans s'enfermer ? ». Le changement de licensing imposé par Broadcom a transformé un renouvellement de routine en décision stratégique chiffrable. Ce guide tranche les arbitrages (Azure VMware Solution ou IaaS natif, rester ou partir, rehost ou refactor) avec des fourchettes de coûts réelles, des durées par taille de parc et un fil rouge : ce qui est construit pour vous reste à vous.

Pourquoi migrer VMware vers Azure en 2026

La migration de VMware vers Azure n'est pas un effet de mode. Elle répond à une équation économique et technique qui s'est durcie sur deux ans.

Le séisme Broadcom : ce qui a réellement changé

Le rachat de VMware par Broadcom, finalisé fin 2023, a bouleversé le modèle de licence. Trois ruptures concrètes pèsent désormais sur tout DSI qui exploite une plateforme vSphere :

• Fin des licences perpétuelles. Les licences « achetées une fois pour toutes » ne sont plus commercialisées. Le modèle est devenu par abonnement (subscription), renouvelable annuellement ou pluriannuellement. Une licence perpétuelle existante continue de fonctionner, mais sans support ni mises à jour de sécurité au-delà de sa couverture, ce qui la rend intenable en production.
• Bascule vers VMware Cloud Foundation (VCF). L'offre s'est consolidée autour de VMware Cloud Foundation, le bundle qui regroupe vSphere, vSAN, NSX et les outils de gestion. La facturation se fait par cœur (per-core), avec un minimum de 16 cœurs facturés par CPU physique, même si le processeur en compte moins. Pour les parcs avec beaucoup de sockets faiblement peuplés, l'impact est mécanique.
• Hausse de la facture. Selon les configurations, les renouvellements observés sur le marché se traduisent par des augmentations de coût de licence à deux, voire trois chiffres en pourcentage. À cela s'ajoute, à terme, la fin de support de matériel vieillissant (serveurs hors garantie, baies de stockage en fin de vie) qui rend le statu quo coûteux à maintenir.

Le piège classique : recevoir le devis de renouvellement Broadcom, le payer « pour cette année », et reporter la décision. Or chaque année reportée renchérit la sortie et réduit la marge de négociation. La bonne posture est de chiffrer les trois trajectoires en parallèle dès le premier renouvellement post-Broadcom.

Les vrais déclencheurs d'une migration

Au-delà du licensing, les motivations qui reviennent dans nos missions :

• Sortie du datacenter : fin de bail, consolidation de salles machines, abandon d'un colocation coûteux.
• Obsolescence matérielle : un cycle de renouvellement de serveurs/stockage à plusieurs centaines de milliers d'euros qu'on préfère éviter.
• Élasticité et continuité : besoin d'un PRA crédible, de capacité à la demande, de régions multiples sans acheter du fer en double.
• Modernisation : volonté de sortir progressivement du tout-VM vers du PaaS et des conteneurs, le cloud servant de tremplin.
• Conformité et souveraineté : exigences HDS, RGPD, DORA, hébergement en régions France Central ou Europe.

Cette page traite la voie Azure. Si votre arbitrage de cloud n'est pas tranché, comparez avec la migration VMware vers AWS et appuyez-vous sur le pilier migration cloud en entreprise.

Les deux grandes voies : AVS ou IaaS/PaaS natif

Tout part d'un choix de fond. Migrer VMware vers Azure, ce n'est pas une seule chose, mais deux stratégies très différentes qu'on peut combiner. Dans le vocabulaire des 6R/7R, AVS correspond au rehost / relocate (on déplace le cluster vSphere tel quel) et le natif au replatform / refactor ; le tableau de décision complet et le détail de la conformité sont traités sur le modèle 6R/7R et la conformité de migration. Ici, on se concentre sur le R dominant d'une sortie VMware : le rehost vers AVS.

Voie 1 : Azure VMware Solution (AVS) : le rehost (lift-and-shift)

Azure VMware Solution (AVS) est une plateforme VMware complète exécutée sur du matériel dédié (bare-metal) dans les datacenters Azure. Vous y retrouvez vSphere, vSAN, NSX-T et vCenter Server, managés par Microsoft, identiques à ce que vos équipes connaissent. On parle de rehost ou de lift-and-shift : on déplace les VM telles quelles, sans les modifier.

Avantages : migration rapide, faible risque, aucune réécriture, vos compétences VMware restent valables, downtime minimal grâce à vMotion. C'est la voie privilégiée quand le délai est court (sortie de datacenter imminente) ou quand les applications sont nombreuses, anciennes ou mal documentées.

Voie 2 : IaaS / PaaS Azure natif : replatform ou refactor

Ici, on quitte l'enveloppe VMware. Les serveurs deviennent des machines virtuelles Azure natives (IaaS) posées sur des disques managés (Premium SSD v2, Ultra Disk), et certaines briques sont remplacées par des services managés (replatform : SQL Server vers Azure SQL Managed Instance, partage de fichiers vers Azure Files) voire réécrites pour le cloud (refactor : conteneurisation sur AKS, bascule vers App Services ou des services serverless).

Avantages : coût d'exploitation souvent plus bas à terme, accès au PaaS, élasticité fine, pas d'empreinte VMware résiduelle. Inconvénients : projet plus long, dépendances applicatives à traiter, compétences cloud requises. C'est le cadre des migrations de serveurs vers Azure et des migrations d'application vers le cloud.

La voie hybride, la plus fréquente

Dans la majorité de nos projets, la réponse n'est ni l'un ni l'autre mais les deux dans le temps : AVS comme pont pour sortir vite du datacenter, puis modernisation progressive, application par application, vers l'IaaS et le PaaS natifs. AVS n'est alors pas une prison, mais une étape transitoire assumée, à condition de garder la main sur sa réversibilité, point que nous traitons plus bas.

Comparatif : rester on-prem, AVS ou IaaS natif

Le tableau ci-dessous synthétise les arbitrages. Les coûts sont des ordres de grandeur indicatifs, jamais des prix fermes : ils dépendent du périmètre, du sizing et des engagements.

| Critère | Rester on-prem (renouvellement Broadcom) | Azure VMware Solution (AVS) | IaaS / PaaS Azure natif | |---|---|---|---| | Type de migration | Aucune (statu quo) | Rehost / lift-and-shift | Replatform / refactor | | Délai typique | Immédiat mais récurrent | Court (semaines) | Moyen à long (mois) | | Effort de refactor | Nul | Nul | Modéré à élevé | | Downtime de bascule | — | Quasi nul (vMotion à chaud) | Faible à modéré selon la charge | | Compétences requises | VMware | VMware (inchangées) | Cloud Azure (IaaS/PaaS) | | Coût matériel | CapEx serveurs + stockage | Aucun (inclus) | Aucun | | Coût licence VMware | En forte hausse (VCF par cœur) | Inclus dans AVS ou BYOL VCF | Supprimé | | Coût d'exploitation à terme | Élevé et croissant | Moyen | Souvent le plus bas | | Réversibilité | Native | Élevée (sortie vers IaaS natif) | Élevée (IaC) | | Conformité FR (HDS/RGPD/DORA) | À votre charge | Régions France/Europe | Régions France/Europe | | Accès PaaS / modernisation | Non | Indirect | Direct |

Aucune option n'est universellement « la bonne ». Notre rôle d'intermédiaire indépendant est de vous dire honnêtement quand NE PAS aller sur AVS, par exemple si votre parc est petit, vos applications déjà packageables et votre objectif est de réduire la facture à terme : dans ce cas, l'IaaS/PaaS natif est souvent plus pertinent.

Azure VMware Solution (AVS) en détail

Comprendre AVS évite les mauvaises surprises de dimensionnement et de coût.

Ce que vous obtenez réellement

AVS provisionne un cluster privé de nœuds bare-metal dédiés dans une région Azure. Sur ce cluster tourne une pile VMware complète et managée :

• vSphere / ESXi pour la virtualisation du calcul ;
• vSAN pour le stockage hyperconvergé ;
• NSX-T Data Center pour la mise en réseau et la microsegmentation ;
• vCenter Server pour l'administration, accessible comme on-premises.

Microsoft gère le matériel, l'hyperviseur et le cycle de vie de la plateforme. Vous gardez la main sur vos VM, vos réseaux NSX et votre vCenter. Le modèle de responsabilité partagée s'applique : Microsoft assure le socle, vous restez responsable de vos charges, vos données, vos accès et vos sauvegardes.

Les nœuds : AV36, AV36P, AV52, AV64

AVS se dimensionne en nœuds (et non en VM individuelles). Les familles disponibles diffèrent par leur ratio cœurs / mémoire / stockage NVMe :

• AV36 : nœud historique, équilibré.
• AV36P : davantage de stockage et de mémoire que l'AV36.
• AV52 : nœud à forte densité (beaucoup de cœurs, de RAM et de stockage).
• AV64 : nœud très dense, pour les charges les plus exigeantes.

Le minimum de cluster est généralement de 3 nœuds, pour la tolérance de panne vSAN. C'est un point de coût majeur : même un petit parc paie au moins trois nœuds. Si vos VM consomment surtout du stockage et peu de CPU/RAM, on regarde Azure NetApp Files comme datastore externe pour découpler le stockage du nombre de nœuds et éviter de surdimensionner le cluster juste pour la capacité disque.

Licences : BYOL VCF ou inclus ?

Deux modèles coexistent. AVS peut inclure les licences VMware dans son tarif (modèle bundled), ce qui simplifie la facturation. Alternativement, certaines organisations disposant déjà de droits VCF étudient le BYOL (Bring Your Own License) VCF sur AVS pour valoriser un investissement existant. L'arbitrage dépend de vos contrats Broadcom en cours et de la durée de votre projet AVS : pour un pont temporaire de 12 à 24 mois, le calcul n'est pas le même que pour une cible pérenne. C'est précisément le type d'arbitrage qu'un audit FinOps chiffre avant la décision.

Azure Migrate : découverte, évaluation, business case

Avant toute migration, on mesure. Azure Migrate est la plateforme d'évaluation et de migration de Microsoft. Elle pilote la découverte, l'inventaire et l'analyse de votre existant.

Ce que fait Azure Migrate

• Découverte et inventaire : déploiement d'une appliance Azure Migrate (OVA) dans votre environnement vSphere, qui interroge vCenter et collecte sans agent l'inventaire des VM (CPU, RAM, disques, OS).
• Cartographie des dépendances : visualisation des flux entre serveurs pour ne pas migrer une application en oubliant sa base de données ou son service d'authentification.
• Évaluation (assessment) : recommandations de sizing Azure (taille de VM, type de disque), estimation de coût mensuel, et indicateur de readiness (prêt / à adapter / non éligible).
• Business case : comparaison chiffrée du coût de maintien on-premises face au coût Azure cible, avec prise en compte de l'Azure Hybrid Benefit pour Windows Server et SQL Server.

En complément, RVTools (export depuis vCenter) reste l'outil de référence pour un inventaire rapide et fiable du parc, très utile au sizing AVS comme au sizing IaaS. L'évaluation Azure Migrate et l'export RVTools constituent les fondations d'un audit d'infrastructure cloud sérieux.

Azure Migrate vs Azure VMware Solution : la confusion à éviter

Ces deux noms sèment la confusion. Ce ne sont pas des concurrents :

• Azure Migrate est un outil de méthode : il découvre, évalue et orchestre la migration. Il sert surtout la voie IaaS native (les VM deviennent des VM Azure).
• Azure VMware Solution est une destination : une plateforme VMware managée. On y migre généralement avec VMware HCX, pas avec Azure Migrate.

Dit autrement : Azure Migrate vous aide à décider et à exécuter une bascule vers du natif ; AVS est l'endroit où vous atterrissez si vous gardez VMware.

Méthodes de migration vers l'IaaS natif (le cas hors AVS)

Si votre arbitrage penche vers l'IaaS natif plutôt qu'AVS, la bascule passe par l'outil Migration et modernisation d'Azure Migrate, avec deux modes, sans agent (la réplication s'appuie sur vCenter, rien à installer dans chaque système invité) ou avec agent, puis une réplication continue : copie initiale, deltas, migration de test, puis cutover.

Ces mécaniques (agentless vs agent, réplication initiale/différentielle, snapshots, migration de test) ne sont pas propres au contexte VMware ; nous les détaillons pas à pas sur Azure Migrate : agentless vs agent, réplication et migration de test. C'est aussi cette voie native qui s'applique pour migrer des serveurs hors VMware vers Azure. Sur cette page-ci, le cœur du sujet reste la sortie d'un cluster vSphere entier vers AVS, traitée ci-dessous avec VMware HCX.

VMware HCX : l'outil clé vers AVS

Pour la voie AVS, l'outil de migration de référence est VMware HCX, déployé entre votre vCenter on-premises et le vCenter AVS.

Ce que permet HCX

• HCX Service Mesh : le tunnel sécurisé et optimisé qui relie les deux environnements.
• Extension réseau L2 : étend vos VLAN on-premises jusqu'à AVS sans changer les adresses IP des VM. C'est ce qui rend la migration transparente : une VM migrée garde son IP, ses voisins continuent de la joindre.
• vMotion à chaud : déplacement de VM en cours d'exécution, sans interruption de service, idéal pour les applications critiques.
• Bulk migration : migration de masse planifiée de nombreuses VM en parallèle, avec une courte coupure à la bascule.
• Cold migration : migration à froid (VM éteinte), pour les charges non critiques ou les cas où le redémarrage propre est préférable.

Erreur fréquente que nous corrigeons en mission : oublier de planifier l'extension réseau L2. Sans elle, les VM migrées doivent être ré-adressées, ce qui casse les dépendances et allonge le projet. L'extension L2 est le premier réflexe HCX.

Connectivité et réseau : ExpressRoute, Global Reach, VPN

Aucune migration ne réussit sans un réseau dimensionné. C'est le poste le plus sous-estimé.

• Azure ExpressRoute : lien privé dédié entre votre datacenter et Azure, hors Internet public. C'est le prérequis recommandé pour AVS et pour les gros transferts de réplication : débit stable, latence maîtrisée.
• ExpressRoute Global Reach : interconnecte votre ExpressRoute on-premises avec celui d'AVS, pour que vos sites et AVS communiquent en privé.
• VPN site-to-site : alternative ou complément pour les flux moins volumineux ou les phases de test, sur Internet chiffré.
• Azure Virtual WAN : pour les architectures multi-sites, centralise et simplifie la connectivité à grande échelle.

Le dimensionnement du lien conditionne la durée de la réplication initiale. Un parc volumineux sur un lien sous-dimensionné, et la première copie prend des semaines. On calibre toujours le débit en fonction du volume de données et de la fenêtre de migration souhaitée. Ces choix relèvent d'un conseil d'architecture en amont du projet.

Prérequis et planification

Avant de répliquer la première VM, on verrouille les prérequis.

Côté Azure

• Abonnement et quotas : capacité de nœuds AVS disponible dans la région cible (la dispo varie par région et peut nécessiter une demande de quota), ou quotas de cœurs pour l'IaaS.
• Autorisations : rôles RBAC adéquats, Microsoft Entra ID configuré, accès délimités au plus juste.
• Réseau : ExpressRoute/VPN provisionnés, plages d'adresses planifiées, résolution DNS.
• Région : choix de France Central ou d'une région Europe pour les contraintes de souveraineté et de conformité.

La gouvernance de fond (structure d'abonnements, management groups, Azure Policy, topologie hub-spoke) relève de la landing zone Cloud Adoption Framework, que nous détaillons sur landing zone CAF Azure en détail. Ici, on se concentre sur les prérequis réseau propres à AVS : capacité de nœuds dans la région cible, ExpressRoute et Global Reach vers le cluster privé, extension L2 HCX.

Côté VMware

• Inventaire via RVTools : VM, vCPU, RAM, disques, versions ESXi, snapshots actifs, dépendances.
• Sizing des nœuds AV : traduction de la consommation réelle (et non des allocations théoriques surdimensionnées) en nombre et type de nœuds.
• Nettoyage : suppression des snapshots orphelins, des VM zombies, des templates inutiles : on ne migre pas du déchet.

Piège classique : les caractères non-ASCII dans les noms de fichiers VMDK ou de VM peuvent bloquer certaines opérations de migration. On l'audite et on assainit avant la bascule, pas pendant.

Migration de bout en bout : les étapes

Quelle que soit la voie, la migration suit une trame éprouvée. Voici les phases et leurs ordres de grandeur de durée et de downtime, indicatifs, fonction du parc et du réseau.

| Phase | Objet | Durée indicative | Downtime | |---|---|---|---| | 1. Évaluation | Découverte, inventaire, assessment, business case | 1 à 2 semaines | Aucun | | 2. Plan de vagues | Cartographie des dépendances, regroupement par application, ordre | 1 semaine | Aucun | | 3. Préparation | Réseau (ExpressRoute), landing zone, HCX/appliance, sizing | 1 à 2 semaines | Aucun | | 4. Réplication | Copie initiale + deltas continus | Selon volume et lien | Aucun | | 5. Migration de test | Bascule à blanc dans un réseau isolé, validation | Quelques jours | Aucun (source intacte) | | 6. Bascule (cutover) | Dernier delta, arrêt source, démarrage cible | Par vague | vMotion : ~0 / réplication : minutes | | 7. Finalisation | Décommissionnement source, optimisation, documentation | 1 à 2 semaines | Aucun |

La migration par vagues (wave planning)

On ne migre jamais « tout en une fois ». On organise des vagues :

1. POC / vague pilote : 1 à 2 applications non critiques pour valider la chaîne technique et les runbooks.
2. Vagues de production : regroupées par application (une appli + ses dépendances dans la même vague, jamais éclatées), de la moins à la plus critique.
3. Vague finale : les charges les plus sensibles, une fois la mécanique rodée.

La cartographie des dépendances (Azure Migrate) est ce qui rend ce découpage fiable. Migrer un front-end sans sa base de données, ou inversement, est la cause numéro un d'incident de bascule.

Le choix de principe (big-bang ou migration par vagues, quand l'un se justifie plutôt que l'autre) est traité côté méthode sur big-bang ou migration par vagues. Sur cette page, on reste sur l'exécution opérationnelle des vagues propre à un parc vSphere.

La migration de test : valider sans risque

Point souvent négligé des blogs, essentiel en pratique. La migration de test (test migration) consiste à basculer une VM (ou une vague) dans un réseau Azure isolé, sans toucher à la source qui continue de tourner en production.

On y vérifie : démarrage de l'OS, services applicatifs, connectivité, authentification, performances, intégration des agents (sauvegarde, supervision). Si quelque chose cloche, on corrige et on recommence : zéro impact sur les utilisateurs. Ce n'est qu'après une migration de test concluante qu'on planifie le cutover réel. C'est ce filet qui transforme une migration anxiogène en opération maîtrisée.

Charges spécifiques : SQL Server, bases de données, stockage

Certaines charges méritent un traitement dédié.

• SQL Server : les clusters de basculement (Failover Cluster Instances) et les groupes de disponibilité Always On exigent une attention particulière. Sur des VM Azure, l'extension SQL IaaS Agent apporte gestion automatisée des correctifs, sauvegarde et optimisations. En replatform, on évalue Azure SQL Managed Instance pour supprimer la gestion de l'OS et du moteur.
• Bases de données : selon l'objectif, on garde la VM (rehost), on migre vers un PaaS managé (replatform), ou on optimise le stockage (Ultra Disk pour les IOPS élevés).
• Stockage volumineux sur AVS : Azure NetApp Files branché comme datastore externe permet d'ajouter de la capacité sans ajouter de nœuds, un levier de coût décisif pour les parcs « gros stockage / faible calcul ».

Bonnes pratiques post-migration

La migration ne s'arrête pas au cutover. La valeur se construit après.

Supervision et exploitation

• Azure Monitor et Log Analytics : centralisation des métriques et des journaux, alertes, tableaux de bord. On instrumente dès la première vague, pas après coup.
• Azure Advisor : recommandations automatiques de performance, sécurité, coût et fiabilité.

Sécurité et conformité

• RBAC et Microsoft Entra ID : accès au moindre privilège, élévation juste-à-temps.
• Microsoft Defender for Cloud : posture de sécurité, détection des menaces, conformité par rapport aux référentiels (dont CIS Benchmarks).
• Chiffrement au repos et en transit, segmentation réseau (NSX-T sur AVS, NSG/pare-feu sur IaaS).

Cette phase rejoint nos prestations de sécurisation d'infrastructure cloud et de cybersécurité cloud.

Continuité d'activité et reprise après sinistre

Migrer est l'occasion de (re)construire un PRA crédible :

• Azure Site Recovery : réplication et orchestration de la reprise pour atteindre des objectifs de RTO/RPO définis.
• Azure Backup : sauvegardes managées, rétention, restauration granulaire.
• On formalise le PRA/PCA avec des objectifs de RTO et RPO explicites, et on teste la bascule : un PRA non testé n'est qu'une intention. Voir nos pages dédiées au PRA cloud et au PCA cloud.

Coûts et optimisation : maîtriser la facture

Le cloud mal piloté coûte cher. Le piloter correctement est un métier : le FinOps.

Les leviers d'économie propres à AVS

Sur AVS, deux leviers dominent le TCO et sont spécifiques à la plateforme :

• Réservations de nœuds (Reserved Instances 1 ou 3 ans) : les nœuds AV36/AV36P/AV52/AV64 réservés sur engagement bénéficient de remises substantielles par rapport au tarif à la demande. Décisif quand AVS est une cible pérenne et non un simple pont : on réserve ce qui est prévisible, on laisse à la demande ce qui varie.
• Azure NetApp Files en datastore externe : ajouter de la capacité de stockage sans ajouter de nœuds, le levier de coût clé des parcs « gros stockage / faible calcul » qui, sinon, paieraient des nœuds entiers juste pour de la capacité disque.

Les autres leviers, Azure Hybrid Benefit (réutilisation des licences Windows/SQL), ESU Windows Server, rightsizing générique (sur la consommation réelle, souvent surdimensionnée de 30 à 60 % sous VMware), extinction hors usage et pilotage Azure Cost Management, s'appliquent surtout à la voie IaaS native ; ils sont détaillés sur Azure Hybrid Benefit, ESU et leviers FinOps Azure. Le cadrage du business case avant/après, lui, est traité sur FinOps de migration et business case avant/après.

TCO sur 3 ans : trois scénarios

L'arbitrage se joue sur le coût total de possession à 3 ans, pas sur le devis du mois. Pour un parc de référence de 100 à 300 VM, la logique comparative, toujours à modéliser sur vos chiffres réels, oppose trois trajectoires :

1. Rester on-prem : renouvellement VCF par cœur (en forte hausse) + renouvellement matériel + maintenance + énergie. Coût récurrent croissant, CapEx périodique lourd.
2. AVS : pas de CapEx matériel, OpEx mensuel des nœuds (réductible via réservations et NetApp Files), licences incluses ou BYOL. Migration rapide.
3. IaaS/PaaS natif : OpEx généralement le plus bas à terme (rightsizing + PaaS + Hybrid Benefit), au prix d'un projet plus long et d'un effort de refactor.

Aucun prestataire sérieux ne vous donnera un TCO ferme sans avoir vu votre parc. Méfiez-vous des promesses chiffrées « clés en main » : le bon TCO se construit sur votre inventaire RVTools, vos contrats Broadcom et vos contraintes de conformité. C'est l'objet de notre audit FinOps et de notre optimisation des coûts cloud.

Conformité française et sectorielle : la nuance Azure

Sur la plateforme Azure, deux points méritent d'être posés dans le contexte VMware. Les données peuvent être hébergées en France Central ou dans une région Europe, et les charges de santé s'appuient sur un hébergeur/partenaire certifié HDS. La certification vise l'hébergeur, jamais votre configuration en elle-même (voir notre secteur santé). Pour la finance et l'assurance, AVS comme Azure natif peuvent répondre à DORA à condition d'industrialiser la résilience et de documenter la sortie (voir notre secteur finance).

Le détail des référentiels (RGPD art. 28/32, HDS, DORA, NIS2, SecNumCloud) et l'arbitrage de souveraineté sont traités une fois pour toutes sur conformité RGPD, HDS, DORA et souveraineté en migration cloud. Architecte Cloud s'appuie sur une démarche ISO 27001 et veille à aligner les architectures sur ses exigences.

Réversibilité : AVS comme pont, pas comme prison

La nuance propre au contexte VMware : quitter l'enfermement Broadcom pour s'enfermer dans Azure serait absurde. Si vous passez par AVS, nous le positionnons comme une étape transitoire dont la sortie vers l'IaaS natif est anticipée dès le départ. Le code d'infrastructure (Terraform ou Bicep) reste versionné dans vos dépôts, les comptes cloud sont à votre nom, runbooks et documentation vous sont remis : vous pouvez reprendre la main, changer de partenaire ou de cloud sans repartir de zéro.

Le principe général d'anti-vendor-lock-in et de clause de sortie (comptes à votre nom, IaC dans vos dépôts, plan de réversibilité documenté) est développé sur réversibilité et anti-vendor-lock-in. Si un jour vous reprenez une infrastructure existante, notre approche est détaillée sur reprendre une infrastructure cloud existante.

Stratégie de rollback : le filet propre à une sortie vSphere

La nuance d'une migration depuis vSphere : tant que le cluster source on-premises n'est pas décommissionné, il reste le filet de sécurité. Si une bascule échoue, on rebascule sur la source intacte. C'est pourquoi on ne supprime jamais l'environnement d'origine avant une période de vérification post-bascule (souvent quelques jours à quelques semaines selon la criticité). Chaque vague a son runbook de rollback : critères d'échec, qui décide, comment on revient, en combien de temps. La migration de test réduit drastiquement la probabilité d'y recourir, mais le plan existe toujours.

Le principe générique de plan de rollback et de tests de non-régression, applicable à toute migration, est détaillé sur plan de rollback et tests de non-régression.

Pièges et erreurs fréquentes

Les écueils que nous rencontrons le plus souvent :

• Sous-dimensionnement des nœuds AVS : se baser sur les allocations VMware au lieu de la consommation réelle, et manquer de capacité en production.
• Oubli de l'extension réseau L2 : ré-adressage forcé des VM, dépendances cassées.
• Blocages réseau ExpressRoute : lien sous-dimensionné, réplication interminable, ou routage Global Reach mal configuré.
• Caractères non-ASCII dans les VMDK : opérations de migration bloquées.
• Sous-estimation du delta de réplication : des VM très actives génèrent un delta important ; mal anticipé, il rallonge le cutover.
• Vagues mal découpées : une application séparée de ses dépendances, et c'est l'incident garanti à la bascule.
• PRA oublié : migrer sans reconstruire la continuité, et découvrir le problème le jour d'un incident.

Modernisation : aller au-delà du rehost

Le rehost AVS résout l'urgence Broadcom. Il ne capture pas toute la valeur du cloud. La trajectoire d'optimisation post-pont :

• Conteneurisation des applications éligibles sur AKS (Azure Kubernetes Service), avec les bonnes pratiques (RBAC, network policies, admission control, Pod Security).
• Bascule vers le PaaS : App Services, Azure SQL Managed Instance, services serverless : moins d'OS à gérer, plus d'élasticité.
• IaC partout : Terraform/Bicep pour reproduire, versionner et auditer chaque environnement.

On la mène application par application, par valeur décroissante, sans big bang. C'est le prolongement naturel de la migration, encadré par nos prestations DevOps et infrastructure et de gouvernance cloud.

Faire seul ou avec un partenaire ?

Vous pouvez mener cette migration en interne si vous avez les compétences VMware et Azure, le temps, et la sérénité d'assumer le réseau et la conformité. Beaucoup de DSI choisissent un accompagnement pour des raisons précises :

• Vitesse et risque : un partenaire qui a déjà mené ce type de projet évite les pièges ci-dessus.
• Neutralité : un intermédiaire indépendant Azure Partner vous dit quand AVS n'est pas la bonne réponse, sans intérêt à vendre du nœud.
• Livrables concrets : assessment, plan de vagues, IaC dans vos dépôts, runbooks de bascule et de rollback, documentation.

Architecte Cloud est Microsoft Azure Partner (Solutions Partner : Infrastructure) et AWS Partner (Advanced Tier Services), avec 12 ans d'expertise, +120 projets accompagnés, +40 clients et une satisfaction client reconnue. Les prestataires de notre réseau disposent des certifications Azure Solutions Architect Expert, Azure Security Engineer, CISSP et FinOps Certified Practitioner, dans une démarche ISO 27001.

Combien ça coûte, combien de temps : durée, budget, livrables

Pour une migration VMware vers Azure de périmètre courant, nos missions s'inscrivent dans les fourchettes suivantes, indicatives, sur devis selon le périmètre réel (nombre de VM, voie AVS ou native, complexité applicative, conformité) :

• Durée : 3 à 8 semaines pour un projet de migration cadré (hors modernisation longue), du lancement à la finalisation, vagues comprises.
• Budget indicatif : 25 000 à 80 000 € pour l'accompagnement de migration. Ce montant n'inclut pas la consommation Azure mensuelle (nœuds AVS, VM, stockage, réseau), qui est facturée par Microsoft et que nous optimisons.

Livrables types :

• Évaluation Azure Migrate + inventaire RVTools et business case TCO 3 ans sur 3 scénarios.
• Grille de décision AVS / IaaS natif / hybride argumentée pour votre parc.
• Plan de vagues avec dépendances, durées et fenêtres de bascule.
• Code IaC (Terraform/Bicep) versionné dans vos dépôts.
• Runbooks de migration de test, de cutover et de rollback.
• Documentation d'exploitation, de sécurité et de conformité, remise et à vous.

Premier pas recommandé : un diagnostic qui chiffre vos trois trajectoires (rester / AVS / natif) sur votre parc réel. C'est la décision qui économise le plus d'argent. Lancez votre diagnostic en ligne ou contactez-nous : réponse sous 48 h ouvrées.

Pour aller plus loin

• Pilier du silo : migration cloud en entreprise
• Migration de serveurs vers Azure
• Comparer avec une sortie VMware vers AWS (EVS)
• Migration de serveurs vers AWS
• Migration d'application vers le cloud
• Architecte Azure · nos services · nos secteurs · le guide du cloud

FAQ : Migration VMware vers Azure

Comment migrer une machine virtuelle VMware vers Azure ?

Deux voies. Pour rester sous VMware, on déplace la VM vers Azure VMware Solution avec VMware HCX (vMotion à chaud, sans changer d'IP grâce à l'extension réseau L2). Pour basculer vers une VM Azure native, on utilise Azure Migrate : découverte, réplication continue (sans agent ou avec agent), migration de test, puis bascule. Le choix dépend de votre objectif : rapidité et faible risque (AVS) ou modernisation et coût à terme (natif).

Quelle est la différence entre Azure Migrate et Azure VMware Solution ?

Ce ne sont pas des concurrents. Azure Migrate est un outil de découverte, d'évaluation et de migration, surtout utilisé pour basculer vers des VM Azure natives. Azure VMware Solution (AVS) est une destination : une plateforme VMware complète (vSphere, vSAN, NSX-T, vCenter) managée sur du matériel Azure, vers laquelle on migre généralement avec VMware HCX. Azure Migrate vous aide à décider et exécuter ; AVS est l'endroit où vous atterrissez si vous gardez VMware.

Combien de temps prend une migration de VMware vers Azure ?

Pour un projet cadré, comptez en général 3 à 8 semaines du lancement à la finalisation, vagues incluses, hors modernisation longue. La durée dépend surtout du volume de données (qui conditionne la réplication initiale), du débit réseau (ExpressRoute), du nombre de VM et de la complexité applicative. Un grand parc avec dépendances lourdes se découpe en plusieurs vagues étalées.

Combien coûte Azure VMware Solution (AVS) ?

AVS se facture par nœud (familles AV36, AV36P, AV52, AV64), avec un minimum de 3 nœuds pour la tolérance de panne vSAN. C'est un plancher de coût même pour un petit parc. Le tarif dépend de la région, du type de nœud, des engagements (Reserved Instances / Savings Plans) et du modèle de licence (inclus ou BYOL VCF). On réduit la facture via les réservations et Azure NetApp Files comme stockage externe. Tout chiffrage doit se faire sur devis, après sizing réel.

Faut-il choisir Azure VMware Solution ou des machines virtuelles Azure natives ?

AVS si le délai est court, le parc volumineux ou mal documenté, et que vous voulez conserver vos compétences VMware sans rien réécrire. L'IaaS/PaaS natif si vous visez le coût le plus bas à terme, l'accès au PaaS et une cible pérenne, avec un projet plus long. Souvent, la meilleure réponse est hybride : AVS comme pont, puis modernisation progressive vers le natif. Un intermédiaire indépendant vous dit honnêtement quand AVS n'est pas pertinent.

Quel est l'impact des changements de licences Broadcom sur la migration VMware ?

Broadcom a supprimé les licences perpétuelles au profit d'un modèle par abonnement, consolidé autour de VMware Cloud Foundation (VCF) facturé par cœur avec un minimum de 16 cœurs par CPU. Résultat : des hausses de coût marquées au renouvellement. C'est le principal déclencheur de migration en 2026. La bonne démarche est de chiffrer en parallèle trois trajectoires (rester on-prem, AVS, natif) sur un TCO à 3 ans avant de payer un renouvellement par défaut.

Faut-il conserver ses licences VMware/VCF pour migrer vers Azure ?

Cela dépend de la voie. Vers l'IaaS natif, les licences VMware deviennent inutiles. Vers AVS, deux modèles : licences incluses dans le tarif AVS, ou BYOL VCF si vous disposez déjà de droits à valoriser. L'arbitrage dépend de vos contrats Broadcom en cours et de la durée de votre projet AVS (pont temporaire ou cible pérenne). C'est un calcul FinOps à faire avant la décision.

Qu'est-ce que VMware HCX et à quoi sert-il dans la migration ?

VMware HCX est l'outil qui relie votre vCenter on-premises au vCenter AVS. Il fournit le Service Mesh (tunnel sécurisé), l'extension réseau L2 (les VM gardent leur IP), le vMotion à chaud (déplacement sans interruption), la bulk migration (migration de masse) et la cold migration (à froid). C'est l'outil clé pour migrer vers AVS avec un downtime minimal et sans ré-adressage réseau.

Quel downtime prévoir lors d'une migration VMware vers Azure ?

Avec vMotion à chaud (HCX vers AVS), l'interruption est quasi nulle sur les VM concernées. Avec la réplication (vers le natif ou en bulk migration), le downtime se limite à l'application du dernier delta et au redémarrage côté Azure : souvent quelques minutes à quelques dizaines de minutes par charge. La cold migration implique d'éteindre la VM le temps du transfert. La migration de test permet de mesurer le downtime réel avant le cutover.

Comment évaluer son parc VMware avant la migration (assessment) ?

On combine deux outils : RVTools (export rapide et fiable depuis vCenter : VM, vCPU, RAM, disques, versions, snapshots) et Azure Migrate (découverte sans agent, cartographie des dépendances, recommandations de sizing et de coût, indicateur de readiness). De là, on produit un business case TCO et un plan de vagues. Cette évaluation est le socle de toute décision sérieuse.

Comment réduire les coûts après une migration VMware vers Azure ?

Les leviers FinOps : Azure Hybrid Benefit (réutilisation des licences Windows/SQL), Reserved Instances et Savings Plans sur les charges stables, rightsizing sur la consommation réelle (souvent surdimensionnée sous VMware), extinction des environnements hors usage, Azure NetApp Files pour découpler le stockage AVS du nombre de nœuds, et pilotage via Azure Cost Management. Les économies observées sont réelles mais dépendent du parc, jamais garanties d'avance.

Une migration VMware vers Azure est-elle réversible ?

Oui, si elle est conçue pour. Tant que la source on-premises n'est pas décommissionnée, elle reste un filet de rollback. À plus long terme, la réversibilité repose sur l'IaC (Terraform/Bicep) dans vos dépôts, des comptes cloud à votre nom, une documentation remise et un plan de sortie écrit. AVS peut servir de pont vers le natif sans enfermement. Chez Architecte Cloud, l'anti lock-in est un principe : tout ce qui est construit reste à vous.

La migration VMware vers Azure est-elle conforme RGPD / HDS / DORA ?

Elle peut l'être. RGPD : architectures conçues conformes, hébergement en France Central ou Europe, rôles responsable/sous-traitant documentés (art. 28). HDS : hébergement chez un partenaire certifié HDS pour les données de santé. DORA : pour la finance/assurance, résilience, tests et réversibilité documentés. ISO 27001 : nous nous appuyons sur une démarche ISO 27001. La conformité n'est jamais automatique : elle se conçoit et se documente.