Why VMware licensing gets expensive even if nothing changes

The tricky part of VMware licensing is that your cost can rise even when your workload demand is flat. The most common root causes look like this:

VMware Cloud Foundation (VCF) subscription licensing: The new center of gravity

If you want to optimize costs, you need to understand what you’re optimizing against. Under modern VCF program documentation, a key rule is:

VCF is subscription software licensed per core, with a minimum of 16 cores per processor, and every core on the server must be licensed (including deactivated cores).

That “16 cores per CPU minimum” is one of the most important cost levers. It means even if you buy a smaller-core CPU, you may still pay for 16 cores per socket. And if you buy a very high-core CPU, you may pay for all of those cores.

There is also a broader operational shift: VCF 9.0+ uses subscription-based license files instead of the old 25-character keys, with license usage tracked through Broadcom’s tooling and workflows.

3 levers that reduce VMware licensing cost

Here are 3 levers that reliably work in real environments. Everything else is usually a variation of these.

Lever A: Reduce licensable cores (hardware + cluster design)

If licensing is per-core, then the most direct savings come from reducing the number of cores that must be licensed.

That can mean:

• Consolidating workloads onto fewer hosts (without compromising HA requirements).
• Retiring underused clusters.
• Re-thinking “one cluster per team” patterns when they cause licensing fragmentation.
• Avoiding unnecessary scale-up to extremely high core-count hosts when you don’t need them.

This is a core part of our IT infrastructure optimization services — fewer licensable cores equals lower subscription capacity requirements.

Lever B: Reduce the VMware footprint (move workloads away)

If you can move a portion of workloads off VMware through legacy software modernization (to AWS-native services, containers, or managed databases), you shrink the VMware estate and, therefore, the required subscription capacity.

This is often the biggest long-term lever because it prevents “license gravity” (where everything is forced to stay on VMware because the platform exists).

Lever C: Increase license efficiency (right-size before you pay)

A surprising amount of VMware spend is tied to “big VMs on big clusters” that were allocated years ago. The hidden win is that right-sizing often triggers second-order effects:

• Smaller VMs allow higher consolidation ratios.
• Higher consolidation reduces the number of hosts needed.
• Fewer hosts means fewer sockets/cores to license.

So “rightsizing” isn’t just an AWS thing. It’s a VMware licensing optimization strategy, too.

Where AWS fits: Treat migration as a licensing optimization project, not just a hosting move

A lot of companies approach “VMware to AWS” as an infrastructure relocation story. That’s a missed opportunity. If licensing cost is your pain, your migration strategy should explicitly answer:

1. Which workloads should stay on VMware (temporarily or long-term)?
2. Which workloads should move off VMware first to reduce subscription capacity?
3. What right-sizing evidence do we have (not guesses) to support redesign and CFO buy-in?

This is exactly the gap our VMware to AWS migration framework, specifically the AWS OLA, is meant to address.

AWS OLA: The mechanism that turns “we think we overpay” into numbers

AWS describes the Optimization and Licensing Assessment (OLA) as a way to assess on-prem and cloud environments and provide recommendations to optimize instances and licensing. According to official AWS documentation, the OLA is a no-cost engagement designed to build a data-driven business case before you commit to a migration strategy.

There are 2 details from AWS documentation that are particularly useful in practice:

Even though the AWS Prescriptive Guidance page is written for Microsoft workloads, the method matters here: if you’re going to optimize VMware licensing and AWS cost, you want time-series utilization, not static snapshots.

AWS also explicitly claims license efficiency benefits: “performing an AWS OLA offers 60% greater license efficiency,” and that overprovisioning third-party licensing increases TCO. And in a Cloud Operations blog post, AWS cites analysis of 300 OLAs delivered by partners, suggesting reductions in required core licenses for Windows Server and SQL Server (the point being: OLA is designed to optimize license-driven costs, not only compute).

EVS as a licensing strategy: Keep VMware, change the infrastructure boundary

Sometimes, “move off VMware” is not immediately realistic. You may have too many legacy workloads, be constrained by change windows, or simply need a safer intermediate step.

