AWS Migration Acceleration Program funding, explained — the definitive 2026 guide.

IWhat MAP is — and why it exists

The Migration Acceleration Program (MAP) is AWS's structured, funded methodology for moving an existing workload — from on-premise data centers or another cloud — onto AWS. It pairs a prescriptive playbook with real money: cash incentives and service credits that offset the cost of the migration itself.

MAP exists because migrations are the moment a company decides where its infrastructure will live for the next decade. AWS would rather pay down the friction of that decision than lose the workload to Azure or Google Cloud, or watch a company stay on-premise out of inertia. The credits and cash are not charity; they are customer-acquisition spend, accounted for against the lifetime value of a consolidated cloud customer. Understanding that framing tells you everything about how the funding is sized: AWS funds in proportion to the spend it expects to capture afterward.

Two things distinguish MAP from the credit programs most founders know. First, it is workload-anchored, not stage-anchored. AWS Activate hands credits to a startup because of who it is (Series-A, VC-backed, in an accelerator). MAP funds a company because of what it is moving — the size, complexity, and projected post-migration consumption of a specific workload. A bootstrapped 60-person company migrating a large data estate can unlock far more MAP funding than a flashy seed-stage startup unlocks in Activate.

Second, MAP is phased. It does not arrive as one lump sum on day one. AWS releases funding as the migration de-risks itself — a little at Assess to fund the business case, more at Mobilize to fund the pilot and the landing zone, and the bulk at Migrate & Modernize once production workloads actually move and consumption starts to register. Each phase has its own gate, its own deliverables, and its own funding line. The phases are the spine of this entire guide.

The program has evolved. Earlier MAP iterations leaned heavily on per-server incentives and treated "modernize" as an afterthought. The current 2026 framing — Migrate AND Modernize as a single combined phase — reflects AWS pushing customers past lift-and-shift toward managed services (containers, serverless, managed databases) where consumption, and therefore the post-migration value AWS captures, is higher. Funding now rewards modernization, not just rehosting.

IIThe three phases — and exactly what AWS funds at each

Every MAP engagement moves through Assess, then Mobilize, then Migrate & Modernize. The phases are sequential gates: you do not reach the large Migrate funding without first clearing Mobilize, and you do not start Mobilize without an Assess-stage business case. Here is what each phase contains and what AWS actually pays for inside it.

A useful mental model: Assess answers "should we, and what's the case?"; Mobilize answers "can we, and is the foundation built?"; Migrate & Modernize answers "are we actually moving production, and how much is now running on AWS?" Funding rises sharply across the three because risk falls sharply across the three.

IIIHow the funding is actually calculated

MAP funding is not a published price list. It is a calculation, and the two variables that drive it are (1) the size of the workload you move and (2) the post-migration spend you commit to. Understanding the calculation is how you go from "some credits" to a number you can plan around.

Start with the central concept AWS uses to size everything downstream: committed spend, often expressed internally as ACR (annualized committed revenue) — the projected annual AWS consumption the migrated workload will generate once it is live and ramped. This is the number the business case in Assess produces and Mobilize firms up. Nearly every funding lever scales off it.

The Migrate & Modernize funding then layers two components on top of that committed number:

• The consumption credit (percentage of migration spend) — AWS credits a percentage of the spend the migrated workloads generate during the migration window. The exact percentage is tiered and partner-negotiated, but the structural point holds: it is a percentage of real spend, so it rises directly with how much you move. More workload moved, more spend generated, more credit applied.
• The migration incentive (scope of what moved) — A second component sized to the scope of the migration. Historically this was a per-server cash figure (you migrate N servers, you earn N × a fixed amount). The current model increasingly ties it to the committed-spend tier, rewarding the projected post-migration consumption rather than raw server count — which aligns AWS's payout with its actual return.
• The commitment multiplier (firmness of the spend) — A firm, contractually-backed commitment (e.g., a Private Pricing Agreement or EDP signed alongside the migration) unlocks more funding than a soft projection. AWS pays more when the post-migration revenue is contracted, not merely forecast. This is why large migrations are often paired with a committed-spend agreement.

Put those together and the scaling becomes intuitive. A small migration with a $120K/year projected commitment sits in a low funding tier: a modest Mobilize incentive, a single-digit-to-low-double-digit percentage consumption credit, and a small migration incentive — typically a five-figure total across the phases. A large migration with a firmly-committed $1M+/year spend sits in a high tier: a substantial Mobilize incentive, a larger consumption-credit percentage, a scope incentive tied to that commitment, and often a paired pricing agreement — pushing the total funding into the six figures, sometimes well beyond. The program is deliberately progressive: the more you move and the harder you commit, the larger the share AWS funds.

