MAP is the program that lets you migrate to AWS at little-to-no net cost. AWS funds the assessment, credits a meaningful share of the migration and modernization spend, and pays the partner who runs the cutover. But MAP is partner-filed via APN — there is no public form, and most companies either never hear about it or leave half the funding on the table. This is the working mechanic: the three phases, what AWS funds at each, how the money scales, who qualifies, and how to claim it.
MAP is not a discount code or a single credit grant. It is a structured, multi-phase program AWS uses to de-risk and co-fund migrations — because every workload it pulls off Azure, GCP, Heroku, Oracle, or a data-centre rack becomes years of committed consumption revenue. AWS funds the move to capture the run-rate that follows.
Mechanically, MAP wraps three things into one engagement: a methodology (a phased playbook AWS and its partners run thousands of times a year), a tooling stack (Migration Hub, Application Discovery Service, Application Migration Service / MGN, Database Migration Service / DMS, the Schema Conversion Tool / SCT, DataSync, Transfer Family), and — the part everyone cares about — funding: AWS credits applied to your bill, plus partner-investment dollars AWS pays directly to the partner doing the work.
The defining feature, and the one that trips up first-timers, is that MAP is partner-led and partner-filed — you do not apply on a webpage. An AWS Partner Network (APN) partner registers the migration, attests the source environment and projected AWS spend, and claims the funding; AWS reviews the partner's submission, not yours. It is identical in shape to the AWS credits cluster (see $100K AWS credits — partner-filed Activate Portfolio and AWS POC funding explained): real, public-page-invisible, gated behind a partner attestation.
The honest framing matters because the program is easy to over-sell. MAP funding scales with the migration — its size, complexity, and committed post-landing AWS spend. A genuine production migration with a meaningful run-rate unlocks the full Assess → Mobilize → Migrate ladder; a tiny workload with negligible projected spend does not qualify for MAP dollars, and the right move there is a vetted-partner referral that de-risks the cutover without pretending AWS will write a cheque. CloudRoute triages which you are before anyone files anything. The next sections cover the two answers you came for — how much AWS funds, and how to get it — starting with the three phases, because the funding is structured around them.
MAP funding is released phase by phase — each with a different objective, deliverable, and funding posture. AWS funds the cheap, low-risk discovery first, then the pilot once the business case holds, then the production migration once the landing zone is proven. Each gate protects AWS's investment and, usefully, yours — a migration that fails the Assess gate is one you should not start.
Objective: build the business case. The partner runs discovery — usually via AWS Application Discovery Service and Migration Hub — to inventory servers, databases, dependencies, and current spend, then produces a Total Cost of Ownership (TCO) model comparing your present run-rate to the projected AWS bill, plus a readiness assessment scoring you across people, process, platform, and security.
What AWS funds: typically delivered at no cost to you — AWS subsidises the assessment because it qualifies the opportunity cheaply. For you it is a free, rigorous answer to "should we do this, and what will it cost?"
Deliverable + duration: a TCO/business case, a 7-Rs disposition per application (Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor), a target architecture sketch, and a wave-structured plan — in 2–4 weeks (days for a 30-server Heroku shop, the full four weeks for a 400-VM on-prem estate with undocumented dependencies).
Objective: close the readiness gaps Assess found and prove the migration with a low-risk pilot. This builds the foundation — a secure, multi-account AWS landing zone (Control Tower, Organizations, guardrails, networking, logging, IAM baseline), a migration factory, and a runbook — then migrates a first non-critical wave to validate the tooling and cutover end to end.
What AWS funds: MAP credits and partner-investment funding begin here. Representatively, partner funding often offsets on the order of a quarter of eligible migration services cost — enough to substantially de-risk the foundation work and pilot. Exact percentages are deal-specific, set in the partner's MAP funding request.
Deliverable + duration: a production-ready landing zone, a proven runbook, a migrated pilot workload, and a committed wave plan — in 4–8 weeks (the landing zone is the long pole; a mature multi-account setup compresses it considerably).
Objective: move production in waves, with rollback at every step. Rehosts go via MGN (agent-based block-level replication, near-zero-downtime cutover); databases via DMS, with SCT handling heterogeneous conversions (Oracle → Aurora PostgreSQL, SQL Server → Aurora); bulk data via DataSync or Transfer Family. "Modernize" is the selective refactor — containerising onto ECS/EKS, moving self-managed databases to RDS/Aurora.
What AWS funds: the largest share lands here. MAP credits offset a meaningful portion of the production and modernization spend, and partner funding scales with committed post-migration run-rate — the bigger and more committed the workload, the larger the envelope (next section).
Deliverable + duration: production on AWS, the source decommissioned, cost validated against the Assess TCO model, and a backlog for modernization better done after you land — in 8–24+ weeks by estate size, wave count, and how much modernization you fold in versus defer.
The phases are not bureaucracy — they are the funding gates. AWS funds Assess to qualify the deal, co-funds Mobilize to prove it, and funds the largest share of Migrate to capture the run-rate. A partner who knows the program sequences your waves so each gate releases the next tranche, keeping the migration close to cash-flow-neutral. A team filing MAP for the first time often discovers the funding rules after doing work that could have been funded — which is exactly the money left on the table.
The most-asked question — "how much will AWS actually fund?" — has an honest two-lever answer: the size of the migration (eligible services spend) and the AWS run-rate you commit to after landing. There is no fixed public figure; like Activate Portfolio, it is a discretionary range set per deal.
Two stacking sources. AWS credits offset a share of your actual AWS consumption during and after the migration, released across the Mobilize and Migrate phases. Partner-investment funding — money AWS pays the partner, not you — offsets the migration services cost (the labour). Because the partner is funded directly, a qualifying migration can net out to little-or-no cost to you: credits cover the infrastructure, partner funding covers the work.
Both levers key off the same number: your committed post-migration AWS spend. AWS funds migrations in proportion to the run-rate it expects to earn afterward. A workload projected at a few hundred dollars a month will not unlock MAP funding; one landing at ~$5K–$15K/month opens the standard ladder; six-figure annual commitments unlock proportionally larger envelopes and, past a threshold, layered programs (EDP/PPA committed-spend discounts negotiated with your AWS account team).
As a mental model — exact terms set deal-by-deal in the partner's funding request and AWS's approval: in Mobilize, partner funding commonly offsets ~25% of eligible services cost; in Migrate, the offset is larger and the credit share against consumption rises with committed spend. For a mid-sized migration the combined funding routinely covers the majority of all-in cost; for a substantial enterprise migration the dollars run well into six figures. There is no single headline number — funding is sized to your migration, and it is the partner's job to claim every tier you qualify for (the table below shows the phase-by-phase posture).
| Phase | What unlocks funding | AWS funding posture | Net effect on your cost |
|---|---|---|---|
| Assess | A real estate to discover + a plausible TCO case | Assessment subsidised — typically delivered at no cost | Free business case + readiness score |
| Mobilize | Approved business case + committed wave plan | MAP credits begin; partner funding ≈ ~25% of eligible services cost | Landing zone + pilot substantially de-risked |
| Migrate & Modernize | Proven landing zone + committed AWS spend | Largest share; credits + partner funding scale with run-rate | Majority of all-in cost offset on qualifying deals |
MAP is broad but not universal — AWS funds migrations it expects to convert into committed consumption. The honest eligibility picture: who is squarely in scope, who is borderline, and who should pursue a different path.
The most common eligibility mistake is self-disqualifying: teams assume MAP is "for enterprises only" and never ask, when a mid-sized SaaS migrating a $6K/month estate is exactly the profile the program was built for. The free Assess phase exists to settle this before anyone commits.
This is barely documented publicly, and it is the whole game. MAP funding is gated behind an APN partner submission — and the gap between a partner who claims the full funding and one who leaves half unclaimed is the difference between a funded migration and an expensive one.
AWS routes migration funding through the AWS Partner Network because partners do work AWS would otherwise staff itself, and because a partner's attestation is AWS's due-diligence layer. When a qualified partner registers your migration, they create a structured record AWS reviews — much like the ACE (APN Customer Engagements) records used for credit applications. There is no equivalent record you can file as the end customer: you are the workload, the partner is the filer.
The MAP opportunity record the partner submits typically contains:
Here is where partner quality converts directly into dollars: the funding tiers are not automatic — they are claimed. An experienced partner knows which programs stack (MAP credits + partner-investment funding + any applicable Activate layer), sequences the wave plan so each gate releases the next tranche, and sizes the committed-spend projection to maximise the envelope; a first-time or low-tier filer frequently claims one tier and misses the rest. This is the gap CloudRoute closes: we route you to a vetted APN partner with a real MAP track record and the tier (Advanced or Premier) that carries full funding-submission rights, matched to your migration (Heroku, GCP, Oracle, on-prem, SAP). The partner files MAP, runs it, and is paid through it — so on a qualifying deal your net cost trends toward $0, and you never see an invoice from us. (Full economics: the migration persona detail.)
Founders constantly conflate MAP with Activate credits. They are different programs with different triggers, but on the right deal they stack — and knowing which applies, and when both do, is worth real money.
Activate funds net-new startup workloads — you are building on AWS and AWS credits the build (the $5K Founders tier up to $100K Portfolio and beyond; see $100K AWS credits). The trigger is "startup building on AWS." MAP funds migrations — you move an existing workload from elsewhere, and AWS funds the move plus credits the resulting consumption. Activate is build-led; MAP is migration-led. Both are partner-filed, public-page-invisible, and scale with credible projected AWS spend — which is why CloudRoute treats them as one routing problem.
They stack when you have both motions at once — more common than it sounds. A Series-A company migrating its Heroku monolith (MAP) while building a brand-new GenAI feature on Bedrock (Activate Portfolio + Bedrock POC) can run both in parallel through one partner, provided each funds a genuinely distinct workload. AWS will not fund the same workload twice — claiming both against the identical migration gets the second request downgraded to $0 — but a real migration plus a real net-new build is two legitimate sources.
Migrating an existing workload → MAP is your primary funding source. Building something net-new on AWS → Activate credits. Doing both at once → run both in parallel through one partner, one workload each. Never claim both against the same workload — that is the fastest way to get a funding request downgraded.
You cannot start MAP by filling in a form, because the form is the partner's. What you can do is get matched to a partner who files it correctly, fast — here is what the first stretch looks like end to end.
Step 0 — Size the opportunity (you, 5 minutes). A rough answer to three things — what you are migrating from, the approximate estate size (servers/databases/apps), and a ballpark of current monthly spend — is enough to know whether you are above the MAP threshold or in Activate territory.
Step 1 — Get matched to an APN partner (CloudRoute, < 24h). Submit an inquiry; CloudRoute triages it and routes you to a vetted partner matched to your source platform, region, and the partner tier MAP requires. You get a scheduling link — no procurement, no RFP theatre.
Step 2 — Assess phase (partner + AWS, 2–4 weeks, $0). The partner runs discovery, builds your TCO model and readiness assessment, and produces the 7-Rs disposition and migration plan — the free "should we, and what will it cost" answer, and the basis for the funding request.
Step 3 — Partner files the MAP opportunity (partner, days). The partner registers the migration through APN, attests source/target and projected spend, and claims the Mobilize + Migrate funding tiers; AWS reviews the submission.
Step 4 — Mobilize, then Migrate (partner, weeks → months). Landing zone and pilot, then production cutover in waves, with AWS funding released at each gate. You hold go/no-go at every wave; the partner carries the execution and the funding paperwork.
Why go through a partner-matching layer rather than cold-emailing a consultancy: funding quality is partner quality, and a random Select-tier shop may not even have full submission rights. CloudRoute's job is to put you in front of the right partner in under a day. See the AWS Migration hub for the full cluster, and AWS POC funding explained for how the same mechanic funds proofs-of-concept.
Even teams that find MAP routinely under-claim it — after enough routed migrations, the same gaps recur. Here is the money most companies leave behind, and how not to be one of them.
The throughline: MAP funding is claimed, not granted automatically, and it is claimed by your partner. The single highest-leverage decision in the program is which partner files it — and that is the one thing CloudRoute is built to get right.
The funding is structured around the phases, so this is the table that matters. What each phase is for, what AWS funds, what you walk away with, and roughly how long it takes. Percentages are representative; the exact funding is set in your Assess-phase funding request.
| Phase | Objective | What AWS funds | Your deliverable | Typical duration |
|---|---|---|---|---|
| 1 · Assess | Build the TCO + readiness business case | Assessment subsidised — usually $0 to you | TCO model, 7-Rs disposition, readiness score, migration plan | 2–4 weeks |
| 2 · Mobilize | Build the landing zone + prove it with a pilot | MAP credits begin; partner funding ≈ ~25% of eligible services cost | Production-ready landing zone, runbook, migrated pilot wave | 4–8 weeks |
| 3 · Migrate & Modernize | Cut production over in waves; modernize selectively | Largest share — credits + partner funding scale with committed spend | Production on AWS, source decommissioned, cost validated vs TCO | 8–24+ weeks |
Situation: Heroku costs were scaling super-linearly with traffic and the team wanted off before renewal, but the CFO had flagged migration as an unbudgeted cost. They needed RDS/Aurora-grade database reliability, a real multi-account setup for an upcoming SOC 2 audit, and a way to fund the move. Nobody on the team had heard of MAP; they assumed the migration was a six-figure cost they would eat.
What CloudRoute did: Routed within 19 hours to a Premier-tier APN partner with deep Heroku-to-AWS and MAP experience. The partner ran the Assess phase (free) and built a TCO model showing ~45% run-rate savings on AWS, then filed the MAP opportunity claiming both Mobilize and Migrate funding tiers against a committed ~$11K/month projected AWS spend. Mobilize built an AWS landing zone (Control Tower + multi-account, doubling as SOC 2 groundwork) and piloted a non-critical service. Migrate moved the monolith to ECS via a rehost-then-replatform path and Heroku Postgres to Aurora PostgreSQL via DMS, in three waves with rollback at each.
Outcome: Production cut over in 11 weeks across three waves, near-zero downtime on the final cutover. AWS MAP credits plus partner-investment funding covered the large majority of the all-in migration cost; the customer's net out-of-pocket was a small fraction of the original six-figure estimate. Run-rate landed ~45% below Heroku, and the landing zone closed most of the SOC 2 infrastructure gaps as a side effect. CloudRoute's commission was paid by the partner from the MAP engagement funding — the customer paid CloudRoute $0.
migration window: 11 weeks · phases: Assess → Mobilize → Migrate · funding: MAP credits + partner-investment · cost to CloudRoute customer: $0
CloudRoute routes you to a vetted APN partner who files MAP, runs the migration, and gets paid through it — so a qualifying migration nets out near $0 to you. Free Assess phase, no procurement, no RFP theatre.