This is where Amazon Elastic VMware Service (Amazon EVS) becomes relevant. Not as “modernization”, but as a way to relocate VMware operations into AWS while keeping VMware tools. AWS is explicit that EVS requires bringing your own VMware Cloud Foundation (VCF) license.

So EVS is not the path to eliminate VMware licensing costs. But it can be part of a cost strategy when:

You want to avoid rebuilding apps right now.

You want AWS infrastructure flexibility and procurement model.

You want to use VMware license portability / BYOS models where applicable.

To be clear: EVS can reduce data center costs and accelerate the timeline, but it does not remove VCF licensing requirements, as BYOS is required for the service.

MAP and VMware Migration Accelerator (VMA): funding/incentives that change the math

If licensing pressure is driving urgency, funding often becomes the deciding factor. AWS has multiple programs. In our VMware context, the following 2 names appear often:

• MAP (Migration Acceleration Program) — the broad migration funding framework.
• VMware Migration Accelerator (VMA) — AWS describes it as providing credits when migrating VMware Cloud on AWS workloads to EC2, to lower cost and reduce risk.

These incentives don’t “optimize licensing” directly, but they reduce the upfront cost of doing the work that reduces licensing long term (assessment, planning, migration execution).

A practical process you can follow without getting lost in vendor noise

Here’s a clean process that works whether you migrate now or later:

Step 1: Build a licensing-aware inventory

Not just “VM count”, but where your licensable core footprint really lives: clusters, host core counts, and which workloads require the VMware stack.

Step 2: Identify “license reduction candidates”

These are workloads that are good targets to move off VMware first:

• stateless apps
• batch workloads
• dev/test environments
• workloads with clear modernization paths

Step 3: Run an OLA-style sizing exercise

Lite if you need speed, Full if you want accuracy.

Step 4: Choose your path

• If you can modernize: move those workloads to AWS-native services → shrink VMware footprint.
• If you need relocation first: use EVS as the bridge → modernize gradually.

Step 5: Make cost optimization continuous

Treat licensing optimization as an ongoing discipline:

• quarterly right-sizing
• consolidation reviews
• decommissioning campaigns (especially old clusters)

Take control of your VMware spend

Don’t let the Broadcom transition dictate your budget. Geniusee specializes in turning complex licensing audits into actionable savings.

Schedule your complimentary VMware-to-AWS Assessment

Closing thought

The most important mindset shift is this:

VMware licensing is not just a procurement problem. It’s an architecture and capacity problem.

The organizations that win are the ones that treat licensing spend as a signal: it’s telling you where your platform is oversized, fragmented, or stuck in old assumptions. AWS doesn’t magically erase that. But AWS gives you two powerful things: a platform that makes right-sizing easier to operationalize and mechanisms like OLA that turn assumptions into data-backed optimization plans.

How Geniusee helps you navigate the Broadcom shift

• Rapid licensing audit: We use AWS OLA (Lite and Full) to turn your RVTools data into a clear cost-reduction roadmap.
• Funding strategy: We identify which workloads qualify for AWS MAP or VMA credits to make your migration self-funding.
• Architectural right-sizing: Besides “lift and shift”, we optimize your core counts to ensure you only pay for the performance you actually use.

Ready to see the numbers? Let’s run your OLA assessment together. Book a call with our DevOps experts.

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.

If you recognize yourself in that sentence, you’re exactly the audience AWS had in mind when they created Optimization and Licensing Assessment (OLA) and Migration Acceleration Program (MAP).

On high‑level marketing slides, this looks linear: run an OLA, gather data, join MAP, secure funding, migrate, celebrate. In real projects, OLA and MAP are more like a pair of frameworks with their own boundaries, prerequisites, and technical details, mainly when your world revolves around VMware, and you’re trying to decide how aggressively to modernize.

In this article, I unpack how OLA and MAP actually behave when you apply them to a VMware estate: 

• what data OLA needs and produces
• how it treats licensing
• how MAP funding is tied to concrete phases of work and what kind of organization realistically qualifies

I’m not trying to restate the AWS documentation word‑for‑word. I’ll reference it where it matters, then add the commentary that doesn’t fit on official product pages.

