VMware to AWS Migration: Choosing Amazon EVS, Rehosting, or Modernizing

Key takeaways
 

• Most VMware estates need more than one migration path: Use Amazon EVS for workloads that depend on VMware, rehost stable servers to EC2, and modernize self-managed databases and aging .NET applications.
• Broadcom’s licensing changes are driving the timeline: The end of perpetual licenses and the 72-core minimum order make the next VMware renewal the natural deadline for deciding where each workload goes.
• EVS is a bridge for groups of workloads, not individual VMs: A four-node minimum plus bring-your-own VCF licensing means it pays off only for groups of workloads with shared VMware requirements.
• AWS Transform cuts planning time but doesn’t make the decisions: It automates discovery, wave planning, network conversion and rehosting at no cost, while your team still sets acceptance criteria and owns operations after cutover.

Paths for moving VMware workloads to AWS

A VMware to AWS migration moves more than virtual machines. Each workload brings its own application dependencies, data flows, identity relationships, network requirements, recovery objectives, licenses, and operating procedures.

The process starts by establishing a reliable inventory, then connecting individual servers to the business services they support. From there, the migration team can decide which workloads should move together, what the target AWS architecture needs to provide, and how to test each wave before cutover.

Most VMware estates move to AWS using a mix of approaches. Workloads with heavy VMware dependencies or a hard renewal deadline often move first to Amazon Elastic VMware Service (Amazon EVS), stable servers with well-understood dependencies rehost to Amazon EC2, and applications carrying technical debt, such as self-managed SQL Server or aging .NET code, are candidates for modernization. The work that makes the plan reliable is deciding which workload belongs in which group, then sequencing the moves so each wave can be tested and cut over without surprises.

Which path fits depends mostly on the workload:

• Large groups of VMs that depend on NSX, vSphere tooling, or VMware operational processes: 
  Amazon EVS moves these workloads VCF-to-VCF without re-platforming each VM, which suits teams facing a renewal or data center exit deadline that need to move first and modernize later.
   
• Stable servers with documented dependencies and no near-term application changes: 
  Rehosting to Amazon EC2 is the fastest route off VMware licensing, with test launches before a planned cutover, and it’s usually a better fit than EVS for small or independent applications, where the four-node minimum is hard to justify.
   
• Self-managed databases, Windows and .NET applications, or systems already due for a rewrite: 
  Replatforming or modernizing onto managed services and updated runtimes reduces operational and licensing costs when the return justifies the change.

The rest of the article covers the tradeoffs, the licensing questions that change the math, and how AWS Transform speeds up discovery, planning, and execution.
 

Why VMware estates are being re-evaluated now

Broadcom's acquisition of VMware, completed in November 2023, changed the economics for many customers. Perpetual licenses were discontinued in 2024 in favor of subscriptions, and customers have been steered toward the VMware Cloud Foundation (VCF) bundle. Starting in April 2025, the minimum order for new licenses and renewals rose from 16 to 72 cores, and customers who miss a renewal date face a reinstatement penalty. For a mid-sized environment, the next renewal can arrive with a meaningfully different price and a short window to decide.

VMware Cloud on AWS customers saw a related change in May 2024, when Broadcom became the only seller of the service and AWS stopped reselling it. Existing AWS-billed subscriptions continue until their terms end, after which those customers negotiate directly with Broadcom.

Renewal dates, hardware refreshes, and data center contract expirations are the usual planning milestones, at which point organizations decide whether a workload belongs on VMware long term, should move to AWS with limited change, or is ready for a different operating model. The answer rarely applies evenly across the estate, which is why an assessment that maps each workload to a path is the best first step.
 

Amazon EVS: keep VMware, change where it runs

Amazon EVS runs VMware Cloud Foundation on Amazon EC2 instances inside your own Amazon VPC. EVS supports VCF 9.0 and 9.1 on i4i and i7i bare-metal hosts, and environments can scale to 32 hosts. Your team keeps administrative access to vSphere, NSX Manager, and SDDC Manager, so existing VMware tools, runbooks, and skills carry over. Workloads can move VCF-to-VCF, and NSX Federation lets on-premises NSX and EVS environments be managed under a single control plane during the transition.

