Amazon EVS: Why you need this VMware migration tool (Practical guide & lessons learned)

Amazon Elastic VMware Service (EVS) is the fastest path to migrate VMware Cloud Foundation (VCF) workloads to AWS bare-metal infrastructure without refactoring. This guide covers the operational benefits, licensing requirements, and a real-world 8-week migration roadmap.

A while back, I was on a call that started like so many migration calls do: half the room was tired, everyone had seen too many “cloud transformation” decks, and the only truly honest sentence was something like: “We’re not against AWS. We’re against breaking production.”

They weren’t wrong to be cautious. The estate was big, mostly VMware, with a heavy Windows footprint, a couple of vendor appliances nobody wanted to touch, and a schedule driven by a contract renewal that was about to get ugly. The teams knew vSphere. The runbooks were written in a VMware dialect. The compliance story was built around familiar controls. And the business didn’t want a heroic migration. The business wanted the data center problem to go away without creating a new one.

That’s the kind of scenario where Amazon Elastic VMware Service (Amazon EVS) stops being “yet another SKU” and starts being a very practical migration option.

AWS describes EVS as “the fastest path to migrate and operate VMware workloads on AWS.” The key mechanism is also very explicit: EVS lets you runVMware Cloud Foundation (VCF) directly inside your Amazon Virtual Private Cloud (VPC), in your AWS account, on qualified EC2 bare metal – without forcing you to replatform or refactor on day one.

This article is the “human” version of that statement: why it matters, what it changes, what it doesn’t, and how I’d approach it if I had to do the same migration again.

Why choose EVS as your cloud platform for VMware?

Most teams don’t wake up one day and decide they want AWS because it’s trendy. They wake up because something in the old world is becoming a blocker.

Sometimes it’s costly. Sometimes it’s capacity. Sometimes it’s a risk: the kind that doesn’t show up in Jira but lives in people’s body language every time there’s a peak traffic event. Often, it’s a VMware Cloud Foundation (VCF) licensing shift or a Broadcom renewal that turns “we can postpone this” into “we need a plan by next quarter.”

And at that point, you’re often not choosing between AWS and the data center. You’re choosing between migration pathways:

• Do we move workloads in a way that keeps the platform familiar and reduces change?
• Or do we take the chance to modernize aggressively, knowing it increases scope and risk?

EVS is not the answer to every migration. But it’s a strong answer when you want one thing above all: reduce the number of things changing at the same time.

If you’re still weighing your options, check out our low-risk playbook for moving from VMware to AWS, developed by our senior cloud architects.

What is Amazon EVS? The native VMware migration tool for AWS

Here’s a description I use when I want to be precise without writing a brochure:

EVS lets you deploy and run VMware Cloud Foundation in your Amazon VPC within your AWS account. You’re still running VMware. You still have the VMware mental model. But your underlying infrastructure now sits on AWS, and your VMware environment lives “next to” AWS services, making it hard to replicate with a traditional on‑prem setup.

AWS frames it as operational consistency: keep familiar VCF software and skills, no replatforming/refactoring required up front. That matters because it changes the migration conversation from “rewrite your world” to “relocate your world safely.”

Not forever. Not as a philosophy. As a sequence.

Reducing complexity in the VMware migration process

People often think speed is about data transfer throughput and migration tooling. Those matter. But the hardest part is usually organizational.

When you migrate from VMware to a fully AWS-native stack, you don’t just change infrastructure. You change:

• how identities and access are managed
• how incidents are handled
• how backups and restores are done
• how networking is expressed and controlled
• how changes are deployed
• how auditors interpret evidence

Even if the technology is “better,” the transition is disruptive. EVS reduces that disruption by keeping the operational surface area familiar at the beginning. It buys you something very valuable: time to modernize intentionally rather than under pressure.

This is why AWS also highlights the “no IP changes, no retraining, no rewriting runbooks” message in EVS migration positioning (depending on your chosen connectivity and migration approach).

EVS pricing and VMware Cloud Foundation (VCF) licensing

EVS is a VMware-on-AWS model. So yes, money and licensing are central.

AWS is clear that EVS requires you to bring your own VMware Cloud Foundation (VCF) license purchased from VMware by Broadcom or a qualified reseller. The user guide describes this as VCF subscriptions with license portability entitlements that you bring to AWS (BYOL).

On the AWS side, pricing is described as three components:

• EC2 bare metal instance usage
• a pair of VPC Route Server Endpoints per environment
• and an hourly EVS control plane fee

That’s useful because it anchors your cost model: you can separate “VMware licensing reality” from “AWS infrastructure reality.” It also makes it easier to do the thing that actually matters: compare EVS not to a fantasy, but to your real baseline — data center cost, VMware licensing, and operational overhead.

Technical execution: Using VMware HCX and migration tooling

The migration tooling in EVS supports 3 methods: live migration (vMotion) for zero-downtime, bulk migration for high-volume waves, and cold migration for legacy apps. To ensure data integrity and prevent data loss, VMware HCX creates an encrypted tunnel for an efficient migration across the public cloud.

