VMware migration services cost: How AWS OLA and MAP funding work

When people ask me about moving from VMware to AWS and actual migration costs, they rarely start with a technical question. Instead, I hear something like:

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). Both exist because rising VMware licensing costs push teams to price out VMware alternatives long before they have the data to properly compare them.

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 aIn 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.

What determines the VMware migration services cost?

The number of virtual machines is the least useful predictor of what you’ll pay. A reliable estimate must account for the target architecture, workload dependencies, licensing, data volume, security requirements, and the amount of application remediation required before cutover. In my experience, the estimates that fall apart later are the ones that skipped this list.

Most VMware-to-AWS budgets include 4 cost layers:

• Assessment and migration planning
• AWS environment preparation and migration execution
• Temporary infrastructure and parallel operations
• Post-migration AWS services and support

Understanding these layers helps you compare proposals accurately and avoid estimates that focus solely on workload transfer while excluding testing, licensing, modernization, or stabilization.

Assessment and migration engineering

The first cost category covers workload inventory, dependency mapping, AWS architecture design, migration-wave planning, and total cost of ownership analysis. It may also include an AWS landing zone, network connectivity, identity configuration, security controls, and migration runbooks.

The main cost drivers at this stage are environmental factors: undocumented dependencies, outdated operating systems, tightly coupled applications, regulated data, and restrictive cutover windows, all of which push the estimate up.

Rehost, relocate, or modernize

Your migration strategy directly affects both project costs and future operating expenses.

• Rehosting moves workloads to Amazon EC2 with limited application changes. It usually reduces initial engineering effort, but it may preserve inefficient resource allocation inherited from your VMware infrastructure.
• Relocation keeps the VMware operating model through Amazon Elastic VMware Service. EVS is worth understanding precisely because it is often confused with VMware Cloud on AWS. VMware Cloud on AWS is managed by Broadcom. EVS is a native AWS service that reached general availability on August 5, 2025, and runs VMware Cloud Foundation directly inside your own Amazon VPC, with full administrative access to the environment. License portability applies, so you bring existing VCF entitlements across rather than buying new ones. The budget must still include those VCF licenses and the underlying bare-metal instances, and coverage now extends across more than 10 AWS regions.
• Replatforming or refactoring moves applications toward managed databases, containers, serverless services, or cloud-native architectures. It requires more engineering during migration, but can reduce long-term infrastructure and administration costs.

A cost assessment should compare these options by workload instead of applying one strategy to the entire estate. In a large-scale VMware environment, forcing a single strategy across hundreds of VMs is usually where budgets go wrong first.

Temporary and overlapping costs

During migration, organizations often operate VMware and AWS environments simultaneously. The budget may therefore include replication infrastructure, Amazon EC2 test instances, Amazon Elastic Block Store storage, network transfer, migration tooling, and several weeks of parallel operations.

Longer migration windows also increase the cost of staying on VMware: data center contracts, VMware subscriptions, and support agreements continue to run alongside growing cloud resource consumption. A wave plan helps control these expenses by limiting how long each workload remains active in both environments.

How AWS OLA and MAP affect the final budget

AWS Optimization and Licensing Assessment identifies right-sizing opportunities, licensing constraints, and potential AWS configurations before the migration begins. It provides the technical and financial baseline required to estimate the target AWS run rate.

The AWS Migration Acceleration Program may then offset part of the eligible assessment, mobilization, migration, or AWS consumption costs. Funding does not replace a complete project budget. Organizations still need to account for internal labor, existing VMware commitments, unsupported remediation work, decommissioning, and long-term AWS operations.

The most useful estimate, therefore, shows 3 separate figures:

1. Gross migration investment
2. Eligible AWS funding or credits
3. Expected post-migration operating cost

What those offsets look like in practice

Every estate prices differently, so treat the following as planning anchors rather than quotes. A lite OLA turns around in days, while a full telemetry OLA collects for 2 to 4 weeks before analysis begins. Across the projects I’ve worked on, assessment and planning for a mid-sized VMware estate occupies somewhere between 2 and 6 weeks of engineering time, depending on how much dependency archaeology is required. On the funding side, AWS partners report MAP credits ranging from 15% to 25% of projected post-migration ARR, with a VMware estate eligible for a Strategic Partner Incentive worth 10% of ARR up to $200K. Against those offsets sit AWS’s own published licensing figures: an average 77% reduction in Windows Server license costs and 45% for SQL Server. The gross investment stays yours. Funding narrows the gap rather than closing it.

