Migration VMware vers AWS

Le rachat de VMware par Broadcom a transformé une décision technique en décision financière : licences perpétuelles supprimées, abonnement par cœur, factures multipliées par deux à dix. Migrer vers AWS n'est plus une option d'avenir, c'est un arbitrage budgétaire qui se pose maintenant. Cette page est le guide de référence, à jour de la situation 2026, pour comprendre vos voies de sortie, choisir la bonne cible AWS, chiffrer le coût réel et conduire le projet sans interruption de service.

Mise à jour : juin 2026. Depuis le 30 avril 2024, VMware Cloud on AWS n'est plus commercialisé par AWS : il reste accessible uniquement via Broadcom et ses revendeurs. Le chemin AWS recommandé pour faire tourner du VMware « tel quel » est désormais Amazon Elastic VMware Service (Amazon EVS), passé en disponibilité générale en 2025. Beaucoup de pages francophones n'ont pas intégré ce changement : si votre prestataire vous parle encore de « VMware Cloud on AWS » comme d'une offre AWS standard, le diagnostic mérite d'être actualisé.

Pourquoi migrer VMware vers AWS en 2026 : le contexte Broadcom

Comprendre la migration VMware vers AWS suppose d'abord de comprendre ce qui pousse des milliers de DSI à y réfléchir cette année. Ce n'est pas un effet de mode technologique : c'est une rupture contractuelle imposée par Broadcom.

Fin des licences perpétuelles et passage à l'abonnement

Avant le rachat, l'écrasante majorité des parcs VMware reposaient sur des licences perpétuelles : vous achetiez une fois, vous payiez un support annuel modéré, et vous gardiez le droit d'usage indéfiniment. Broadcom a mis fin à ce modèle. Désormais, vSphere, vSAN et NSX se consomment par abonnement, facturé par cœur de processeur (avec un plancher minimal de cœurs facturés par socket), et les briques sont regroupées en suites comme VMware Cloud Foundation (VCF) ou VMware vSphere Foundation (VVF). Les SKU à la carte qui permettaient de n'acheter que ce dont on avait besoin ont largement disparu.

Conséquence concrète : une entreprise qui exploitait un cluster avec quelques fonctions activées se retrouve à payer une suite complète, sur la totalité des cœurs physiques, en abonnement renouvelable. Les hausses constatées sur le marché s'échelonnent typiquement de ×2 à ×10 selon le profil de licences antérieur, la densité de cœurs et les fonctions réellement utilisées. Un parc qui sous-exploitait sa densité processeur ou qui n'avait souscrit que vSphere standard est le plus durement touché.

Pourquoi cela change la décision de migrer

Tant que VMware coûtait quelques milliers d'euros par an et par hôte, le statu quo était rationnel : la plateforme fonctionnait, les équipes la maîtrisaient, et migrer coûtait plus cher que rester. La structure de coûts a basculé. Quand l'abonnement triple ou décuple, l'arbitrage « rester vs partir » se réouvre, et le coût d'un projet de migration, qui s'amortit sur trois à cinq ans, devient comparable, parfois inférieur, au surcoût de licence cumulé.

L'erreur à éviter. Migrer dans la panique, sans modèle de coûts, en supposant que « le cloud coûte forcément moins cher ». C'est faux pour certains workloads (voir plus bas le piège économique du cloud). La bonne démarche consiste à modéliser le coût réel de chaque cible, y compris rester sur VMware, avant d'engager le moindre euro. C'est précisément le rôle d'un audit d'infrastructure cloud indépendant.

Vos options de sortie : trois familles, pas une

Face à Broadcom, il n'existe pas une réponse unique mais trois familles d'options, qu'un décideur doit poser à plat avant de choisir AWS :

1. Rester sur VMware et absorber la hausse, défendable si le parc est petit, amorti, stable, et si une migration coûterait plus cher que le surcoût d'abonnement sur l'horizon visé.
2. Changer d'hyperviseur sur site (Proxmox VE, Nutanix AHV, Microsoft Hyper-V, Red Hat OpenShift Virtualization ou XCP-ng / Vates) : on garde ses serveurs, on remplace la couche de virtualisation. Évite le cloud mais demande de nouvelles compétences et un effort de re-plateformage des VM.
3. Migrer vers le cloud : AWS, mais aussi Azure VMware Solution ou Google Cloud VMware Engine. On externalise l'infrastructure et on ouvre la porte à la modernisation.

Cette page traite la voie AWS en profondeur, mais un conseil honnête commence par reconnaître que les trois familles sont légitimes selon le contexte. Nous présentons plus loin les alternatives sans parti pris : c'est la marque d'un accompagnement indépendant, pas d'un revendeur mono-cloud.

Comprendre la facturation par cœur de Broadcom

Pour modéliser correctement le « avant », il faut décortiquer le mécanisme Broadcom. La facturation s'effectue par cœur physique de processeur, avec un minimum facturé par socket (un plancher s'applique même si le processeur a moins de cœurs que ce plancher). Conséquence : un parc moderne à forte densité (processeurs à grand nombre de cœurs) voit sa facture grimper mécaniquement, car chaque cœur compte. Les organisations qui avaient consolidé agressivement leurs hôtes pour réduire le nombre de licences vSphere se retrouvent paradoxalement pénalisées par cette densité.

Autre effet : le regroupement en suites. Là où l'on pouvait acheter vSphere seul, l'offre pousse vers VMware Cloud Foundation (VCF), qui embarque vSphere, vSAN, NSX et la couche d'automatisation, qu'on les utilise ou non. Pour une organisation qui n'exploitait que la virtualisation de base, c'est payer une suite complète pour une fraction de ses fonctions. Ce mécanisme explique l'amplitude des hausses (×2 à ×10) : elle ne dépend pas seulement du prix unitaire, mais du passage forcé à un périmètre fonctionnel et à un nombre de cœurs facturés bien supérieurs.

Conséquence pratique. Avant même de parler d'AWS, le premier livrable utile est un état des lieux de votre exposition Broadcom : combien de cœurs physiques, quelle suite imposée au renouvellement, quel surcoût annuel à horizon 3 ans. Ce chiffre est la borne haute contre laquelle se compare le TCO AWS. Sans lui, aucun arbitrage rationnel n'est possible.