A practical implication that surprises people: two companies migrating the same number of servers can receive very different MAP funding if one commits to managed, higher-consumption services (Aurora, EKS, Lambda) and the other does a flat lift-and-shift to EC2. The modernized estate generates more projected spend, lands in a higher committed-spend tier, and therefore unlocks more funding. Modernization is not just an architecture choice; under the current MAP model it is a funding lever.

IVEligibility — what AWS actually requires

MAP is broadly available, but it is not for everyone or every workload. Here is the honest eligibility picture: what makes a workload MAP-eligible, where the practical floor sits, and the situations where MAP is the wrong instrument.

MAP is designed for the migration of an existing production workload. That framing carries most of the eligibility logic:

• There must be an existing workload to migrate — MAP funds moving something that already runs — on-premise, in a colo, or on another cloud. A net-new application being built directly on AWS is not a migration; that is a build, and it routes to Activate / build-funding programs, not MAP.
• The workload needs meaningful projected AWS spend — There is no single public floor, but in practice MAP makes sense once the projected post-migration spend is non-trivial — small workloads with a few hundred dollars a month of projected consumption rarely clear the threshold to justify the partner-filed process. Larger estates are squarely in scope. The bigger the committed spend, the better the funding tier.
• A defensible business case (TCO) must exist — AWS funds against a validated case. If the Assess-phase TCO does not show a credible migration with credible post-migration consumption, the funding does not open. The business case is a gate, not a formality.
• A partner must be attached — MAP funding is filed and claimed by an AWS Partner (see Section V). A company cannot self-serve the funding request. No partner, no MAP funding line — this is the most common disqualifier in practice, and the subject of the next section.
• The customer must not be a disqualified party — Standard AWS rules apply: AWS will not fund direct competitors, and US export-control / sanctions rules govern which countries the program can flow to. Companies in supported regions (US, UK, EU, the GCC, India, APAC, and most of LATAM) are fine.

Where MAP is the wrong instrument: a pure greenfield build (use build-funding / Activate); a tiny workload below the practical floor (the partner-filed overhead is not worth it for a few thousand dollars of credit); and enterprise procurement that is really about a pricing contract rather than a migration (that is an EDP / Private Pricing conversation, though it frequently runs alongside a MAP migration). Recognizing which instrument fits saves weeks of filing the wrong application.

VThe partner-filed / APN unlock — how MAP money is actually opened

This is the section most guides skip, and it is the one that decides whether a company sees MAP funding at all. MAP funding cannot be requested by the customer. It is filed by an AWS Partner through AWS's partner systems, tied to a registered opportunity. Understanding this mechanic is the difference between claiming the money and leaving it on the table.

AWS funds partners, and partners fund customers. The flow runs through two connected systems. First, the opportunity is registered in ACE (APN Customer Engagements) — the gated portal AWS Partners use to log customer opportunities and link them to AWS. Second, against that opportunity, the partner submits a MAP funding request through AWS's Partner Funding portal (in Partner Central). The partner attaches the business case, requests a funding tier sized to the committed spend, and an AWS funding manager reviews and approves the dollar amount.

Only certain partners can do this. The partner needs the appropriate APN status and, critically, a MAP / Migration Competency or partner-program designation that authorizes them to file MAP funding. Not every AWS partner can; a generalist reseller without migration designation cannot open a MAP funding line even if they have ACE access. This is why the choice of partner is not interchangeable — it directly determines whether (and how cleanly) the funding gets approved.

The partner-filed request typically carries:

• The registered ACE opportunity — customer name, workload, projected spend, linking the engagement to AWS
• The validated business case (TCO) — the dollar case the Assess phase produced
• The committed-spend / ACR projection — the number that sizes the funding tier
• The phase and funding type requested — Assess incentive, Mobilize cash + credits, or Migrate consumption credit + scope incentive
• The migration plan + wave structure — what moves, in what order, on what timeline
• The partner's delivery role — what the partner will actually execute, since AWS funds the engagement, not a cash handout

Two practical consequences follow. First, the quality of the partner's filing materially affects the approved amount — a well-built business case with a firm commitment and a credible plan lands a higher tier than a thin one. Second, the funding is claimed by the partner and applied to the engagement: AWS reimburses the partner for delivery and the customer's AWS bill is offset by the credits. The customer is funded but is not the entity transacting with AWS's funding desk. If you migrate with no partner, that desk is never contacted, and the money simply never exists for you. This is, mechanically, why most companies leave MAP money on the table — covered in Section VIII.