Why does AWS bother to build OLA at all?

If you read the OLA page on Amazon AWS, you’ll see a neutral description: the assessment “helps check your on-premises and cloud environments and provide recommendations to optimize instances and licensing”. It sounds like just another generic “we’ll analyze your stuff” offering.

The real driver is more painful: in most on‑prem environments and especially on VMware, cost and reality are completely decoupled.

There is no straightforward way to answer “which applications drive which portion of this bill, and what would happen if we changed the platform underneath them?”

If you try to talk about migration in this context, you very quickly end up in a “feelings vs. feelings” argument. Engineers feel that the current estate is a mess. The CFO feels that change is risky and potentially expensive. Nobody has data precise enough to settle the debate.

AWS OLA is AWS’s attempt to break that deadlock. It effectively says:

AWS says OLA can provide insights into VMware licensing, resource usage, storage, dependencies, and costs.

The two faces of OLA: lite snapshot vs. full telemetry

On paper, OLA is one program, but in practice, it has at least 2 operational modes as AWS describes in their prescriptive guidance.

Light version

The lite version is for environments where workloads run on VMware, and you don’t want, or aren’t allowed, to deploy agents to every VM. In this case, you export configuration and inventory data from vCenter. People often use RVTools for this, and AWS explicitly mentions it and provides that CSV/XML output. This gives a point‑in‑time view: which VMs exist, how many vCPUs and how much RAM they have, what kind of storage they occupy, and which clusters they live on.

With that snapshot, AWS can already do some basic mapping:

• These 40 virtual machines look like candidates for a certain EC2 family based on their sizing.
• These ones are running Windows / SQL Server and fall under those licensing rules.
• This is your footprint in terms of cores and sockets.

The downside is that it’s static. If a VM has 16 vCPUs but uses 5% of them, a single snapshot doesn’t capture that. It’s still beneficial for licensing analysis, and AWS notes that the turnaround in this mode can be as quick as a handful of days, but don’t expect perfect right‑sizing.

Full version

The full version of OLA is technically much more interesting because it sees time. In that mode, you deploy agents on your workloads (or use existing ones, depending on the tooling) and collect CPU, memory, I/O, and sometimes even process‑level or query‑level data continuously over 2-4 weeks. AWS mentions third‑party tools like Cloudamize as typical engines for this.

With continuous telemetry, OLA can tell a very different story:

• “Yes, this VM is configured with 8 vCPUs, but it rarely goes above 20% aggregate usage.”
• “These three VMs are idle for 18 hours a day and only spike during batch windows.”
• “This SQL Server instance is memory‑bound; CPU doesn’t justify its current size.”

Once you feed that into AWS’ pricing and sizing models, you don’t just map “vCPU 8 → m6i.2xlarge”. You start to see options: maybe you can comfortably run a particular workload on a smaller family with burst capabilities, or maybe you can shrink your core footprint and thus your license exposure without touching functionality.

This distinction (snapshot vs. time series) matters a lot in a VMware environment because VMs were often over‑provisioned to compensate for old hardware, unknown traffic patterns, or simply as an insurance policy. A static snapshot will faithfully capture the over‑provisioning. Time‑based OLA will quantify just how over‑provisioned you are.

Beyond VM counts: the licensing dimension

If OLA only produced prettier capacity reports, it wouldn’t justify its own existence. The reason it’s central to migration planning is its licensing analysis.

AWS is quite blunt about the goal: the OLA e‑book talks about helping customers “save on third‑party licensing costs and run your resources more efficiently”, using workloads like Microsoft, VMware, Oracle, and SAP as examples. Independent solution briefs focused on VMware repeat the same theme: OLA surfaces opportunities to reduce VMware licensing costs and achieve 60% greater VMware license efficiency by tuning how you run those workloads in the cloud.

In practice, the licensing part of OLA does 3 things for VMware estates:

1. It enumerates where commercial software actually runs. Not “where we think SQL Server is”, but where the binaries, services, and usage metrics say it is.
2. It applies the vendor’s current licensing rules, which can be arcane, especially after all the changes in the VMware / Broadcom world, to your current layout.
3. It simulates alternative layouts on AWS: fewer, right‑sized instances; different architectures; possible use of BYOL vs license‑included options; or moves to managed services where the license is built into the service cost.