The following sections explain how AWS OLA builds this cost baseline and how MAP funding applies across the migration lifecycle.

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. You can see the total cost of ownership on an invoice, but not what any of it buys you.

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. Neither side can put a VMware migration cost on the table that the other trusts, because nobody has data precise enough to settle the debate.

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

“Let’s freeze the hand‑waving. Give us workload‑level telemetry and licensing details, and we’ll show you (with numbers) where you’re over‑ or under‑provisioned and what that looks like on AWS with different design choices.”

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. Which one fits depends on how far along you are in leaving VMware and how much of that decision still rests on assumptions.

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. It will tell you whether it makes sense to migrate from VMware. It will not tell you what to move first.

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 to 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, maybe you can shrink your core footprint, and thus your license exposure without touching functionality, or maybe a subset of workloads is better served by a VMware-compatible landing zone such as Amazon Elastic VMware Service while the rest moves to native services.

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 their resources more efficiently, using workloads like Microsoft, VMware, Oracle, and SAP as examples The published numbers are worth reading carefully, because AWS scopes them more narrowly than partner marketing often does. The AWS OLA page cites 60% greater license efficiency as a general figure across assessed environments, not as a VMware-specific outcome. Where AWS does publish workload-level results, they cover Microsoft: an average 77% reduction in Windows Server license costs and 45% for SQL Server after migration. For a VMware estate carrying a lot of Windows and SQL Server, those two figures are usually the more relevant ones anyway.

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, reduce cores, or reassign them to different hosts while still respecting 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.

Pulling those levers is where an OLA report stops being a document and becomes infrastructure cost-optimization work with a schedule attached.

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. 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, and the distance between what it tells you and what you need is wider than most teams expect. It cannot build your landing zone or run a single migration wave. It cannot settle who owns the AWS account structure after cutover, or whether your VMware administrators want to become cloud engineers. It cannot judge whether a team already absorbing a data center refresh has the capacity to carry a 12-month program on top of it. Those questions decide whether the savings in the report ever reach the invoice.

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. Getting that foundation reviewed against AWS design principles before workloads land on it is what an AWS Well-Architected Review is for. 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.

The thresholds moved in 2024, and the current ones decide whether you qualify. On July 1, 2024, AWS restructured MAP so that a single consolidated business approval replaces the earlier multi-stage process, and the program now scales to migrations worth up to $10M in annual recurring revenue. A month later, AWS folded a VMware-specific Strategic Partner Incentive into the standard MAP template, which is the piece that matters most if you are leaving VMware behind. AWS partners report the practical thresholds this way: MAP Lite now opens at $100K projected ARR rather than $250K, the VMware SPI pays 10% of ARR in partner cash capped at $200K, post-migration credits typically fall between 15% and 25% of ARR, total partner funding reaches $2M, and 1:1 customer matching no longer applies. Treat the partner-reported figures as directional, since AWS publishes the program mechanics openly but not the full incentive tables.

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.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. For an ISV, the arithmetic works differently: eligibility is assessed against the ARR the product will generate on AWS once customers are running on it, not against what the ISV spends to move its own infrastructure.

The other ingredient is time. MAP is often framed around a 12 to 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 to 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.

Where OLA and MAP programs go wrong

Most of the failure modes are unglamorous, which is exactly why they catch teams out. None of them appear in the program documentation.

The estate gets treated as one decision. Applying a single strategy across hundreds of VMs produces one of two outcomes: a rehost that carries every over-provisioning decision forward into your AWS bill, or a modernization program larger than the team can staff. Per-workload decisions cost more to make and less to live with. Running the migration itself with a DevOps team that stays on after cutover is usually what keeps the second failure mode from happening.

Parallel operations get underscoped. Budgets model the migration and the end state, then treat the overlap between them as a rounding error. You run VMware and AWS together for months, paying for both, and every wave that slips extends that overlap. A wave plan that survives contact with reality is worth more here than a lower headline estimate.

Tagging arrives too late. MAP credits attach to resources tagged as migrated, and the tagging has to happen as workloads move rather than afterward. Teams that schedule it as a cleanup task find funding tranches delayed or refused, because the evidence AWS needs was never captured at the moment it existed.

Mobilize deliverables get underestimated. The landing zone is the visible part, and it is rarely the part that slips. Governance documentation, the FinOps tagging dictionary, and security control mappings consume more of the schedule than teams plan for, and skipping them stalls the funding review rather than the migration.

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, talk to our VMware to AWS migration team. We can help you find the data you need to make an informed decision.