Comment migrer une VM VMware vers AWS : les 7 étapes

Avant d'entrer dans les détails techniques, voici la réponse directe à la question la plus posée. Migrer un parc VMware vers AWS suit une trajectoire en sept étapes, quel que soit le chemin retenu (EVS, EC2 ou modernisation) :

1. Audit et inventaire : recenser VM, systèmes d'exploitation, ressources consommées (CPU, RAM, IOPS), licences applicatives et exigences réglementaires, à l'aide d'AWS Application Discovery Service ou d'outils tiers.
2. Cartographie des dépendances applicatives : identifier qui parle à qui (flux réseau, bases de données partagées) pour constituer des vagues de migration cohérentes et éviter de couper une dépendance.
3. Choix de la voie et de la cible : pour chaque application, décider entre relocalisation (EVS), rehost (EC2), replatforming ou refactoring, selon le cadre des 7R.
4. Préparation de la cible AWS : mettre en place la landing zone (AWS Control Tower), le réseau (VPC, Transit Gateway, Direct Connect), les identités (IAM Identity Center) et la sécurité avant toute bascule.
5. Vague pilote : migrer un petit lot de VM non critiques pour valider le processus, mesurer les temps et ajuster le plan.
6. Exécution par vagues : répliquer puis basculer les VM avec AWS Application Migration Service (MGN) ou VMware HCX, en respectant les fenêtres de bascule et la stratégie de rollback.
7. Validation et optimisation post-migration : recette fonctionnelle, puis rightsizing, réservations/engagements et gouvernance FinOps une fois sur AWS.

Chaque étape est détaillée dans la suite de cette page. Pour un cadrage chiffré de votre propre parc, un diagnostic d'audit gratuit est le point de départ recommandé.

Les voies de migration VMware vers AWS

AWS ne propose pas un chemin unique mais quatre voies principales, qui correspondent à des niveaux croissants de transformation. Le choix se fait application par application, pas pour tout le parc en bloc.

Voie 1 : Relocalisation (Relocate) : Amazon EVS

La relocalisation consiste à déplacer vos VM sans rien changer : même hyperviseur VMware, mêmes outils (vCenter, vSAN, NSX), mêmes compétences internes. C'est ce que permettait VMware Cloud on AWS, et c'est ce que permet aujourd'hui Amazon Elastic VMware Service (Amazon EVS).