If your VMware clusters are licensed per CPU or per core and your workloads are gently idling on oversized VMs, OLA can quantify the space between what you’ve paid for and what you actually use. That gives you concrete levers:

• Consolidate VMs, shrink cores, or reassign them to different hosts in a way that still respects performance and compliance.
• Move some workloads away from clusters or license constructs that are particularly expensive under Broadcom’s new terms, for example, to Amazon Elastic Compute Cloud (EC2) or services like Amazon Elastic VMware Service (EVS) that support VMware Cloud Foundation license portability.
• Reevaluate whether you should bring your own licenses to AWS or let AWS handle licensing as part of the service in some parts of the stack.

Addition: AWS likes to attach numbers to this. In their OLA marketing, they talk about average cost reductions of around a third when customers actually implement the right‑sizing and licensing changes they suggest. Whether your number will be 10%, 30%, or more depends heavily on how aggressively you over‑provisioned and how rigid your current contracts are. But the important shift is qualitative: you’re no longer arguing about whether there are savings. You’re arguing which of several specific, modeled options you’re willing to pursue.

Why OLA alone is not enough

At this point, you might ask: if OLA gives me such a detailed picture and a list of optimization levers, why do I need MAP at all?

The short answer is: OLA tells you what’s possible; MAP helps pay for and structure the path to get there.

An OLA report is still a static artifact. It doesn’t create a landing zone, move a single VM, or resolve your organizational questions about roles, skills, and operating models. It’s a map, not the journey.

This is why workloads that appear in OLA marketing (VMware, Microsoft, Oracle) tend to also appear in MAP case studies. OLA often feeds into the Assess phase of MAP, and MAP is where the funding and the delivery mechanics live.

MAP: From spreadsheet to funded program

On the MAP page, AWS describes it as a proven cloud migration program that lets you reduce costs, automate execution, and achieve your migration goals with an outcome-driven methodology. There’s a lot of marketing language there, but buried inside is a very operational idea: for large or strategic migrations, AWS is willing to co‑invest if you follow a structure that increases the likelihood of success.

The structure is the well‑known three‑phase model:

Assess phase

For VMware migrations, the Assess phase is where you combine what OLA told you about your actual usage and licensing with your own view of business priorities. You might discover, for example, that 60% of your license spend is concentrated in 20% of your workloads, or that certain applications are technically trivial to move but business‑critical, which changes how you stage waves.

AWS prescriptive guidance on large migrations emphasizes that Assess and Mobilize are the foundation: you’re supposed to enter the later part of MAP – Migrate & Modernize – with a solid portfolio view, not a list of random VMs. MAP funding in Assess typically supports the effort needed to reach that state: detailed analysis, joint workshops, and building a migration backlog with enough detail to commit real resources.

Mobilize phase

In this phase, you start touching AWS more seriously. This is where you design and implement your landing zone, define which accounts and network topology to use, and connect AWS to your VMware world via VPN or Direct Connect. It’s also where you establish foundational practices that MAP explicitly depends on, such as resource tagging. The MAP documentation has an entire section on tagging migrated workloads, because funding, reporting, and governance depend on being able to say “this EC2 fleet over here corresponds to that set of migrated on‑prem workloads over there.”

Migrate & modernize phase

Finally, in migrate & modernize, you apply the engine built in Mobilize to actual workloads. That’s where your VM‑to‑EC2 mappings, your decisions about databases and storage, and your chosen migration tools all come together. AWS’s own guidance suggests splitting this into an initialization stage, where you prove the patterns with pilot migrations, and an implementation stage, where you run waves at scale.

Across all 3 phases, AWS can attach different pots of MAP funding. The AWS partner funding page is fairly clear: MAP funds “support you with migrations or modernizations of any size or workload to AWS, at each phase of the customer’s migration journey,” and they can be provided as cash or AWS promotional credits. The exact size of those pots and the conditions attached depend on your projected AWS usage, your portfolio size, and how compelling your business case is.