VIMAP vs Activate — two different instruments people confuse

Founders routinely ask whether they should "get Activate credits or MAP credits," as if they are two sizes of the same thing. They are different instruments with different anchors, different mechanics, and different ceilings. Often a company qualifies for both — for different parts of its AWS footprint.

Activate is stage-and-identity anchored. It funds a startup because of who it is — institutionally funded, early-stage, often VC- or accelerator-affiliated — and it tops out around the $100K Portfolio tier for general-purpose AWS consumption. It is fast, relatively light to file, and it is about getting a young company running on AWS.

MAP is workload-and-commitment anchored. It funds a company because of what it is moving and how much it will spend afterward, and its ceiling is a function of the migration's size — which for a substantial estate runs well past Activate's. It is heavier to file (phased, partner-built business case) and slower to mature (months across phases), but the funding scales with the workload rather than capping at a tier.

The two are not mutually exclusive, and the sophisticated play is to use each for what it is for. A Series-A company migrating an existing on-premise data estate might take Activate Portfolio for its net-new product workloads and run a parallel MAP engagement for the migrated estate — two funding lines, two anchors, one company. The comparison table below lays the two instruments side by side.

VIIModernization as a funding multiplier

The current program is "Migrate AND Modernize" for a reason. The modernization half is the most under-used lever in MAP — companies treat it as optional polish when it is, structurally, a way to unlock more funding and more long-term value.

A lift-and-shift moves your existing servers to EC2 with minimal change. It is fast and low-risk, and it is a legitimate first step. But it generates roughly the consumption profile you already had — which lands you in a modest committed-spend tier and therefore a modest funding tier. The workload is on AWS, but you have left funding (and operational benefit) on the table.

Modernizing — refactoring toward managed databases (Aurora), containers (ECS/EKS), serverless (Lambda), and managed storage and analytics — raises projected AWS consumption, which raises the committed-spend tier, which raises the MAP funding. It also reduces the operational toil that the lift-and-shift carries forward. AWS funds modernization specifically because a modernized estate is worth more to AWS over its lifetime, and it shares some of that future value back as higher migration funding now.

The honest tradeoff: modernization adds scope, time, and engineering effort to the migration. It is not free, and not every workload should be modernized in the first wave. The pragmatic pattern most well-run MAP engagements follow is "migrate first, modernize in waves" — get the workload onto AWS to start the consumption clock and the credits, then modernize the highest-value components in subsequent waves, each of which can extend the funding profile. Treating modernization as a sequenced lever rather than an all-or-nothing decision is how companies get both the speed of migration and the funding (and architecture) upside of modernization.

VIIIWhy most companies leave MAP money on the table

MAP is one of the most under-claimed funding programs AWS runs, not because it is hidden, but because the path to it is non-obvious and easy to skip. Here are the specific, recurring reasons companies migrate and never see a dollar of MAP funding.

The through-line across all six: MAP rewards companies that engage the program correctly at the start — with a designated partner, a real business case, a firm commitment, and a modernization plan. The money is not hard to access if the path is set up before the migration begins. It is nearly impossible to recover if the migration is already done. The asymmetry is the whole reason the program is so under-claimed.

• They migrated without a partner — The single biggest reason. MAP funding is filed by a partner through the APN; a company that migrates with only its internal team — or a non-AWS contractor — never opens the funding line. The migration happens, the credits do not. By the time someone realizes, the workload is already moved and the window has closed.
• They used a partner without MAP designation — Having a partner is necessary but not sufficient. A generalist reseller or a partner without the MAP / Migration Competency cannot file the funding even with ACE access. Companies assume "we have an AWS partner" means "we can claim MAP," and find out otherwise after the fact.
• They under-scoped the commitment in Mobilize — The committed-spend number set during Mobilize caps the Migrate funding. Teams that low-ball the projection to seem conservative permanently limit the funding tier they can reach — the ceiling is set before the headline money is requested.
• They skipped the business case — No validated TCO, no funding gate cleared. Teams eager to "just start migrating" skip the Assess-phase business case and discover that the funding request has nothing to attach to. The diligence is the unlock, not a delay.
• They lift-and-shifted everything — A flat rehost lands in a low committed-spend tier and forgoes the modernization funding lever (Section VII). The workload moves, but at a fraction of the funding a partially-modernized migration would have unlocked.
• They started filing too late — MAP funding is meant to be opened before and during the migration, with the Assess business case up front. Companies that try to claim retroactively — "we already migrated, can we get MAP credits now?" — generally cannot, because the program funds the migration as it happens, not after it is done.