EVS is self-managed, which separates it from VMware Cloud on AWS, where Broadcom operates the environment. Your team or a partner handles patching, capacity, and day-two operations, and the account running EVS must maintain AWS Business Support or higher.

EVS fits best when a group of workloads shares VMware-specific requirements and the business needs to exit a data center or avoid a renewal before applications can be changed. It also works as a staging point: once workloads run on AWS, each one can be evaluated for rehosting or modernization on a schedule that matches its lifecycle. 

Teams that choose EVS should still define the long-term destination for each workload, because running VCF on AWS indefinitely carries both AWS infrastructure and Broadcom licensing costs.
 

Minimum footprint and cost planning for Amazon EVS

Amazon EVS is an environment-level commitment. Broadcom recommends a minimum production environment of four nodes, with the exact design shaped by the VCF release, storage architecture, NSX configuration, management requirements, and workload profile. VCF licenses are brought by the customer from Broadcom or an authorized reseller.

Cost planning should cover the complete environment: bare-metal EC2 hosts, the EVS control plane, network components, storage, data transfer, backup, disaster recovery, and applicable VMware and Microsoft licensing. The design also needs enough IP address space, DNS and NTP configuration, and a network model that supports both the VCF environment and connected AWS services. 

Because of that baseline cost, EVS makes sense for a group of workloads with shared VMware requirements, while smaller or more independent applications usually have a better cost and operating model on Amazon EC2 or a managed AWS service.
 

Rehost to Amazon EC2

Rehosting moves a VMware-based server to Amazon EC2 with limited application change. It is often the fastest way off VMware licensing for stable workloads with well-understood dependencies.

The replication engine is AWS Transform MGN, formerly AWS Application Migration Service, which supports both agent-based and agentless replication from vCenter. Teams launch test instances, validate application behavior and connectivity, and perform a planned cutover when the workload is ready. Rehosting establishes an AWS foundation quickly and leaves the option to rightsize, replatform, or modernize the workload in a later phase.
 

Replatform or modernize

Some VMware workloads justify a larger change. A self-managed database may move to Amazon RDS or Amazon Aurora. A Windows-based .NET application may benefit from an updated runtime, a Linux deployment, or containers on Amazon ECS or Amazon EKS. A tightly coupled application may call for a phased plan that separates the infrastructure move from application changes.

Modernization can reduce operational work, improve release speed, and lower licensing costs when the expected return supports the effort. The decision should rest on the application's lifecycle, business value, technical debt, delivery goals, and the team's capacity to absorb change. For a deeper comparison of application paths, see when to move VMs to containers or serverless.
 

How to decide, workload by workload

A useful decision framework asks these questions of every application:

• Business role: What customer, operational, compliance, or revenue function does the application support?
   
• Technical fit: Is the application stable and ready to rehost, or would a managed service or modernization path produce a better long-term result?
   
• Dependencies: Which databases, file shares, identity services, third-party systems, network rules, and batch processes must move together?
   
• Operational model: Which team will support the workload after migration, and which monitoring, backup, recovery, patching, and access controls must be in place?
   
• Licensing and cost: What changes when the workload leaves VMware, including Windows Server, SQL Server, and other software licensing?
   
• Timing: Does a renewal date, data center milestone, end-of-support date, or business initiative create a preferred migration window?
   

Discovery tooling can answer much of the dependency and utilization question. Application owners, security, operations, and business stakeholders supply the context that turns the data into an executable runbook.
 

Windows Server and SQL Server licensing

Windows Server workloads deserve their own licensing review. On Amazon EVS, eligible licenses with portability rights can be brought over. For VMs without those rights, EVS offers Windows Server entitlements billed per vCPU-hour, which can be added or removed for individual VMs as needs change.

For workloads moving directly to Amazon EC2, or for applications that may benefit from a database or .NET modernization path, a Microsoft workloads strategy assessment compares the application architecture, actual utilization, license entitlements, operating costs, and expected return from change.

