Skip to main content

VMware to AWS Migration Paths (2026): EVS vs MGN vs Native Replatform Decision Guide

Cloud ArchitectureUpdated Palaniappan P4 min read

Quick summary: For a mid-market software estate (~280 VMs, $340k/yr Broadcom renewal), splitting 60% MGN rehost + 25% EVS relocate + 15% replatform cut parallel-run from 22 to 16 weeks, without forcing one hypervisor strategy.

Key Takeaways

  • Broadcom's subscription-only VMware licensing (post-2023 acquisition) pushed many enterprises into $180k to $420k/yr renewal quotes for mid-market VM counts
  • This post is the VMware-to-AWS path decision guide: when to Relocate on EVS, Rehost with MGN, or Replatform to native AWS
  • It is separate from the EVS product deep-dive, the 7 Rs overview, and a data-center exit program plan, though it feeds those documents
  • Benchmark pattern (not a cited client): Mid-market B2B software, ~280 VMs, mixed RHEL/Windows, $340k/yr Broadcom renewal quote, 22-week parallel-run target on paper
  • After tri-path assignment (60% MGN, 25% EVS, 15% replatform): 16-week parallel-run achievable
VMware to AWS Migration Paths (2026): EVS vs MGN vs Native Replatform Decision Guide
Table of Contents

Amazon Elastic VMware Service (EVS) reached general availability on August 21, 2025 (AWS announcement), with 19 commercial Regions listed on the EVS FAQ as of mid-2026, including expansions to Singapore, London, Mumbai, Sydney, Paris, and São Paulo through late 2025. AWS Transform MGN (formerly AWS Application Migration Service) remains the default block-level rehost path to EC2, with a default 150 concurrent replicating source-server quota (increase via AWS Support with a migration plan per MGN at scale guidance).

Broadcom’s subscription-only VMware licensing (post-2023 acquisition) pushed many enterprises into $180k to $420k/yr renewal quotes for mid-market VM counts. That is a business driver. This post is the VMware-to-AWS path decision guide: when to Relocate on EVS, Rehost with MGN, or Replatform to native AWS. It is separate from the EVS product deep-dive, the 7 Rs overview, and a data-center exit program plan, though it feeds those documents.

Artifacts: migration path decision matrix, wave plan worksheet CSV.

Three paths, one program office

PathAWS serviceYou keepYou change
RelocateAmazon EVSvSphere ops, HCX, BYOLLocation (AWS bare metal)
RehostAWS MGNApp binaries, OSHypervisor → EC2
ReplatformECS/EKS/RDS/etc.Business logicRuntime, often data tier

Opinionated take: Default to MGN for the long tail, EVS only where vSphere is contractual or operational debt, replatform only where refactor ROI is already funded. Mandating one path for 280 VMs is how programs miss exit dates and overspend on bare metal.

Decision tree

Vendor cert or ops team only knows vSphere for this VM?
  YES → EVS (Relocate) — verify Region on EVS FAQ
  NO → Container-ready or managed-service target within 2 quarters?
         YES → Replatform backlog (may still MGN-bridge short term)
         NO → AWS MGN → EC2 (Rehost)

Score each VM in wave-plan-worksheet.csv.

Amazon EVS: when relocate wins

Per EVS GA:

  • VCF 5.2.1 on i4i.metal with license portability (BYOL)
  • Full admin access, with the same vCenter model as on-premises
  • On-demand, 1-year, and 3-year consumption options

Choose EVS when:

  • ERP or SCADA vendor supports vSphere 8 on AWS but not raw EC2
  • Team cannot retrain on EC2 patch cadence before DC lease ends
  • HCX vMotion cutover is required for near-zero downtime on large VMs

When NOT EVS: Estates under ~30 VMs (MGN + right-sizing usually cheaper), workloads targeting EKS in 6 months (pay bare-metal twice), or Regions not on the EVS FAQ list.

AWS MGN: when rehost wins