When people say “EVS is a migration tool,” the practical question is: how do workloads move?

AWS documentation explicitly covers migrating workloads to EVS using VMware HCX once EVS is deployed. AWS also published a post on accelerating VMware migrations to EVS with HCX and the connectivity decision (VPN vs. Direct Connect), highlighting Direct Connect as a common accelerator with flexible bandwidth and more reliable throughput for large-scale migrations.

This is the part I wish more teams understood early:

Migration success is usually limited by network design and connectivity, not by the migration tool.

HCX can be configured. EVS can be deployed. But if your routes, DNS, firewall rules, latency expectations, and hybrid dependencies are unclear, you end up with a migration that is “technically possible” but operationally fragile.

So, in practice, EVS migration readiness is less about “did we click the deploy button” and more about “did we make the network boring.”

See how we applied these principles in our case, AWS migration for TradeSmarter, where we stabilized a high-load trading infrastructure.

8-week roadmap: VMware migration best practices

Week 1 feels like discovery, but emotionally it’s negotiation.

Not between vendors. Between teams. You’re aligning what “safe” means. Is “safe” zero downtime? Or “a predictable maintenance window”? Is keeping IPs “safe” keeping IPs? Or using DNS cutovers? Is “safe” avoiding application changes? Or being okay with small config edits?

You pick a pilot that is representative but not a crown jewel. You define what the business can tolerate. You stop pretending you can migrate everything the same way.

Week 2 is where you learn whether the environment is well understood or just well survived.

You start talking about connectivity. You look at dependencies. And suddenly someone remembers the weird firewall exception that exists only because of that one old integration. This is normal. The point isn’t to shame the past. The point is to capture it before the cutover.

Week 3 is when EVS becomes “real.”

AWS says you can deploy VCF environments in hours using a guided workflow. That’s true, but the deeper reality is: deploying is not the same as operating. This is where you validate management access, the service access subnet behavior, monitoring expectations, and, most importantly, who owns what in day‑2.

Week 4 is where you do the first migration that you almost don’t care about.

That sounds wrong, but it’s healthy. Your first migration should be a sacrificial learning loop. You watch what breaks: DNS surprises, MTU issues, time sync assumptions, weird old hard-coded values. You learn what your real throughput looks like. You learn what rollback means in your world.

Weeks 5-8 are where discipline matters more than architecture.

If you treat migrations as one-offs, every wave will be painful. If you treat it as a factory-style pre-checks, runbooks, validation, postmortems, even when nothing fails-the migration speed goes up, not down. EVS is meant to enable this kind of repeatable relocation.

And then something interesting happens: once a meaningful chunk of workloads runs “on AWS” but still inside VMware, your teams start breathing again. That’s when modernization stops being a crisis and becomes a roadmap item.

Expert lessons: 4 pitfalls to avoid when you migrate from VMware

What would I do differently next time? This is the part I wish someone had told me.

I’d be blunt. EVS is powerful, but it doesn’t save you from bad sequencing. Here are the lessons I’d bake into any EVS-first migration:

1) I’d treat licensing as a technical dependency, not a procurement detail.

EVS requires BYO VCF licensing. If you discover late that your license portability or subscription terms don’t align with your target timeline, the project stalls in the worst possible way: not because engineering is hard, but because paperwork is slow.

2) I’d invest earlier in a “hybrid reality map.”

Most EVS migrations are hybrid for some time. That means routing, DNS, identity and security boundaries need to be clear. The first time you realize that an app depends on a data center-only service is not a fun surprise. You want those surprises in a spreadsheet, not in a cutover window.

3) I’d set expectations that EVS is not the final transformation.

If leadership hears “fastest path,” they may conclude “we’re done.” EVS is the fastest path to relocate and operate VMware workloads on AWS. It is not a guarantee of cloud-native cost structure or managed-service operational simplicity. That next layer still needs intention.

4) I’d plan modernization as a “second track” from day one.

This is the EVS superpower: you can run two tracks in parallel. Track A relocates. Track B modernizes the things that make the biggest difference (databases, storage, CI/CD, observability). If you wait until relocation is done to start thinking about modernization, you lose momentum, and you keep paying for complexity longer than necessary.

A simple way to decide if EVS is your best first step

If your priority is speed + low disruption, EVS is designed for you. If you’re optimizing for immediate cloud-native modernization, EVS may still be useful, but it might be an intermediate step you can skip if you have the capacity and risk tolerance.

The best EVS use cases are the ones where you can honestly say: “We need to move out of the data center first. We can modernize after the platform is stable.”

And if you can say that, EVS gives you a very concrete path: VCF in your VPC, migration with HCX, connectivity choices like Direct Connect, and a cost model that is explicit about its components.

Ready to modernize your cloud infrastructure?

Executing a successful migration at scale requires more than just the right tool. You need a proven migration approach that prevents data loss and ensures a seamless transition for your VMware customers. At Geniusee, we help VMware customers access up to $2M in AWS MAP funding to ensure a low-risk, cost-efficient path to the cloud. Schedule a free call with our AWS experts.