SQL Server needs the same focused review. Some applications need the control of SQL Server on Amazon EC2, while others can shift routine database administration to Amazon RDS for SQL Server or follow a longer-term move to an open-source engine. See our guide to migrating SQL Server to AWS for the other considerations.
 

Where AWS Transform fits

AWS Transform is AWS's agentic AI service for migration and modernization, and its VMware capabilities cover most of the repeatable work across all three paths:

• Discovery and assessment: Ingests inventory data, including RVTools exports, identifies data-quality gaps, and produces TCO projections and a business case.
   
• Dependency mapping and wave planning: Maps application dependencies and groups servers into migration waves based on technical and business priorities, which the team can adjust.
   
• Network conversion: Translates on-premises network configurations, including NSX exports, into VPCs, subnets, security groups, transit gateways, and route tables, with output as AWS CloudFormation, AWS CDK, Terraform, or Landing Zone Accelerator configurations.
   
• Rehost execution: Orchestrates AWS Transform MGN, including agent deployment, test launches, progress tracking, and cutover.
   
• Modernization: Containerizes supported applications for Amazon ECS or Amazon EKS and accelerates analysis and transformation work for Windows and .NET applications.
   

AWS currently offers the VMware migration agent at no cost, while the AWS resources a migration creates are billed at standard rates. AWS Transform can also tag migrated resources for MAP credit eligibility automatically.

AWS Transform shortens planning and reduces manual configuration. Decisions about acceptance criteria, which workloads justify modernization, and how the environment will be operated after cutover still sit with the migration team and the business.
 

Running the migration in waves

Migration waves work best when they represent business services rather than server counts. A customer-facing application may span web servers, application servers, databases, file services, identity systems, and external integrations, and grouping those components together supports clearer testing, cutover, and rollback.

For every wave, define:

• The applications and infrastructure included
• Dependencies that must migrate together or remain connected during the transition
• The target AWS architecture, network path, and security controls
• Functional, performance, and business acceptance tests
• Cutover timing, rollback steps, and the owner responsible for post-migration validation

Two Stratus10 projects show how wave planning plays out with Windows-heavy estates. GB International, a global logistics company, consolidated Windows application and web servers from multiple data centers into a highly available, multi-region AWS environment built with CloudFormation and patched through AWS Systems Manager, cutting costs by 62% compared with its previous data center spending. BMT Scientific Marine moved its Windows Server 2008 R2 VMs to EC2 instances running Windows Server 2019, transferred more than 75 TB of data to AWS using AWS Snowball, and replaced offsite tape backups with Amazon S3 Glacier Deep Archive.
 

Common pitfalls to plan for
 

• Unsupported guest operating systems: Older Windows and Linux versions may need an in-place upgrade or rebuild before or during migration, as BMT's move from Windows Server 2008 R2 required.
   
• IP addressing: Overlapping CIDR ranges between on-premises and AWS complicate hybrid connectivity, and hard-coded IP addresses in applications break at cutover if no one has found them.
   
• Replication bandwidth: Initial replication of large disks over VPN can take longer than the wave schedule allows. Size the connection, consider AWS Direct Connect, or move bulk data offline with AWS Snowball
   
• Licensing true-ups: Leaving VMware changes Windows Server and SQL Server licensing positions. Review entitlements before cutover so the first AWS invoice reflects the licensing you planned for.
   
• Operational readiness: Backup, monitoring, patching, and access controls need to be in place on AWS before production cutover, along with clear ownership.

For more guidance on sequencing migration and modernization work, read Cloud Migration and Modernization Strategies: What to Plan For.
 

Funding the migration through AWS

The AWS Migration Acceleration Program (MAP) provides methodology, tooling, and funding across three phases: assess, mobilize, and migrate and modernize. Depending on eligibility and current program terms, MAP funding and credits offset the cost of assessment, planning, and migration.

Stratus10 provides the free AWS migration assessment that produces the inventory, dependency analysis, wave sequencing, architecture direction, and business case needed to move into delivery, along with a review of which MAP funding your migration may qualify for.