MGN block-replicates to a staging subnet, launches test then cutover instances. Limits to plan around (migration at scale):

  • Default 150 max active replicating servers (request increase with justification)
  • Up to 200 source servers per replication job
  • EC2/EBS quotas for replication servers + snapshots, so plan waves

Choose MGN when:

  • VMs are general-purpose Linux/Windows without vSphere-only tooling
  • You want native EC2 integration (IAM instance profiles, Systems Manager, Graviton)
  • Post-migration path includes right-sizing and Graviton adoption

Native replatform: when to skip the VM entirely

Replatform 15 to 20% of a typical estate first because it removes VMs from EVS/MGN scope:

  • Containerized microservices already on VMs → ECS/Fargate or EKS
  • Commercial databases on VM → Aurora/RDS (see managed DB ops guide)
  • Batch → Lambda + Step Functions where runtime allows

Do not replatform tier-0 monoliths on the critical path to DC exit unless refactor is funded and tested; scale-in-place before decomposition applies.

Wave planning: parallel-run math

WaveContentsTypical duration
0Discovery + path assignment worksheet2 weeks
1MGN tier-2/3 (low dependency)3–4 weeks
2EVS cluster + HCX tier-04–6 weeks
3Replatform pilots (parallel)6–12 weeks
4Retire on-prem networking1–2 weeks

Model your VM list in wave-plan-worksheet.csv: tier0 VMs with vmware_only_tooling=yes should not default to MGN.

What to do this week

  1. Export VM inventory (name, OS, vCPU, RAM, storage, tier) into wave-plan-worksheet.csv.
  2. Mark vSphere-only systems. Vendor-certified vSphere-only systems are candidate EVS.
  3. Score the top spend. Run decision matrix scoring for the top 20% spend VMs first.
  4. Open a quota ticket. Open an AWS Support ticket for MGN quota if concurrent replicate count exceeds 120.
  5. Verify EVS Region. Check EVS Region availability for primary + DR before signing relocate SOW.

What this post doesn’t cover

We have not benchmarked EVS i4i.metal unit economics against MGN Graviton targets for the same workload; fill your SKUs in the worksheet before executive cost sign-off.

Sources

Related: AWS migration services · Architecture review

Frequently asked questions

When should we choose Amazon EVS over AWS MGN?
Choose EVS when vSphere operations, HCX live migration, or VMware-only vendor certifications block a hypervisor change before your data-center exit deadline. Choose MGN when you can run on EC2 with block-level replication and want native AWS integration without bare-metal VMware licensing overhead.
When should we NOT use EVS for the whole estate?
Skip EVS-only strategies for small estates under ~30 VMs where MGN to right-sized EC2 is cheaper, when your target Region lacks EVS (verify the AWS EVS FAQ list), or when your 6-month goal is EKS/ECS-first. Relocate only the VMs that truly require vSphere.
What breaks during MGN cutover at scale?
EC2 and EBS quotas throttle staging replication; default MGN concurrent replicating server limit (150, increase via Support) stalls waves above ~120 simultaneous sources. Symptom: replication lag grows while cutover calendar slips. Fix: wave planning, quota pre-checks, and staggered cutover instead of a single big-bang weekend.
How does this differ from the Amazon EVS product post?
The EVS post explains vSphere-on-AWS mechanics and BYOL. This post is the portfolio decision: which VMs take EVS, which take MGN, which replatform, and in what order, for mixed estates exiting on-premises VMware.
Can we use EVS and MGN in the same program?
Yes, and it is recommended for most mid-market estates. EVS for VMware-bound tier-0 systems; MGN for general-purpose Linux/Windows that tolerate EC2; replatform for container-ready or SaaS workloads. One program office, three technical tracks.
What could go wrong with a single-path mandate?
EVS-only delays container modernization and bare-metal cost; MGN-only breaks vendor certs tied to vSphere; replatform-only misses the DC exit date. The wave worksheet forces per-VM assignment instead of executive "pick one R."
Palaniappan P
Palaniappan P

AWS Cloud Architect & AI Expert

AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.

AWS ArchitectureCloud MigrationGenAI on AWSCost OptimizationDevOps

Recommended Reading

Explore All Articles »