AWS Migration Acceleration Program (MAP) Explained: Funding, Phases, and What Actually Gets Approved

The Three MAP Phases

1. Assess

Assess is a 4–8 week discovery sprint. The deliverables are a Migration Readiness Assessment (MRA), a Total Cost of Ownership (TCO) model showing on-prem vs AWS run-rate, and a portfolio inventory classifying every workload against the 7 R strategies. AWS provides funding to cover assessment cost — typically capped at a few tens of thousands of dollars depending on portfolio size — and the partner files for it via an MRA Funding Request in AWS Partner Central.

The output of Assess is an Application Portfolio Assessment (APA) and a high-level migration plan AWS will sign off on before Mobilize funding is approved. If the TCO doesn't show AWS run-rate within ~80% of on-prem, AWS may push back — funding is correlated with the consumption that follows.

2. Mobilize

Mobilize is where most engagements either accelerate or stall. The output is a production-ready AWS environment: an AWS Landing Zone built on AWS Control Tower, an organization with separate accounts per environment, baseline security controls (GuardDuty, Security Hub, Config, CloudTrail organization trail), an IAM federation strategy, FinOps cost-allocation tags, and a CI/CD pipeline scaffold for IaC.

The Mobilize funding tranche covers a meaningful portion of this build — but only if every deliverable is documented in the format AWS requires. This is the work most teams under-scope: the landing zone is technically a few weeks of Terraform, but the governance documentation that goes around it (account vending, break-glass procedure, FinOps tagging dictionary, baseline runbook, security-control mappings to ISO 27001 / SOC 2 / NIS2 if relevant) is what gets reviewed at the gate.

3. Migrate & Modernize

The actual migration phase. Workloads execute against their assigned R-strategy. AWS funding here is the largest tranche and pays out as a percentage of first-year AWS run-rate attributable to MAP-eligible workloads — typically in the 15–25% range, occasionally higher for SAP, mainframe, or VMware migrations under MAP 2.0 specialty programs. The partner attests each workload as MAP-eligible by tagging it with a customer-specific MAP tag, and AWS reads consumption against those tags monthly.

Workloads stay attributable to MAP for 12 months after their migration cutover. After that the funding window closes, even if more workloads move later — those need to be enrolled in a follow-on program (which is allowed but requires a fresh MRA).

The 7 R Migration Strategies

MAP organizes every workload against one of seven strategies. These come from the AWS migration playbook and dictate effort, cost, and AWS run-rate:

• Retire — decommission. ~10–15% of most portfolios are unused or duplicated; identifying them is the easiest TCO win in Assess.
• Retain — leave on-prem for now. Common for licensed software with anti-virtualization clauses or mainframe applications outside MAP's specialty paths.
• Relocate — move with no architectural change, e.g. VMware Cloud on AWS or Outposts. Fastest path; eligible for MAP 2.0 VMware funding.
• Rehost ("lift and shift") — re-deploy on EC2 / RDS without rewriting. AWS Application Migration Service (MGN) is the standard tool. Lowest effort, modest cloud-economics gain.
• Replatform ("lift and reshape") — change one or two layers, like moving SQL Server to RDS or swapping IIS for Application Load Balancer + EC2. Higher economics gain, moderate effort.
• Repurchase — move to SaaS, e.g. Exchange to Microsoft 365, on-prem CRM to Salesforce. Reduces AWS run-rate but is still MAP-eligible for the migration project itself.
• Refactor / Re-architect — significant rewrite to take advantage of cloud-native services. Highest economics gain, largest effort and risk; usually phased post-migration to avoid blocking the cutover deadline.

The portfolio split typically lands around 60% Rehost, 20% Replatform, 10% Refactor, 10% Retire/Retain — though for SAP-heavy or mainframe-heavy portfolios the distribution looks very different.

Who Qualifies — and How Eligibility Actually Works

MAP is open to organizations migrating production workloads currently running outside AWS. The unwritten qualification line is annual AWS spend potential of roughly $250K+ — below that, the funding math doesn't justify AWS's review effort, and partners struggle to get an MRA approved. Above that, eligibility is about workload qualification, not company size.

A workload qualifies as MAP-eligible if:

• It is currently running outside AWS (on-prem, colo, another public cloud, or another AWS account that the customer is consolidating).
• It will be tagged with the customer-specific MAP tag in AWS at cutover and stay tagged for 12 months.
• It is part of a documented migration plan signed off in Assess.

Workloads that do not qualify: net-new cloud-native development, dev/test environments that aren't paired to a production workload, and any workload whose R-strategy is Retain or Retire (since no AWS consumption follows).

What MAP 2.0 Changed

MAP 2.0, active since late 2022, formalized specialty migration paths that previously sat outside the program:

