The AWS Migration Acceleration Program is the most-misunderstood line item in cloud migration. This is the operational walkthrough — the real timeline from discovery to optimize, exactly who does what at each phase (you, the partner, AWS), how the funding flows so a typical migration nets out near $0, and a realistic worked example. Not the brochure; the run-book.
The Migration Acceleration Program is AWS's structured, co-funded path for moving existing workloads onto AWS. Strip away the branding and it is two things bolted together: a methodology (a phased way to run the project) and a funding mechanism (money that offsets the cost of running it).
The methodology half is the three-phase model AWS has standardised across thousands of migrations: Assess, Mobilize, Migrate. It exists because migrations fail in predictable ways — teams skip discovery, under-build the landing zone, then try to move everything at once. The phases force discovery before delivery and a pilot before a production wave. Even unfunded, the structure is worth copying.
The funding half is what makes "MAP-funded" different from "a migration." AWS contributes in two distinct currencies, and conflating them is the single most common misunderstanding. The first currency is AWS service credits applied to your bill — these offset the cost of running the migrated workload during and after the move. The second is partner-delivery funding paid by AWS to the partner doing the work — this offsets the cost of the labour. You feel the first as a smaller invoice; you feel the second as a professional-services engagement that costs you far less than its sticker price, sometimes nothing.
That two-currency structure is why the headline "$0 migration" is real but needs an asterisk. Real engineers do real work for real weeks. The reason your cheque is near zero is that AWS is paying for the destination — they want your workload on AWS for the next decade, so they subsidise the move. The honest framing throughout this piece: the migration is funded, not free of effort. Your team still shows up.
One more orientation point. MAP is not a grant you "win" and then spend however you like. It is consumption- and milestone-based. The assessment incentive is earned by completing the assessment. The migration credits accrue against workloads you actually land on AWS. If the project stalls at 30% migrated, you get roughly 30% of the migration funding — not the full pool. This keeps everyone honest and is the reason partners care as much as you do about actually finishing.
MAP gives you a phased method (Assess → Mobilize → Migrate) plus two kinds of AWS money — service credits that shrink your bill and delivery funding that pays the partner — sized to your post-migration spend, so a qualifying migration can net out near $0 in cash even though the work is entirely real.
Here is the whole arc in order, with the durations a mid-sized migration (say, 40–120 workloads moving off a single source environment) actually sees in 2026. Treat the ranges as honest, not optimistic — the wide bands are where most of the variance lives.
The five stages below map onto MAP's three funded phases plus a pre-phase (Discovery, which precedes the MAP record) and a post-phase (Optimize, which is where the FinOps value compounds after cutover). Funding attaches to the middle three.
What happens: A lightweight inventory of the source environment (how many servers, which databases, rough dependencies, current monthly spend), a first-cut business case, and submission of the MAP opportunity into AWS's partner systems. This precedes formal Assess funding — it is the qualification gate.
Who drives: The partner runs the application and writes the business case; you provide the inventory inputs and a sponsor who can say "yes, we intend to migrate." AWS reviews the opportunity for eligibility.
What can stall it: No clear sponsor, or a source environment nobody can describe. If you cannot answer "roughly how much do you spend now and on what," budget extra time here.
What happens: Deep discovery. Automated tooling (AWS Application Discovery Service, Migration Evaluator, or partner equivalents) maps dependencies, right-sizes the target, and produces a TCO model and a wave plan. The output is a migration readiness assessment and a directional total-cost-of-ownership case that justifies the spend AWS is about to fund against.
Who drives: The partner runs the assessment and models the target architecture; you grant read access to the environment and validate that the discovered dependencies match reality. AWS funds this phase via the assessment incentive once the assessment is completed and submitted.
What can stall it: Access. Discovery tooling needs to see the environment; procurement or security review of that access is the usual bottleneck. Start the access conversation on day one of Assess.
What happens: You build the foundation you migrate into. That means the landing zone (multi-account structure, networking, identity, guardrails), the operational runbooks, security baselines, a CI/CD path, and a pilot migration of one or two low-risk workloads to prove the pattern end to end. Nothing production-critical moves yet; you are de-risking.
Who drives: The partner builds the landing zone and runs the pilot; you make the architecture decisions that are actually business decisions (account boundaries, who owns what, compliance constraints) and sign off on the pilot. AWS funding shifts here from the assessment incentive to partner-delivery funding, and the first service credits begin to apply to the pilot workloads now running on AWS.
What can stall it: Treating the landing zone as a checkbox. An under-built landing zone is the number-one cause of painful Migrate phases — every shortcut here becomes a per-wave tax later. This is the phase to spend care, not speed.
What happens: Production workloads move in waves — batches of related applications cut over together, each wave a mini-project with its own test, cutover, and validation. Most migrations run 4–12 waves. The strategy per workload is decided in Assess: rehost (lift-and-shift), replatform (lift-and-reshape, e.g. self-managed database → RDS), or refactor (re-architect). Most 2026 migrations are mostly rehost with selective replatforming.
Who drives: The partner executes each wave and runs the cutovers; you own go/no-go on each wave, provide the application owners who validate that things work, and run user acceptance. AWS pays the largest share of both delivery funding and service credits across this phase, because this is where workloads actually land on AWS and start consuming.
What can stall it: Wave validation. The cutover is rarely the hard part; confirming the migrated app behaves correctly under real traffic is. Thin application ownership — nobody who can confidently say "yes this works" — is what turns a two-week wave into a six-week wave.
What happens: After cutover, you right-size instances, adopt Savings Plans or Reserved Instances against the now-known baseline, retire over-provisioned resources, and apply Well-Architected fixes. This is where a migration stops being a cost and starts being a saving. MAP service credits are typically still burning down here, cushioning the optimisation period.
Who drives: Mostly you, optionally with the partner on a smaller FinOps engagement. AWS's formal funding role has ended — though Well-Architected reviews and other programs can fund follow-on work.
What can stall it: Nothing stalls it; it simply gets skipped. Teams declare victory at cutover and leave 20–40% of the savings on the table. The migration is finished; the value is not.
These bands assume a single source environment and a team that can give the migration real attention. Multiply timelines for: multiple source clouds, heavy refactoring, strict change-freeze windows, or a part-time internal team. The funding does not speed up the calendar — it removes the cost barrier, not the complexity. A funded migration of a hard environment is still a hard migration.
The reason MAP migrations work — and the reason the ones that go badly went badly — comes down to the division of labour. Three parties, three clean lanes. When a lane gets crossed (you trying to do delivery, or the partner trying to make business calls), things slow down.
The simplest mental model: you own the decisions and the access; the partner owns the delivery; AWS owns the money and the guardrails. Each party is doing the thing it is uniquely positioned to do. You know your business and control your environment. The partner has done this dozens of times and holds the AWS funding paperwork. AWS holds the chequebook and sets the technical bar.
Companies under-resource the one lane only they can fill: application owners for wave validation. The partner can move the bytes, but only your people can confirm the migrated app is correct. Migrations that staff this lane finish on the optimistic end of every range above; migrations that don't, drift to the pessimistic end.
This is the section most guides skip, and it is the one that makes "$0 migration" believable instead of suspicious. There is no single cheque. The near-zero net is the sum of several flows arriving in different currencies at different phases. Trace them and the magic disappears — it is just structured incentives.
Recall the two currencies from Section I: service credits (smaller AWS bill) and partner-delivery funding (cheaper or free professional services). Add the assessment incentive at the front, and you have three flows. Here is the order they arrive and what each one offsets.
Stack the three flows and the picture is clear. The assessment is funded, the delivery is largely or fully funded, and the running cost is credited down. What remains for you in cash is, in a well-sized migration, close to nothing — and what you spend in effort is the part that was never going to be free: your team's time deciding, accessing, and validating. That is the honest shape of a "$0" MAP migration.
AWS funds the Assess phase through an assessment incentive paid once the assessment is completed and submitted. Practically, this means the discovery, TCO modelling, and wave planning — work the partner does — is offset by AWS. For you, the assessment is typically at no cost. This is the first reason your cheque is small: the most analysis-heavy phase is funded before any workload moves.
During Mobilize and Migrate, AWS pays the partner delivery funding tied to the migration milestones — landing zone built, waves completed, workloads landed. This is the flow that offsets labour. Depending on the size of the migration and the funding tier, this can cover a large share of the partner's engagement cost — and in well-sized migrations, effectively all of it. This is why you can have a real partner doing real delivery without a large professional-services invoice.
The honest nuance: delivery funding is sized to the migration's scale and the post-migration run-rate. A small migration earns less delivery funding, so the partner may charge a residual fee; a large migration can be fully covered. "Near $0" is most literally true in the upper-mid range where the destination spend justifies full funding.
As workloads land on AWS, service credits apply to your monthly bill, offsetting the cost of running the migrated estate during the move and for a window afterward. These credits accrue against actual consumption — they are not a lump sum you draw down freely. The effect: your AWS invoice during and just after migration is heavily discounted, cushioning the period before you have optimised and committed to Savings Plans.
Because credits are consumption-based, they reward actually finishing. A migration that lands 80% of its workloads earns far more service credit than one stalled at 30% — another structural reason every party is aligned on completion.
MAP is not for every migration. There is a floor, and there are profiles where the answer is "use a different path." Knowing this up front saves weeks of pursuing funding you won't receive.
The broad eligibility shape in 2026: an existing workload moving onto AWS from somewhere else (another cloud or on-premise), a credible business case, a delivery partner, and a post-migration AWS run-rate that clears MAP's floor — commonly framed around ~$5K/month of projected AWS spend at the entry end, with the richer funding tiers expecting a six-figure-plus annual run-rate. Below the floor, MAP's overhead isn't worth it and AWS won't size meaningful funding to it.
The thing to internalise: funding is sized to the destination, not the difficulty. Two migrations of identical pain — one landing at $4K/month, one at $40K/month — receive very different funding, because AWS is buying future consumption, not reimbursing your suffering. This is counter-intuitive and worth saying plainly: a hard, small migration may be barely funded; an easy, large one may be fully funded.
If your post-migration AWS bill will sit comfortably above ~$5K/month, MAP is worth pursuing and the upper tiers come into reach. If it will sit below that, treat MAP as unlikely and look at a lean partner-led migration or startup credit programs instead. The destination spend, not the migration's complexity, is the gate.
Abstract walkthroughs hide where the time and money actually go. Here is a representative, anonymised-pattern migration — composite, not a single named customer — traced through every phase with rough durations and how the funding lands.
The setup. A mid-market SaaS company runs ~60 workloads in a co-located data centre: a mix of Linux web/app servers, a couple of self-managed PostgreSQL databases, a message queue, and assorted batch jobs. Current infrastructure spend is roughly $35K/month. They want out of the data centre before a lease renewal nine months away, and they project ~$28K/month on AWS post-migration after right-sizing. That destination run-rate puts them squarely in MAP territory.
Discovery & application (week 0–3). A partner inventories the estate, confirms the ~$28K/month projection is credible, writes the business case around the lease deadline, and submits the MAP opportunity. The sponsor is the VP of Engineering; the lease gives the project urgency, which helps. Funding outcome: opportunity approved, assessment incentive lined up.
Assess (week 3–8). Discovery tooling maps dependencies and surfaces two surprises — an undocumented internal service three other apps depend on, and a database far larger than anyone admitted. The partner builds the TCO model and a wave plan: 8 waves, mostly rehost, with the two PostgreSQL databases replatformed to Amazon RDS. Funding outcome: assessment completed and funded; the company's cash cost for this phase is effectively $0.
Mobilize (week 8–16). The partner builds a multi-account landing zone (separate prod/non-prod, centralised logging and identity, network baseline, guardrails) and runs a pilot: two low-risk batch jobs and one stateless web service. The pilot flushes out an IAM-permissions gap and a DNS-cutover wrinkle — exactly what a pilot is for. Funding outcome: partner-delivery funding begins; first service credits hit the pilot workloads. Company cash cost remains near $0.
Migrate (week 16–36, ~5 months). Eight production waves. Early waves (stateless services) move fast — about a week each. The database replatforming waves are the slow ones: data sync, validation, and a carefully scheduled cutover each take longer, pushing those waves to two to three weeks. The undocumented internal service found in Assess gets its own dedicated wave so its three dependents can be cut over together. Application owners validate each wave; one wave slips a week on validation, which is normal. Funding outcome: the bulk of delivery funding and service credits land here, tracking the workloads as they go live.
Optimize (week 36+). With the full estate on AWS and a known baseline, the team right-sizes over-provisioned instances, commits to Savings Plans against the steady-state, and retires a handful of resources that turned out to be dead. The $28K/month projection settles closer to $23K/month after optimisation. Residual MAP service credits cushion these first months. Funding outcome: no new MAP funding, but the largest recurring saving of the whole project is realised here.
Across the project: the assessment was funded, partner delivery was largely funded by AWS (the company paid a modest residual on the heavier database waves), and service credits offset the running cost through Migrate and into Optimize. Net cash cost to the company was a small fraction of an equivalent unfunded migration — and the recurring AWS bill, post-optimisation, came in below the old data-centre spend. The expensive part was never the cash; it was the engineering attention across ~9 months.
| Phase | Typical duration | Who drives | Key output | AWS funding | What stalls it |
|---|---|---|---|---|---|
| 0. Discovery & application | 1–4 weeks | Partner + your sponsor | Inventory + business case + MAP opportunity | Qualification only | No sponsor; unknown environment |
| 1. Assess | 2–6 weeks | Partner (you grant access) | Readiness assessment + TCO + wave plan | Assessment incentive | Access / security review |
| 2. Mobilize | 4–10 weeks | Partner (you decide architecture) | Landing zone + runbooks + pilot | Delivery funding begins + first credits | Under-built landing zone |
| 3. Migrate | 2–6 months | Partner (you own go/no-go) | Production waves cut over | Bulk of delivery funding + service credits | Thin wave validation |
| 4. Optimize | ongoing | You (optional partner FinOps) | Right-sizing + Savings Plans + WAFR fixes | None (residual credits burn down) | Getting skipped entirely |
Knowing the arc is useless without a first move. Here is what the opening fortnight looks like if you decide to pursue a MAP-funded migration — deliberately small, because the whole point is to qualify before you commit.
Day 0 — assemble three facts. You need only three things to begin a serious conversation: roughly how much you spend on infrastructure now, roughly what you're running (count of servers, the main databases), and a named sponsor who can authorise the project. You do not need a detailed inventory yet — that is literally what the funded Assess phase produces.
Day 0–3 — get matched to a partner. The single highest-leverage decision is partner selection, because the partner carries the MAP paperwork, the funding relationship, and the delivery track record AWS underwrites against. You want a partner with a real migration history and the AWS tier that unlocks the funding tiers you need — not whoever is nearest. (This is the step CloudRoute handles: it routes your migration to a vetted, MAP-capable AWS partner matched to your stack, region, and size — see the box below.)
Day 3–7 — the qualification conversation. A 30–45 minute call where the partner pressure-tests fit: is the destination run-rate above the floor, is there a real migration (not net-new build), is there a sponsor and a deadline. You leave this call knowing whether MAP is realistic and roughly what funding tier you're looking at. If it's a no, you've spent an hour, not a quarter.
Day 7–14 — the MAP opportunity goes in. If it's a go, the partner drafts the business case and submits the MAP opportunity. Your job is to provide the inventory inputs and confirm the sponsor. From approval, the funded Assess phase begins — and from that point, your cash cost is effectively $0 while real work starts.
That is the entire on-ramp: three facts, one matched partner, one qualification call, one opportunity submission. The depth comes later, funded. The mistake to avoid is over-preparing — teams burn weeks building detailed inventories that the funded Assess phase would have produced for free.
The phases and the engineering are broadly the same either way; a competent unfunded migration copies MAP's structure. What changes is who pays, how much scrutiny the design gets, and how the economics land. Here is the honest side-by-side.
| Dimension | Unfunded migration | MAP-funded migration |
|---|---|---|
| Assessment cost | You pay for discovery + TCO | Funded by the assessment incentive |
| Partner-delivery cost | Full professional-services invoice | Largely or fully offset by delivery funding |
| Running cost during move | Full AWS bill from day one | Service credits offset consumption |
| Net cash cost | Six figures is common | Near $0 when well-sized |
| Architecture scrutiny | Whatever you enforce | Well-Architected bar expected |
| Eligibility | Anyone | Post-migration run-rate above the floor (~$5K/mo+) |
| Paperwork overhead | None | MAP records + funding claims (partner-handled) |
| Best for | Small estates below the MAP floor | Substantial migrations above the floor |
Situation: The team had the AWS skills to run the platform but no bandwidth to plan and execute a 70-workload migration alongside the product roadmap — and no appetite to absorb a six-figure professional-services bill or pay the data-centre bill and the AWS bill in parallel during the cutover. They needed the migration funded and delivered, not just advised on.
What CloudRoute did: Routed within a day to a MAP-capable AWS partner with data-centre-exit and RDS-replatform track record in the EU region. The partner filed the MAP opportunity, ran the funded assessment (8-wave plan, mostly rehost with two databases replatformed to RDS), built the landing zone, and executed the waves against the lease deadline. CloudRoute matched and handed off; the partner owned delivery and every funding claim end to end.
Outcome: Migration completed inside the lease window. Assessment funded; partner delivery largely covered by AWS delivery funding (a modest residual on the heavier database waves); service credits offset the running cost through cutover. Post-optimisation AWS spend landed below the old data-centre cost. The customer's out-of-pocket was a small fraction of an unfunded equivalent — CloudRoute's fee was paid by the partner, so the customer paid $0 to be matched.
engagement window: ~8 months · partner delivery: AWS-funded · customer cash to CloudRoute: $0
CloudRoute routes you to a vetted, MAP-capable AWS partner matched to your stack, region, and size — the partner files the MAP paperwork, runs the funded assessment, and delivers the waves. Customer pays $0 to be matched. No procurement, no discovery theatre.