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

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 Application Migration Service (MGN) 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–$420k/yr renewal quotes for mid-market VM counts — a business driver, not a technical one. 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 not the EVS product deep-dive, not the 7 Rs overview alone, and not a data-center exit program plan — though it feeds those documents.

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

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 — EVS track carried vendor-certified ERP; MGN absorbed stateless tiers; replatform removed 42 VMs from scope entirely.

Three paths — one program office

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 — 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 — wave migrations

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

What broke — Week 3 of a single-path MGN program. Tier-0 ERP failed cutover: vendor support rejected EC2 hypervisor for certified stack; 36-hour rollback via MGN reverse replication. Detection: vendor ticket + failed smoke test. Fix: moved ERP + 14 dependent VMs to EVS track; MGN continued for 180 stateless VMs. Lesson: assign path per VM before calendar commit — see worksheet column assigned_path.

Native replatform — when to skip the VM entirely

Replatform 15–20% of a typical estate first — not because it is easy, but 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

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 vendor-certified vSphere-only systems → candidate EVS.
3. Run decision matrix scoring for the top 20% spend VMs first.
4. Open AWS Support ticket for MGN quota if concurrent replicate count exceeds 120.
5. Verify EVS Region availability for primary + DR before signing relocate SOW.

Reproduce this — Download wave-plan-worksheet.csv. Fill assigned_path for every row. Count paths: if EVS > 40% of VMs, validate bare-metal budget; if MGN > 80%, audit for hidden vSphere dependencies before cutover calendar.

What This Post Doesn’t Cover

• VMware Cloud on AWS (legacy VMC) commercial terms — see EVS vs VMC comparison.
• MAP funding math — MAP SMB guide.
• Post-migration FinOps — FinOps handoff 2026.
• Application dependency discovery tooling — covered in migration readiness checklist.

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.

Related: AWS migration services · Architecture review