Funding: Not free cloud, but shared risk

There’s a misconception that MAP is a way to get free cloud infrastructure from AWS. That’s not how it works.

In practice, MAP funding behaves more like a risk‑sharing mechanism. MAP Credits are issued in connection with the migration plan and migrated workloads. AWS looks at your migration and says: if you move this much of your workload to our platform and do it in a structured way that properly uses our services, we’re willing to put some of our own money on the table up front.

Sometimes that money offsets partner professional services. Sometimes it shows up as AWS credits that reduce your invoices during migration. Sometimes it’s a mix. But in all cases, there are strings attached:

• You’re expected to align your plan with the MAP phases and to adopt basic practices such as tagging.
• You’re expected to actually execute the migration within a realistic timeframe, not run an endless readiness program.
• You’re expected to land in an AWS estate that looks like a serious, long‑term deployment, not a temporary mirror of your VMware clusters.

From a technical perspective, that means you can’t just rely on OLA to tell you “EC2 size X is cheaper than your current VM.” You need to think about how your architecture, operating model, and automation will change. That’s precisely what MAP forces you to do.

Need a VMware-to-AWS plan with numbers behind it?

Geniusee run the assessment, quantify licensing and right-sizing opportunities, and execute migration waves with a MAP-aligned delivery model.

Explore our VMware to AWS migration service

What a “good” VMware candidate for OLA + MAP looks like

No AWS document explicitly states that it will only support customers with revenue above X dollars per month. Still, reading between the lines of their guidance and partner materials, some patterns are apparent.

On the infrastructure side, you want enough VMware footprint to make optimization meaningful 

If you’re running a handful of VMs, you might still get value from an OLA for education, but the licensing and right‑sizing gains won’t justify a complex program. Once you’re in dozens or hundreds of VMs, especially with a mix of Windows, SQL Server, Oracle, maybe some third‑party middleware, the optimization surface grows dramatically.

On the organizational side, there has to be an appetite to change 

If your goal is to replicate your vSphere clusters 1:1 in AWS, keep the same licensing and operational practices, and just hope the bill will magically shrink, OLA and MAP will probably frustrate you. They are biased towards modernization and making your estate easy to evolve on AWS, not towards preserving every quirk of your current setup.

On the commercial side, the migration needs to be large or strategic enough to justify AWS’s co‑investment

That doesn’t always mean massive enterprise. It can also be an ISV (Independent Software Vendor) whose product will run on AWS, or a company in a target industry. But there needs to be a credible story that, after the migration, your AWS usage will be sustained and non‑trivial.

The other ingredient is time. MAP is often framed around a 12‑24‑month horizon for the bulk of the migration, in line with AWS prescriptive guidance on large migrations. If your posture is “we might think about cloud in 5-7 years, no commitments yet,” you can still explore OLA with a long‑term lens, but the funding side of MAP will be harder to justify.

Why it’s worth understanding OLA and MAP before you make a decision

The main value of OLA and MAP lies not in the promise of magic savings or fully funded projects. They inject structure and evidence into a conversation that, without them, tends to be vague and emotional.

OLA forces you to confront how your VMware workloads actually behave and how your licensing money is really being used. MAP forces you to think of migration as a multi‑phase program with clear milestones rather than a weekend adventure, and it offers financial support if you’re serious enough to follow through.

Even if you ultimately decide that now is not the right time to exit VMware, going through an OLA and sketching how MAP would apply to your estate changes the quality of your decisions. You stop saying “we think we’re overspending” and start saying “we know which workloads are responsible, we know what the alternatives cost, and we know what AWS is and isn’t willing to co‑fund.”

That shift (from fog to numbers, from generic fears to specific trade‑offs) is often the most important step in the whole VMware‑to‑AWS story, regardless of how fast you choose to walk the rest of the path.

Let’s start?

Deciding to move a VMware estate is a responsible moment, and you shouldn’t have to guess the numbers. If you’re looking for comprehensive guidance or a free assessment of your specific environment, get in touch with our AWS team. We can help you find the data you need to make an informed decision.