• SAP on AWS — additional funding for SAP migrations under MAP for SAP, with AWS-vetted SAP partners. Tools: AWS Launch Wizard for SAP, AWS Migration Hub Refactor Spaces.
• Mainframe — MAP for Mainframe with AWS Mainframe Modernization service. Pricing model fundamentally different — multi-year contractual.
• VMware — MAP for VMware funds Relocate strategies onto VMware Cloud on AWS, then optional Replatform off VMware later.
• Windows workloads — Optimization and Licensing Assessment (OLA) factors into MAP funding; bringing your own Windows licenses through Microsoft Mobility (where eligible) increases approved credits.

If your portfolio is dominated by one of these workload classes, the right MAP track changes the funding economics significantly. The MRA in Assess identifies which track applies.

MAP vs Other AWS Migration Programs

Where Most MAP Engagements Stall

Three patterns repeat across MAP engagements that don't hit their Migrate & Modernize gate on time:

1. Assess goes too deep. Teams treat the MRA as an architecture review and spend 12 weeks instead of 6. AWS doesn't pay extra for the depth — the funding is fixed against the deliverable, not the hours. The optimum is a fast, opinionated assessment that classifies workloads and exposes the few that need follow-up review, rather than a wall-to-wall analysis.

2. Mobilize lacks the governance documentation. The landing zone gets built quickly. The IAM federation strategy, FinOps tagging dictionary, account vending procedure, and security-control mapping documents lag — and those are what AWS reviews at the gate. Two weeks of writing at the start of Mobilize saves four weeks of back-and-forth at the gate.

3. Tagging discipline collapses at cutover. Every MAP-eligible workload must carry the MAP tag continuously for 12 months for funding to apply. If the tag is missing for even part of a billing month, that month doesn't count. AWS Config rules that enforce the MAP tag and AWS Resource Groups that audit it weekly are non-negotiable for any MAP engagement above seven figures of run-rate.

How Opsio Approaches MAP

Opsio is an APN Migration Competency partner running MAP engagements across the EU and India out of the same 24/7 SOC/NOC that supports our AWS managed services customers post-migration. Practical pattern that consistently lands MAP funding on time:

• Assess in 4–6 weeks, not 12 — opinionated portfolio classification with a hard cutoff on workload-level deep dives.
• Mobilize landing zone delivered as Terraform modules off a hardened internal baseline, with the governance documentation written in parallel rather than after.
• Continuous MAP-tag audit via AWS Config + Security Hub findings escalated to our SOC, so no workload drifts off the tag mid-month.
• FinOps reporting that ties every workload's actual spend back to its R-strategy projection from Assess — so when AWS asks why a workload is 30% over its TCO model, the answer is in the dashboard.

The right MAP partner is not the one who promises the largest credit. It's the one whose Assess-phase TCO survives the first six months of post-cutover reality — that is what governs whether the Migrate & Modernize tranche actually pays out.

Frequently Asked Questions

What are the 7 migration strategies in AWS?

Retire, Retain, Relocate, Rehost, Replatform, Repurchase, and Refactor. They classify how each workload moves: from leaving it alone (Retain) to a full cloud-native rewrite (Refactor). Most portfolios end up with roughly 60% Rehost, 20% Replatform, 10% Refactor, and 10% Retire/Retain, but the distribution depends heavily on the underlying technology mix.

What is a migration accelerator?

A migration accelerator is a structured program — methodology, tooling, partner network, and funding — that an organization uses to migrate workloads to a public cloud. AWS MAP is the canonical example. Azure has a parallel program (Azure Migrate & Modernize); GCP runs a Rapid Migration Program (RaMP). All three pair partner-led delivery with consumption-tied funding.

How much funding does AWS MAP actually provide?

For most engagements, total MAP credits land in the 15–25% range of first-year AWS run-rate attributable to MAP-eligible workloads. Specialty paths (MAP for SAP, MAP for Mainframe, MAP for VMware) can fund more, depending on workload eligibility and the OLA outcome for Windows licensing. The credit pays out to the partner in tranches against the three gates, then the partner applies it to the customer.

Do we need a partner to use MAP?

Yes. MAP is delivered exclusively through APN partners with the AWS Migration Competency designation. AWS does not run MAP engagements directly — Professional Services may co-deliver alongside a partner on very large engagements, but the partner is contractually required.

How long does a MAP engagement take?

From the MRA kickoff to the close of the Migrate & Modernize phase, expect 9–18 months for a 100-workload portfolio, including a 6–12 month migration window. Smaller portfolios compress to 6–9 months; SAP / mainframe-heavy or regulated portfolios extend past 18 months because the gates require additional compliance documentation.