Amazon EVS déploie VMware Cloud Foundation (VCF) directement dans votre VPC AWS, sur des instances EC2 bare metal (matériel dédié, sans couche d'hyperviseur AWS intermédiaire). Vous conservez vSphere, vSAN, NSX et vCenter, mais l'infrastructure physique est opérée par AWS, dans la région de votre choix, y compris la région AWS Paris (eu-west-3). La migration des VM s'effectue alors typiquement avec VMware HCX, qui étend votre réseau on-premise jusqu'au cloud et déplace les VM à chaud ou en masse.

Quand choisir la relocalisation :

• Vous voulez sortir de votre datacenter rapidement, sans réécrire ni reconfigurer les applications.
• Vos équipes maîtrisent VMware et vous voulez préserver cet investissement de compétences à court terme.
• Vous avez des applications difficiles à porter (appliances, systèmes legacy, dépendances NSX fines).

Point d'attention : avec EVS, vous continuez à consommer des licences VMware (via Broadcom) en plus de l'infrastructure AWS. La relocalisation résout le problème du datacenter, pas le problème du coût de licence Broadcom. Elle est souvent une étape de transition vers une modernisation ultérieure, pas une destination finale.

Voie 2 : Rehost (« lift and shift ») : Amazon EC2 via MGN

Le rehost consiste à transformer chaque VM VMware en instance Amazon EC2 native. On quitte l'écosystème VMware : plus de vSphere, plus de licences Broadcom. La VM devient une instance EC2 standard, qui bénéficie du système AWS Nitro, des types d'instances optimisés et du catalogue de services AWS.

L'outil de référence est AWS Application Migration Service (MGN). Son principe : installer un agent léger sur chaque serveur source (Windows ou Linux), qui réplique en continu le disque vers une zone de transit AWS, sans interrompre la production. Le jour de la bascule, MGN convertit automatiquement la réplique en instance EC2 (pilotes, bootloader, agents adaptés), et vous testez avant de couper la source. Le RPO est de quelques secondes à quelques minutes (réplication continue) et la fenêtre de bascule se compte en minutes, ce qui rend possible une migration quasi sans interruption pour les utilisateurs.

Quand choisir le rehost :

• Vous voulez éliminer définitivement les licences VMware, pas seulement déplacer le datacenter.
• Vos applications tournent bien sur des serveurs standards et n'exigent pas de fonctions vSphere spécifiques.
• Vous visez un premier palier rapide avant une modernisation progressive (« migrate then modernize »).

Voie 3 : Replatforming : moderniser à la marge

Le replatforming garde l'application, mais remplace certaines briques d'infrastructure par des services managés AWS, sans réécrire le code applicatif. Exemples typiques :

• Migrer une base de données VMware-hébergée vers Amazon RDS (PostgreSQL, SQL Server, MySQL) : vous abandonnez l'administration de la VM de base de données.
• Déporter un partage de fichiers Windows vers Amazon FSx.
• Conteneuriser un middleware sur Amazon ECS ou Amazon EKS sans toucher au cœur métier.

C'est l'équilibre fréquent : gains opérationnels réels (moins d'administration, sauvegardes managées, haute disponibilité native) pour un effort maîtrisé.

Voie 4 : Refactoring : reconcevoir en natif

Le refactoring (ou re-architecture) reconçoit l'application pour exploiter pleinement le cloud : découpage en microservices, serverless avec AWS Lambda, bases managées, files de messages. C'est la voie la plus coûteuse et la plus risquée à court terme, mais celle qui apporte les plus grands gains de coût et d'agilité sur le long terme. Elle se justifie pour les applications stratégiques, à fort trafic ou en évolution constante, rarement pour un parc legacy stable. Voir notre page dédiée à la migration d'application vers le cloud pour ce cas.

Le cadre des 7R appliqué à VMware

AWS formalise les stratégies de migration dans le cadre des 7R (retire, retain, relocate, rehost, replatform, repurchase, refactor). Pour un parc VMware, l'arbitrage ne se joue pas sur les sept stratégies à parts égales : deux R dominent la décision : Relocate (déplacer le cluster tel quel vers Amazon EVS) et Rehost (convertir chaque VM en instance EC2 via MGN), les autres venant à la marge sur quelques applications. C'est ce couple Relocate/Rehost que cette page détaille (voir les quatre voies ci-dessus et l'arbre de décision EVS vs natif plus bas). Un projet réaliste combine d'ailleurs plusieurs R : sur un parc de 170 VM, on observe couramment 10 % à retirer, 60 % en rehost EC2, 20 % en replatform, 5 % en refactor sur les applications cœur et quelques VM à retenir sur site.

Pour la grille complète des sept stratégies, leur arbre de décision par type d'application et le piège du lift-and-shift, voir le modèle 6R/7R de la migration cloud, page propriétaire de ce cadre.

Les outils de migration AWS, côté VMware

Une migration VMware vers AWS mobilise deux familles d'outils : l'outillage AWS générique de découverte et de bascule (Application Discovery Service, AWS Application Migration Service / MGN, DMS et SCT pour les bases) et l'outillage de mobilité VMware (HCX, vMotion, RAV) qui fait la spécificité d'une sortie de cluster vSphere. Le détail des mécaniques génériques (agent MGN, réplication continue, conversion en EC2, DMS/SCT pour les bases) est traité sur les outils de migration AWS : MGN, DMS, SCT. Cette page se concentre sur ce qui change quand la source est VMware : HCX, RAV et le déploiement EVS.

Pilotage et programmes d'accompagnement

• AWS Migration Hub : la console centrale qui suit l'avancement de la migration, application par application, vague par vague.
• AWS Transform : service d'accélération qui aide à analyser, planifier et automatiser des pans de la migration et de la modernisation (notamment le portage de charges VMware), en s'appuyant sur l'IA générative pour la découverte et la transformation de code/configuration.
• AWS Migration Acceleration Program (MAP) : programme cadre d'AWS qui structure la méthodologie (évaluation, mobilisation, migration) et peut donner accès à des crédits selon l'éligibilité.
• VMware Migration Accelerator (VMA) : programme côté écosystème VMware/Broadcom pour accompagner les bascules.

Indépendance. Ces programmes (MAP, VMA) comportent des incitations commerciales. Un intermédiaire indépendant vous aide à en bénéficier sans transformer le choix technique en choix dicté par les crédits. Le bon outil est celui qui sert votre TCO et votre réversibilité, pas celui qui maximise les commissions.

VMware HCX en détail

HCX mérite une section, car c'est l'outil qui rend la relocalisation fluide, et personne ne le détaille en français. Ses capacités clés :

• Network Extension : étend votre réseau L2 on-premise jusqu'au cloud : une VM migrée conserve son adresse IP, ce qui évite de reconfigurer les applications et leurs dépendances réseau pendant la transition.
• Bulk Migration : déplace de grands lots de VM en parallèle, avec une bascule planifiée (la VM redémarre côté cible). Idéal pour les vagues volumineuses.
• vMotion / HCX vMotion : déplace une VM à chaud, sans interruption, mais une à la fois, réservé aux VM critiques qui ne tolèrent pas de redémarrage.
• Replication Assisted vMotion (RAV) : combine réplication en masse et bascule à chaud : on prépare beaucoup de VM en arrière-plan, puis on bascule chacune sans coupure, dans une fenêtre maîtrisée. Le meilleur compromis volume/disponibilité.
• HCX Sentinel : permet de migrer des VM hors vSphere (machines physiques ou autres hyperviseurs) vers la cible, en installant un agent de réplication.

Sur ces mécanismes reposent les engagements de RTO/RPO : RAV et vMotion visent un RPO proche de zéro et une bascule sans interruption perceptible ; la Bulk Migration accepte un court redémarrage planifié. Le choix se fait VM par VM selon la criticité.

Comparaison des destinations : EVS vs EC2 vs AVS vs GCP VMware Engine

Migrer du VMware ne signifie pas forcément aller chez AWS, et même chez AWS plusieurs cibles coexistent. Voici la comparaison honnête.

| Critère | Amazon EVS (VMware natif) | EC2 natif (via MGN) | Azure VMware Solution (AVS) | GCP VMware Engine | |---|---|---|---|---| | Hyperviseur | VMware (VCF) conservé | Abandonné (Nitro) | VMware (VCF) conservé | VMware conservé | | Licences VMware | Toujours nécessaires | Supprimées | Incluses dans l'offre | Incluses dans l'offre | | Compétences internes | Réutilisées | À faire évoluer | Réutilisées | Réutilisées | | Effort de migration | Faible (HCX) | Faible/moyen (MGN) | Faible (HCX) | Faible (HCX) | | Potentiel de modernisation | Différé | Immédiat | Différé | Différé | | Écosystème de services managés | AWS (via VPC) | AWS complet | Azure complet | Google Cloud complet | | Région Paris (souveraineté FR) | Oui (eu-west-3) | Oui (eu-west-3) | Oui (France Central) | Selon disponibilité |

Lecture de ce tableau :

• EVS vs EC2 natif : EVS minimise le risque et préserve les compétences mais conserve le coût de licence Broadcom ; EC2 supprime ce coût mais demande une vraie migration. EVS est souvent un palier transitoire, EC2 une cible durable.
• AWS vs Azure VMware Solution : si votre SI est déjà largement Microsoft (Entra ID, Microsoft 365, SQL Server), AVS peut être plus cohérent. Nous traitons ce cas dans notre page migration VMware vers Azure et notre expertise architecte Azure. Le conseil reste sans parti pris entre les deux clouds.
• GCP VMware Engine : pertinent si votre data ou vos workloads analytiques vivent déjà sur Google Cloud.

Combien coûte une migration VMware vers AWS : durée, budget et livrables

C'est la question que tout DAF pose, et celle qu'aucun concurrent francophone ne chiffre honnêtement. Voici un cadre réaliste, à transformer en devis ferme après audit, car le coût dépend du périmètre.

Budget indicatif du projet

Pour un parc de PME/ETI, le budget d'un projet de migration VMware vers AWS s'établit à titre indicatif entre 25 000 et 80 000 €, sur devis selon le périmètre. La durée constatée va de 3 à 8 semaines pour les parcs courants, davantage pour les grands parcs ou les modernisations profondes. Cette fourchette couvre l'audit, la conception de la cible, l'exécution par vagues et la validation. Elle exclut les coûts récurrents d'exploitation AWS, traités ci-dessous.

Ce que le budget recouvre, livrable par livrable :

• Rapport d'audit et d'inventaire : cartographie du parc, dépendances, classement 7R par application.
• Document d'architecture cible : landing zone, réseau, sécurité, plan de vagues.
• Modèle de TCO comparatif : coût de rester sur VMware vs coût des cibles AWS, sur 3 ans.
• Infrastructure as Code Terraform versionnée, livrée dans vos dépôts.
• Exécution de la migration par vagues, avec recette et stratégie de rollback.
• Plan FinOps post-migration : rightsizing, réservations, gouvernance des coûts.

Modèle de TCO : licence Broadcom vs cible AWS

Le vrai sujet n'est pas le coût du projet, mais le coût récurrent comparé. Voici les postes à modéliser des deux côtés :

| Côté VMware (statu quo) | Côté AWS (cible) | |---|---| | Abonnement VCF/VVF par cœur (Broadcom) | Instances EC2 (avec engagements) | | Support et maintenance | Stockage EBS / S3 / FSx | | Renouvellement matériel datacenter | Trafic sortant (egress) | | Énergie, hébergement, exploitation physique | Transit Gateway (interconnexion) | | Risque de hausse au renouvellement | Direct Connect (liaison dédiée) |

Côté AWS, trois leviers réduisent fortement la facture EC2 :

• Reserved Instances et Savings Plans : engagement 1 ou 3 ans en échange de remises substantielles (souvent de l'ordre de 30 à 70 % selon l'engagement), à dimensionner après la phase de stabilisation.
• Spot Instances : capacité à prix réduit pour les workloads tolérants à l'interruption (calcul batch, environnements de test) ; à ne pas utiliser pour les serveurs critiques.
• Rightsizing : la majorité des VM VMware sont surdimensionnées ; on observe couramment 20 à 40 % de ressources réservées jamais consommées, qu'on ne reprovisionne pas à l'identique sur AWS.

Honnêteté économique. Sans réservations ni rightsizing, une migration « lift and shift » brute peut coûter plus cher que l'abonnement Broadcom. L'économie n'est pas automatique : elle se construit par l'optimisation FinOps. C'est pourquoi notre modèle de TCO compare le coût AWS optimisé, pas le coût « à la louche ». Pour aller plus loin, voir notre optimisation des coûts cloud et notre offre audit FinOps.

Le piège économique du cloud : les workloads à ne PAS migrer

Un conseil indépendant doit savoir dire non. Tous les workloads ne gagnent pas à partir sur AWS, et certains y deviennent franchement plus chers. Le cadre de décision go/no-go par workload identifie les profils à risque :

• Workloads à fort trafic sortant (egress-heavy) : une application qui sert beaucoup de données vers Internet ou vers d'autres clouds génère des coûts d'egress qui peuvent dépasser le coût des serveurs. Sur site, ce trafic est gratuit. C'est le piège n°1.
• Stockage haut débit massif : les workloads exigeant des IOPS très élevés en permanence coûtent cher en stockage premium provisionné.
• Workloads latence-sensibles : une application industrielle ou temps réel proche de capteurs, machines ou utilisateurs locaux peut souffrir de la latence vers la région cloud ; elle relève parfois plutôt de Retain (rester sur site) ou d'AWS Outposts (matériel AWS déposé chez vous).
• VM stables, amorties, peu sollicitées : si une VM tourne sans variation depuis cinq ans sur du matériel déjà payé, le bénéfice de l'élasticité cloud est nul ; la migrer est une dépense sans retour.

À retenir. L'élasticité du cloud est un avantage pour les charges variables. Pour une charge plate et prévisible, elle n'apporte rien et l'abonnement engagé revient parfois plus cher que le matériel amorti. Le bon plan de migration assume de laisser certaines VM hors AWS : c'est un signe de sérieux, pas un aveu d'échec.

Les étapes d'un projet de migration, en détail

Reprenons la trajectoire des 7 étapes, cette fois avec le niveau de détail qu'attend un DSI.

1. Audit, inventaire et découverte

On part de la réalité, pas du schéma théorique. L'inventaire automatisé (Application Discovery Service ou agents tiers) collecte pendant deux à quatre semaines les métriques réelles : pics CPU/RAM, IOPS, débit réseau. C'est ce qui permet le rightsizing ultérieur. On recense aussi les licences applicatives (Windows Server, SQL Server, middlewares) et les exigences réglementaires par application.

2. Cartographie des dépendances

Une application n'est jamais seule : elle parle à une base, à un annuaire, à un service tiers. Sur un parc VMware, les flux est-ouest internes au cluster sont particulièrement denses, d'où l'intérêt d'une découverte outillée avant de constituer les vagues. La méthode générique d'assessment et de cartographie (regroupement par affinité, ordonnancement des vagues) est détaillée sur la méthode de cartographie des dépendances ; ici, on retient qu'aucune vague ne se découpe sans cette carte, sous peine de couper une dépendance critique en cours de route.

3. Conception de la cible et landing zone

Avant toute bascule, la cible doit exister et être sûre. La landing zone AWS (organisation multi-comptes, garde-fous Control Tower, identités IAM Identity Center) est le socle, et son détail (structure de comptes, SCP, gouvernance) est traité sur landing zone AWS (Control Tower) en détail. Ce qui est propre à une sortie VMware, c'est le volet réseau : raccorder le cluster cible (EVS bare metal ou EC2) à vos sites via VPC, Transit Gateway en hub-and-spoke et Direct Connect, sujet repris en détail plus bas. Migrer dans un compte AWS non préparé, c'est reconstruire de la dette dès le premier jour. Voir aussi notre gouvernance cloud.

4. Vague pilote

On migre d'abord un lot restreint de VM non critiques mais représentatives. Objectif : valider l'outillage (MGN ou HCX), mesurer les temps réels de réplication et de bascule, éprouver la recette et le rollback. La vague pilote transforme un plan théorique en processus éprouvé.

5. Exécution par vagues

Les vagues suivantes s'enchaînent, de la moins critique à la plus critique. Chaque vague suit le même rituel : réplication en arrière-plan (sans impact production), test de la cible, fenêtre de bascule planifiée hors heures ouvrées, recette fonctionnelle, puis décommissionnement de la source une fois la stabilité confirmée.

6. Continuité d'activité et rollback

Pendant toute la migration, la production tourne. La réplication continue de MGN ou de HCX RAV permet une bascule à RPO quasi nul et un RTO de quelques minutes. Surtout, tant que la source vSphere n'est pas décommissionnée, le rollback reste possible : en cas de problème post-bascule, on revient à la VM d'origine sur le cluster source. C'est le filet propre à une bascule VMware. Le principe générique de reprise sur échec et de tests de non-régression est cadré sur plan de rollback et tests de non-régression ; il rejoint nos pratiques de PRA cloud.

7. Validation et optimisation post-migration

Une fois sur AWS, le travail n'est pas fini. Il commence. On applique le rightsizing (ajuster les instances aux métriques réelles), l'extinction hors usage (éteindre les environnements de test la nuit et le week-end), le tagging (étiquetage pour répartir les coûts par équipe/projet) et les engagements (Savings Plans / Reserved Instances) une fois la consommation stabilisée. C'est la phase FinOps, détaillée plus bas.

Calendrier réaliste par taille de parc

Le délai dépend surtout du nombre de VM et de la part de modernisation. Voici des repères issus de retours d'expérience représentatifs du marché.

| Taille de parc | Durée indicative | Jalons typiques | |---|---|---| | ~50 VM | 3 à 6 semaines | Audit (1 sem.) → landing zone (1 sem.) → pilote + 1 à 2 vagues → recette | | ~170 VM | 4 à 6 mois | Audit (3-4 sem.) → landing zone → pilote → 4 à 6 vagues → optimisation | | 500+ VM | 6 à 12 mois | Audit étendu → landing zone → pilote → vagues multiples → modernisation progressive |

La fourchette de 3 à 8 semaines annoncée plus haut correspond aux parcs courants de PME et aux périmètres ciblés ; les grands parcs et les modernisations profondes s'étalent sur plusieurs mois, ce qui est normal et sain.

Retour d'expérience représentatif. Sur un parc de 170 VM d'une ETI industrielle, une trajectoire mixte (60 % rehost EC2 via MGN, 20 % replatform, 10 % retain, 10 % retire) s'est déroulée sur 6 mois : six semaines d'audit et de conception, une vague pilote de 12 VM, puis cinq vagues mensuelles. Aucune interruption perceptible pour les utilisateurs grâce à la réplication continue. La phase FinOps post-migration (rightsizing + Savings Plans) a permis, sur ce cas, de constater une réduction sensible de la facture par rapport au coût AWS « brut » avant optimisation. Chiffres représentatifs, non garantis : votre résultat dépend de votre parc.

Gestion du licensing applicatif sur EC2

Sujet rarement traité, pourtant décisif pour le TCO : que deviennent vos licences Windows Server et SQL Server une fois sur EC2 ?

• License Included : vous payez le système ou la base directement dans le tarif horaire de l'instance EC2. Simple, sans gestion de conformité, mais le coût se cumule au temps d'exécution.
• BYOL (Bring Your Own License) : vous apportez vos propres licences existantes. Pour certaines licences Microsoft, l'usage sur du matériel partagé est restreint : il faut alors des Dedicated Hosts (hôtes physiques dédiés EC2), ce qui change l'équation de coût.

Le bon choix dépend de vos contrats Microsoft en cours (Software Assurance, mobilité de licence) et du volume. Un mauvais arbitrage ici peut faire varier la facture de plusieurs dizaines de pourcents. C'est un point que l'audit doit trancher explicitement, chiffres à l'appui.

Sécurité et conformité de la cible AWS

Migrer ne dispense pas de sécuriser, au contraire, c'est l'occasion de repartir sur une base saine. Et pour un parc français, la conformité n'est pas optionnelle.

Souveraineté et conformité FR/EU

Pour un parc français, la cible AWS doit être pensée souveraineté dès la landing zone : la région AWS Paris (eu-west-3) maintient les données physiquement en France, qu'on parte sur EVS ou sur EC2. L'arbitrage de fond (Cloud Act, hyperscaler US vs OVHcloud, périmètre des transferts) est posé en détail sur souveraineté, Cloud Act et arbitrage OVHcloud. Le détail des référentiels réglementaires (RGPD art. 28/32, HDS via un hébergeur/partenaire certifié, DORA, NIS2, SecNumCloud) est traité sur conformité RGPD, HDS, DORA et souveraineté en migration cloud.

Côté VMware vers AWS, on retient surtout la nuance plateforme/secteur : la conception EVS/EC2 doit acter la localisation, les rôles responsable de traitement / sous-traitant et le chiffrement avant la première bascule, exigence renforcée pour la santé (partenaire certifié HDS) et la finance (résilience et réversibilité DORA). Voir aussi notre conformité cloud.

Le modèle de responsabilité partagée

Sur AWS, AWS sécurise le cloud (matériel, hyperviseur, datacenters) et vous sécurisez ce que vous mettez dans le cloud (systèmes, données, accès, configuration). Ce modèle de responsabilité partagée doit être compris avant la migration, sous peine d'exposer par défaut des ressources que l'on croyait protégées.

Les prérequis de sécurité

• Landing zone via Control Tower : gouvernance multi-comptes et garde-fous dès le départ.
• IAM Identity Center : gestion centralisée des identités et des accès, fédérée avec votre annuaire.
• GuardDuty (détection de menaces) et Security Hub (centralisation des alertes et conformité aux CIS Benchmarks).
• Démarche ISO 27001 côté gouvernance, pour structurer la sécurité dans la durée.

Notre offre sécurisation de l'infrastructure cloud et notre cybersécurité cloud couvrent ces prérequis.

Réversibilité et autonomie : ne pas troquer un enfermement contre un autre

Sortir de l'enfermement Broadcom pour entrer dans un enfermement AWS (ou dans la dépendance à un prestataire) serait une victoire en trompe-l'œil. Le principe est l'inverse : IaC Terraform versionnée dans vos dépôts, comptes AWS à votre nom dès le premier jour, documentation et runbooks remis, de sorte que vous puissiez rejouer, faire évoluer ou quitter la plateforme. C'est aussi une exigence DORA pour la finance.

Le cadre complet de la réversibilité et de l'anti-vendor-lock-in (clause de sortie, comptes à votre nom, IaC portable) est détaillé sur réversibilité et anti-vendor-lock-in. Nous ne revendons ni licences VMware ni capacité AWS : notre intérêt est aligné avec le vôtre, un TCO maîtrisé et une plateforme dont vous gardez les clés. C'est ce qui distingue un intermédiaire indépendant d'un revendeur. Voir qui nous sommes.

Arbre de décision : garder VMware sur AWS (EVS) ou moderniser en natif ?

C'est l'arbitrage central pour un DSI, et il ne se tranche pas à l'instinct. Voici l'arbre de décision que nous posons en atelier.

Question 1 : Devez-vous quitter votre datacenter rapidement (échéance contractuelle, fin de bail, fin de support matériel) ? Si oui et que le temps manque, EVS permet de sortir vite sans réécrire, quitte à moderniser ensuite. Si non, vous avez le temps de viser directement la cible EC2 native.

Question 2 : Vos applications dépendent-elles de fonctions VMware fines (NSX avancé, appliances vSphere, dépendances vSAN spécifiques) ? Si oui, EVS préserve ces fonctions sans risque de régression. Si non, le rehost vers EC2 est ouvert.

Question 3 : Vos équipes ont-elles la bande passante pour monter en compétence AWS pendant la migration ? Si la charge interne est saturée, EVS lisse la transition (mêmes outils, même savoir-faire). Si une montée en compétence est planifiée et soutenue, la cible EC2 native devient durable et supprime le coût de licence.

Question 4 : Quel est votre horizon d'amortissement et votre tolérance au coût de licence Broadcom ? Si vous voulez supprimer le coût de licence le plus vite possible, EC2 native est l'objectif. Si vous acceptez de le conserver à court terme pour réduire le risque, EVS est un palier acceptable.

Synthèse. EVS est rarement une fin en soi : c'est un sas qui réduit le risque pendant que vous préparez la modernisation. Beaucoup d'organisations adoptent une trajectoire en deux temps : relocaliser d'abord (EVS), moderniser ensuite (EC2/services managés), pour découpler l'urgence datacenter de l'effort de transformation. Ce séquencement, défendable devant une direction générale, fait partie de ce que nous cadrons avec vous en amont.

Préparer le réseau et l'interconnexion

Une migration VMware vers AWS est aussi un projet réseau, souvent sous-estimé. Trois briques structurent la connectivité cible :

• AWS Direct Connect : une liaison physique dédiée entre vos sites et AWS, indépendante d'Internet. Elle apporte un débit stable et une latence prévisible, indispensables pendant la phase de réplication massive (où l'on déplace des téraoctets) puis pour les flux hybrides post-migration. Le délai d'établissement d'un Direct Connect (semaines, selon l'opérateur) doit être anticipé dès le lancement du projet, sous peine de bloquer la migration.
• AWS Transit Gateway : le routeur central qui interconnecte vos VPC, vos comptes et votre réseau on-premise en topologie hub-and-spoke. Il évite l'enchevêtrement de connexions point à point et structure le réseau pour la durée.
• VPN de transition : pour les phases initiales ou les sites secondaires, un tunnel VPN chiffré peut suffire avant la mise en service du Direct Connect.

Côté coûts, ces briques pèsent dans le TCO : le Transit Gateway facture l'attachement et le trafic traité, Direct Connect facture le port et le transfert sortant. Les omettre dans le modèle de coût, c'est se préparer une mauvaise surprise, raison pour laquelle ils figurent explicitement dans notre matrice TCO.

Que deviennent vos sauvegardes et votre PRA après la migration ?

Migrer les VM ne suffit pas : il faut migrer la stratégie de protection des données. Sur AWS, le modèle change par rapport à VMware (sauvegardes tierces + second datacenter) : sauvegarde par snapshots EBS et AWS Backup (politique centralisée, versionnée, chiffrée, réplication inter-régions pour les données critiques), et PRA/PCA reconçu autour des régions et zones de disponibilité, avec des RTO/RPO définis et éprouvés par application, une exigence pour les secteurs soumis à DORA.

Le principe générique de continuité, de rollback et de tests de non-régression est cadré sur plan de rollback et tests de non-régression. Cette dimension relève aussi de notre expertise continuité et résilience. Un PRA documenté et testé est un livrable, pas une promesse.

Erreurs fréquentes et comment les éviter

Douze ans de projets de migration font émerger des pièges récurrents. Les connaître, c'est déjà les éviter.

• Migrer sans audit de dépendances : on bascule une application, et une autre tombe parce qu'elle en dépendait. Solution : la cartographie des flux avant tout découpage en vagues.
• Reproduire le surdimensionnement VMware : copier une VM 16 vCPU / 64 Go qui n'en utilise que 30 %, et payer le plein tarif AWS. Solution : rightsizing fondé sur les métriques réelles collectées à l'audit.
• Oublier le licensing applicatif : découvrir après coup que SQL Server en License Included double la facture. Solution : trancher BYOL vs License Included pendant le cadrage, chiffres à l'appui.
• Négliger l'egress : une application qui sert beaucoup de données vers l'extérieur explose la facture cloud. Solution : le go/no-go par workload, qui peut conduire à laisser cette application sur site.
• Construire dans un compte AWS non gouverné : pas de landing zone, pas de garde-fous, et de la dette de sécurité dès le premier jour. Solution : Control Tower avant la première VM.
• Sauter la vague pilote : passer directement aux applications critiques sans avoir éprouvé le processus. Solution : toujours un pilote représentatif et non critique d'abord.
• Considérer le projet fini à la bascule : sans phase FinOps, l'économie promise ne se matérialise pas. Solution : intégrer rightsizing, réservations et gouvernance dès le cahier des charges.

Bénéfices attendus d'une migration réussie

Au-delà de la sortie de Broadcom, une migration bien conduite vers AWS apporte des gains constatés sur nos projets, présentés ici sans garantie, car ils dépendent de votre contexte :

• Scalabilité : on provisionne et on libère des ressources à la demande, là où le datacenter imposait d'acheter pour le pic.
• Performance : le système AWS Nitro et les instances EC2 bare metal offrent un socle matériel moderne ; les types d'instances spécialisés (calcul, mémoire, stockage) permettent d'ajuster finement.
• Réduction des coûts opérationnels : fin de l'exploitation physique du datacenter, des renouvellements matériels et de l'énergie ; coûts variabilisés et optimisables par FinOps.
• Modernisation progressive : une fois sur AWS, le chemin vers les services managés (RDS, conteneurs, serverless) s'ouvre application par application, à votre rythme.
• Résilience : multi-zones de disponibilité, sauvegardes managées, PRA reconçu.

À retenir. Ces bénéfices ne sont pas automatiques : ils se construisent par une cible bien conçue et une optimisation suivie. Une migration « lift and shift » sans suite peut n'apporter qu'un changement d'hébergeur, sans gain réel. La valeur est dans la trajectoire, pas dans la seule bascule.

Alternatives à AWS : situer le choix dans le marché

AWS n'est pas la seule sortie possible de VMware. Les autres voies cloud, Azure VMware Solution (cohérent si votre SI est déjà Microsoft, voir comparer une sortie VMware vers Azure (AVS)) et Google Cloud VMware Engine, et les voies on-premise (Proxmox VE, Nutanix AHV, Hyper-V, OpenShift Virtualization, XCP-ng / Vates pour rester souverain à coût de licence quasi nul) ont chacune leur logique selon vos compétences et votre stratégie data.

Le comparatif neutre tête-à-tête entre clouds (sur quelle plateforme migrer, au-delà du seul cas VMware) est traité sans parti pris sur comparatif neutre Azure vs AWS pour migrer.

À retenir. Le bon choix dépend de votre parc, de vos compétences, de votre stratégie data et de votre exposition réglementaire. Présenter ces alternatives honnêtement n'affaiblit pas la recommandation AWS, quand elle est justifiée, elle la rend défendable devant une direction générale.

Conduire le changement : les équipes pendant et après la migration

Une migration VMware vers AWS n'est pas qu'un projet technique : c'est une transition de compétences. Les administrateurs vSphere d'hier doivent comprendre EC2, VPC, IAM, les outils AWS et, à terme, l'Infrastructure as Code. Ignorer cette dimension humaine, c'est risquer une plateforme bien construite mais inexploitable en interne.

Notre approche intègre le transfert dès le projet :

• Co-construction : vos équipes participent aux ateliers de cadrage et aux vagues, plutôt que de découvrir la cible une fois livrée.
• Documentation vivante : runbooks, schémas et décisions d'architecture remis et expliqués, pas archivés.
• Formation ciblée : montée en compétence sur les briques que vos équipes exploiteront (console AWS, Terraform, FinOps).
• Période d'accompagnement : un relais progressif où nous restons disponibles pendant que vos équipes prennent la main, jusqu'à l'autonomie réelle.

Cette logique de transfert est au cœur de notre conseil en architecture : les prestataires de notre réseau construisent pour que vous exploitiez, pas pour vous rendre dépendant.

Migration VMware vers AWS selon votre secteur

Les contraintes d'une migration varient fortement selon l'activité. Quelques repères sectoriels :

• Santé : l'hébergement de données de santé impose un partenaire certifié HDS et une attention particulière au chiffrement et à la traçabilité. Voir secteur santé.
• Finance et assurance : DORA impose résilience opérationnelle, tests de continuité, gestion des risques liés aux prestataires tiers et réversibilité ; la migration doit être documentée en conséquence. Voir secteur finance.
• Industrie : fréquence de workloads latence-sensibles (supervision, MES) qui relèvent parfois du Retain ou d'Outposts plutôt que d'une migration pure. Voir secteur industrie.
• Distribution, saisonnalité forte : l'élasticité AWS prend tout son sens pour absorber les pics, avec un FinOps rigoureux le reste de l'année. Voir secteur distribution.
• Secteur public : exigences de souveraineté et de marchés publics, région Paris privilégiée. Voir secteur public.
• Éditeurs SaaS : souvent les plus enclins au refactoring (multi-tenant, serverless) pour transformer la migration en modernisation. Voir secteur SaaS.

Pour approfondir les fondamentaux, notre guide du cloud et notre page services de migration cloud complètent cette lecture.

FinOps post-migration : transformer l'essai

La migration n'apporte d'économie que si elle est suivie d'une gouvernance des coûts. Les leviers propres à AWS, une fois le parc stabilisé : rightsizing continu (corriger le surdimensionnement hérité de VMware), extinction hors usage des environnements non productifs, Savings Plans / Reserved Instances / Spot une fois la consommation prévisible, et tagging suivi via AWS Cost Explorer.

Le cadrage générique du FinOps de migration et du business case avant/après, celui qui décide si le projet tient économiquement, est détaillé sur FinOps de migration et business case avant/après. Membre de la FinOps Foundation, nous coordonnons cette phase via notre offre optimisation des coûts cloud ; l'exploitation au quotidien est assurée par des prestataires via notre infogérance cloud.

Pourquoi un intermédiaire indépendant pour votre migration VMware vers AWS

La migration VMware vers AWS croise l'urgence Broadcom, la profondeur technique AWS, la conformité française et l'enjeu budgétaire YMYL. C'est un terrain où l'erreur coûte cher. Notre positionnement :

• 12 ans d'expertise, +120 projets accompagnés, +40 clients, une satisfaction client reconnue.
• AWS Partner (Advanced Tier Services) et Microsoft Azure Partner : nous comparons les deux clouds sans parti pris.
• Prestataires qualifiés : certifications AWS DevOps Engineer Professional, Azure Solutions Architect Expert, CISSP, FinOps Certified Practitioner.
• Démarche ISO 27001, membre de la FinOps Foundation.
• Autonomie et réversibilité au cœur de la méthode : votre IaC, vos comptes, votre documentation.

Cette migration s'inscrit dans notre pilier migration cloud en entreprise, aux côtés des trajectoires sœurs : migrer des serveurs non-VMware vers AWS (MGN, souveraineté), comparer une sortie VMware vers Azure (AVS), stratégie 6R et conformité de migration et migration de serveurs vers Azure.

Prochaine étape. Le seul moyen de transformer ces fourchettes en chiffres fermes, c'est l'audit de votre parc réel. Lancez un diagnostic gratuit ou contactez-nous : réponse sous 48 h ouvrées.

FAQ : Migration VMware vers AWS

Comment migrer une VM VMware vers AWS ?

On installe un agent AWS Application Migration Service (MGN) sur la VM, qui réplique en continu son disque vers AWS sans interrompre la production. Le jour de la bascule, MGN convertit la réplique en instance EC2 et vous la testez avant de couper la source. Pour une relocalisation VMware « tel quel », on utilise plutôt VMware HCX vers Amazon EVS. Le choix dépend de la stratégie : supprimer les licences VMware (EC2) ou les conserver (EVS).

Quel est le coût d'une migration de VMware vers AWS ?

À titre indicatif, un projet pour un parc de PME/ETI s'établit entre 25 000 et 80 000 €, sur devis selon le périmètre. À cela s'ajoute le coût récurrent AWS (instances, stockage, egress, interconnexion), à modéliser et à optimiser avec Savings Plans, Reserved Instances et rightsizing. Sans optimisation, le cloud peut coûter plus cher que prévu : c'est l'objet du modèle de TCO réalisé pendant l'audit.

VMware Cloud on AWS est-il encore disponible ?

Depuis le 30 avril 2024, VMware Cloud on AWS n'est plus commercialisé par AWS : il reste accessible uniquement via Broadcom et ses revendeurs. Le chemin AWS recommandé pour faire tourner du VMware natif est désormais Amazon Elastic VMware Service (Amazon EVS), en disponibilité générale depuis 2025.

Quelle est la différence entre VMware Cloud on AWS / EVS et une migration native vers EC2 ?

Avec EVS (ou l'ancien VMware Cloud on AWS), vous conservez VMware (vSphere, vSAN, NSX, vCenter) et vos compétences, mais aussi vos licences Broadcom. Avec une migration native vers EC2, vous abandonnez VMware : plus de licences, instances AWS standards, accès complet aux services managés. EVS minimise le risque et l'effort ; EC2 supprime le coût de licence et ouvre la modernisation. EVS est souvent un palier transitoire, EC2 une cible durable.

Combien de temps dure une migration VMware vers AWS ?

Pour un parc courant de PME, comptez 3 à 8 semaines. Un parc d'environ 170 VM s'étale sur 4 à 6 mois, et un parc de 500+ VM sur 6 à 12 mois. La durée dépend du nombre de VM, des dépendances et de la part de modernisation.

Faut-il des licences VMware pour faire tourner ses VM sur AWS EC2 ?

Non. Une fois converties en instances EC2 via MGN, vos VM ne dépendent plus de VMware : aucune licence Broadcom n'est nécessaire. Les licences VMware ne restent requises que si vous choisissez Amazon EVS, qui fait tourner VMware natif dans AWS.

Qu'est-ce qu'Amazon EVS (Elastic VMware Service) ?

Amazon EVS déploie VMware Cloud Foundation directement dans votre VPC AWS, sur des instances EC2 bare metal opérées par AWS. Vous gardez vSphere, vSAN, NSX et vCenter, tout en bénéficiant de l'infrastructure et de la proximité des services AWS, dans la région de votre choix dont Paris (eu-west-3). C'est la voie de relocalisation recommandée par AWS depuis 2025.

Quelles sont les alternatives à VMware après le rachat par Broadcom ?

Trois familles : rester sur VMware en absorbant la hausse ; changer d'hyperviseur sur site (Proxmox VE, Nutanix AHV, Hyper-V, OpenShift Virtualization, XCP-ng) ; ou migrer vers le cloud (AWS, Azure VMware Solution, Google Cloud VMware Engine). Le bon choix dépend de la taille du parc, des compétences internes et des contraintes réglementaires.

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

HCX est l'outil de mobilité VMware utilisé surtout vers EVS. Il crée un tunnel sécurisé entre votre vCenter on-premise et la cible, étend votre réseau (Network Extension, les VM gardent leur IP) et déplace les VM en masse (Bulk Migration), à chaud (vMotion) ou via Replication Assisted vMotion (RAV) pour un volume important sans coupure. HCX Sentinel permet même de migrer des machines hors vSphere.

Vaut-il mieux migrer vers AWS, Azure VMware Solution ou Proxmox ?

Cela dépend du contexte. AWS offre l'écosystème de services managés le plus large pour moderniser ensuite. Azure VMware Solution est cohérent si votre SI est déjà Microsoft. Proxmox convient si vous voulez rester on-premise à coût de licence quasi nul, au prix d'un effort de compétences. Un conseil indépendant compare ces options selon votre parc, sans parti pris.

Comment estimer le TCO d'une migration VMware vers le cloud ?

On modélise les deux côtés : d'un côté l'abonnement Broadcom, le support, le renouvellement matériel et l'exploitation physique ; de l'autre les instances EC2 (avec Savings Plans/RI/Spot), le stockage, l'egress, Transit Gateway et Direct Connect. On intègre le rightsizing (les VM VMware sont souvent surdimensionnées) et le licensing applicatif (BYOL vs License Included). Le résultat se présente en fourchette sur 3 ans, jamais en chiffre garanti.

Comment migrer sans interruption de service pour les utilisateurs ?

Grâce à la réplication continue (MGN ou HCX RAV) : les VM sont copiées vers AWS pendant que la production tourne. La bascule, planifiée hors heures ouvrées, ne dure que quelques minutes (RPO quasi nul). Tant que la source n'est pas décommissionnée, un rollback reste possible, ce qui sécurise l'opération.

Quels sont les risques d'une migration VMware vers AWS ?

Les principaux : sous-estimer les dépendances applicatives, migrer des workloads qui coûtent plus cher sur le cloud (egress-heavy, latence-sensibles), négliger la landing zone de sécurité, et oublier la phase FinOps qui conditionne l'économie. Un audit préalable, une vague pilote et une stratégie de rollback réduisent ces risques.