By How do I fund an AWS migration?
AWS migration funding is accessed through partner-applied programmes covering three phases: assessing the existing estate, preparing for migration, and executing it. An AWS Partner submits an opportunity-specific application before work begins, and approval determines what portion of project cost the funding offsets.
The timing constraint is the detail that costs organisations the most money. Funding is applied for against planned work, and it cannot normally be attached retrospectively to a migration already underway. Organisations that start migrating and seek funding afterwards generally find the opportunity has closed.
AWS does not publish funding rates, thresholds, or tier structures. Amounts are determined per opportunity and are subject to confidentiality, which means any specific percentage or figure circulating publicly should be read as an estimate rather than a published rate.
Which AWS funding programmes apply to a migration?
Three categories of programme apply, and they address different phases rather than competing with each other.
| Phase | What it funds | What the organisation gets |
|---|---|---|
| Assessment | Review of the existing estate, licensing position, and utilisation | A migration plan and a defensible cost estimate, useful whether or not a migration proceeds |
| Migration support | Architect, cloud engineer, and software engineer hours | The bulk of the workload migration effort delivered by people who have done it before |
| Post migration credits | A proportion of projected AWS spend, returned as credits | Reduced effective cost during the period when the new run rate is establishing |
The proportion returned as credits is set per opportunity and is not published by AWS. Any specific percentage quoted publicly, including figures that circulate widely, should be read as an estimate rather than a rate.
Assessment. Programmes that examine the existing estate before any migration decision. An Optimization and Licensing Assessment reviews licensing and infrastructure to identify cost reduction, and typically finds savings available whether or not a migration proceeds. A Well-Architected review examines an existing or proposed architecture against AWS best practice.
Readiness and mobilisation. Work that prepares an organisation to migrate: landing zone design, security and governance baselines, operating model definition, and skills assessment. This phase is where training and enablement most naturally attach.
Execution. The migration itself, covering the professional services effort of moving workloads. Co-investment at this phase applies to eligible migrations rather than to all of them, and eligibility is assessed per opportunity against criteria AWS does not publish. Where it does apply, the practical effect is additional delivery capacity committed to a defined window, which is what compresses the calendar.
The Migration Acceleration Program is the structured route through these phases, combining funding with tooling and partner delivery. Its funding levels are opportunity specific and not published.
Assessment funding is the most reliably available and the least used. Organisations routinely pay full price for licensing assessments and architecture reviews that frequently carry funding, because nobody asked.
How do assessment programmes reduce migration cost before it starts?
Assessment programmes reduce migration cost by changing what gets migrated, which is a larger effect than making the migration itself cheaper. Migrating a workload that should have been retired, resized, or re-licensed carries its cost forward indefinitely.
The phase decides three things, in this order: whether the migration is technically and financially sound at all, which workloads should actually move, and what the target architecture is. The third is where the money is. Moving existing virtual machines one for one is the cheapest plan to produce and the most expensive to run. Rightsizing against measured utilisation, decommissioning workloads nobody has owned for years, consolidating what remains, and replacing self-managed components with AWS native services where that is warranted all change the bill permanently rather than once.
An unvalidated plan is a forecast, not a plan.
The discoveries that damage a timeline are concentrated in the oldest parts of the estate. Applications past roughly ten years of service accumulate undocumented dependencies, and with them orphaned systems: components still running, still costing money, with no current owner and nobody able to say what breaks if they are switched off. An assessment finds these while they are still a line in a report. A migration finds them at the point where something has already stopped working. In our experience this is the largest single source of mid-migration surprise, and also the most predictable one, because it tracks application age closely enough to plan around.
Roughly four in five organisations that invest properly in this phase reach cutover without an orphaned application appearing unannounced. That is our own observation across European migrations rather than published research, and it is the clearest reason the phase pays for itself: the cost of the assessment is known in advance, and the cost of the discovery it prevents is not.
That is also where the roadmap cost lands, and it is the reason this phase protects more than the budget. An orphaned system discovered mid-migration does not stay with the migration team. It pulls the developers who know the application off whatever they were building, at no notice and for an unpredictable stretch of time, which is the form of disruption a roadmap absorbs worst. Assessment does not remove that work. It moves it to a point where it can be scheduled, which is the difference between a known cost and an interruption.
That distinction shows up in budget outcomes rather than in savings percentages, and budget outcomes are the more useful measure. Organisations that invest properly in this phase generally land inside the budget they approved. Those that skip it generally overrun, and the mechanism is consistent. Without utilisation data, sizing is decided by safety margin rather than by measurement, so the estate arrives on AWS overprovisioned from the first day.
That overrun does not present as a migration cost. It presents as a run rate that never comes down, because nobody rightsizes a workload that has been running acceptably since cutover. Unwinding it afterwards is the cost allocation and accountability work described in FOCUS and FinOps culture, which is a slower and more expensive way to arrive at a number the assessment could have produced first.
AWS publishes an average of 31% infrastructure saving for customers migrating legacy applications, measured against prior on-premises cost. The figure carries no source and no date on the page that states it. It is also a claim about AWS versus on-premises rather than a claim about migration quality, so it says nothing about how well any individual migration was prepared. In our experience the achievable figure sits below the headline, and the gap is explainable: application debt surfaces mid-migration, some workloads cannot be resized without a code change, and licences do not always transfer on the terms assumed at planning time.
An Optimization and Licensing Assessment examines licensing positions and infrastructure utilisation. Its most common findings are over-provisioned capacity and licences that cost more on AWS under one deployment model than another. Both change the target architecture rather than the migration plan.
A Well-Architected review examines the proposed design against AWS best practice before it is built, and the value is proportional to how early it happens. Reviewing a landing zone at design stage is inexpensive, and rebuilding one afterwards is not.
Both assessments frequently carry funding and are commonly paid for in full instead. For organisations not yet certain about migrating, they are also the lowest commitment way to get a defensible cost picture, since the findings are useful whether or not a migration follows.
What does AWS migration funding not cover?
Migration funding offsets project cost, not the cost of running the resulting platform, and that boundary is where financial models most often break.
Four categories generally fall outside funding.
- Internal staff time. The customer's own engineers, project managers, and testers are not funded, and on most migrations they represent substantial effort.
- Third party licences. Software the organisation must buy or re-license to run on AWS is its own cost.
- Steady state running cost. Once a workload is live, its AWS consumption is normal spend. Funding may contribute during the migration window, not afterwards.
- Remediation of pre-existing problems. Application debt discovered during migration is usually the organisation's own to fix.
Modelling funding as a reduction in project cost rather than a reduction in platform cost avoids the common and unpleasant surprise, which is a migration that came in on budget followed by a run rate nobody forecast.
Is a budget neutral AWS migration realistic?
A budget neutral migration is realistic in specific circumstances and is not a general outcome. Where the conditions hold, stacked assessment, mobilisation, and execution funding can approach the professional services cost of the project, so the migration is delivered for close to no net services spend.
Three conditions largely determine whether that is achievable.
- Scale of migrating workload. Funding scales with the size of the opportunity, so small migrations attract proportionally less.
- Committed and reasonably compressed timeline. Programmes are structured around defined delivery windows rather than open ended projects.
- Willingness to commit to AWS spend. Post-migration commitment is part of the commercial logic of the funding.
Where those conditions do not hold, funding reduces cost without eliminating it, which is still worth pursuing. Presenting budget neutrality as a general promise is the part to avoid, because it sets an expectation that most migrations will not meet, and the credibility cost of that exceeds the value of the claim.
The honest framing is narrower and more useful. Ask which phases can be funded for this specific estate and timeline, and model the residual.
When is an in-house migration cheaper than a partner-led one?
An in-house migration is frequently the cheapest option in direct cost, and saying so is uncomfortable for a partner but true. It is the right choice under three conditions: the team already holds relevant AWS skills or has a deliberate objective to build them, the workload count is modest, and the timeline can flex.
The costs that do not appear on an invoice are where the comparison gets harder.
| Factor | In-house | Partner-led |
|---|---|---|
| Direct services cost | None | Offset by funding, rarely to zero |
| Access to funding programmes | Limited | Primary route |
| Delivery speed | Slower, competing with existing work | Faster, dedicated capacity |
| Risk on unfamiliar workloads | Carried internally | Shared, with prior pattern experience |
| Capability afterwards | Retained internally | Retained only if transfer is explicit |
| Staff opportunity cost | Substantial and usually unmodelled | Lower, and never zero |
The last two rows decide most cases. An organisation whose objective is to own its AWS platform long term should weight retained capability heavily, and should insist that any partner engagement includes explicit knowledge transfer rather than delivery alone. An organisation whose objective is to move quickly and keep internal focus elsewhere should weight speed and risk.
Opportunity cost is the row most often left blank, and it deserves stating plainly. A migration consumes months of internal roadmap capacity, and roadmap capacity is not a cost line. It is the business the organisation did not build during those months.
The planned part of that is manageable, because it was budgeted and accepted before the work started. The damage comes from the unplanned part. Effort that arrives without notice cannot be traded against anything, so it displaces whatever happened to be next rather than whatever mattered least. Priced honestly, an unplanned month is not engineer days. It is the features that shipped later, the customers who waited, and the revenue that arrived in the following year instead of this one. That is the return on a proper assessment, and it does not appear anywhere on the migration invoice.
Funded partner capacity buys calendar time, which is the one thing an in-house migration cannot purchase at any price.
None of that means a migration can be handed over and forgotten, and a proposal implying otherwise should be read as a warning rather than as a service level. Domain experts have to be available to explain what an application actually does, and business stakeholders have to decide what can be interrupted and when. That involvement is not overhead to be minimised. It is what stops a migration breaking something nobody knew was load bearing, and it is the reason the internal cost of a funded migration is lower than an in-house one rather than absent.
That is not automatically an argument for outsourcing, because it turns on a question only the organisation can answer. Migrating is not what differentiates a business. Running the AWS platform afterwards might be. Where platform capability is genuinely part of what the organisation sells, an in-house migration that builds the team is the right answer even though it is slower and attracts less funding. Where it is not, the migration is opportunity cost with no strategic return, and speed is worth paying for.
The decision is also narrower than it first appears, because it concerns one layer of the relationship rather than all of it. An organisation can migrate in-house and still use a partner for a funded assessment beforehand, or for a commercial review of its AWS agreement afterwards. Those layers are described in when a partner beats buying AWS direct.
What sequence gets the most out of migration funding?
The sequence that recovers the most funding starts with assessment and applies for each phase before the corresponding work begins. Funding is phase-gated, so the order of operations determines what remains available.
- Assess before deciding. Establish the estate, licensing position, and target architecture while assessment funding is still applicable.
- Apply before working. Each phase is applied for in advance. Work performed ahead of approval generally cannot be funded retrospectively.
- Separate migration from commitment. Migrate first, establish the real usage baseline, then negotiate commercial terms against observed consumption rather than forecast.
- Attach enablement explicitly. If retained capability is an objective, name training and knowledge transfer as deliverables during readiness, rather than hoping it happens during delivery.
- Model the residual and the run rate. Funding covers project cost. Forecast steady state separately, before committing.
Step three is where the most durable money sits, and it is also the step most often collapsed into the funding conversation by mistake.
Is MAP funding the same thing as a private pricing agreement?
No. They are separate mechanisms with different bases, and treating them as one negotiation is the most common commercial error in migration conversations.
MAP funding is assessed against an opportunity and a forecast. It supports the act of migrating, it is applied for before the work starts, and its basis is necessarily an estimate, because the workloads have not moved yet.
A private pricing agreement is a commitment to AWS spend over a term. Its basis should be the run rate you can observe after migration rather than the run rate you projected before it, and the migration is the thing that produces that number.
So the sequence matters more than the negotiating skill. Migrate, let the consumption baseline settle, then size the commitment against what the estate actually costs to run. Committing earlier means committing against a forecast that the migration itself is still in the process of testing, and every error in that forecast is priced in for the length of the term. The mechanics of the agreement are covered in the AWS private pricing agreement guide.
The two also arrive from different directions, which is part of why they get merged. Migration funding is offered by a partner as part of a delivery proposal. A private pricing agreement is a procurement exercise with a different internal owner and a different timeline. Where both land in the same quarter, the migration should still be allowed to establish the baseline first.
Where do funded migrations usually go wrong?
Funded migrations usually go wrong on sequencing and expectation rather than on delivery. Four patterns recur.
Funding is sought after work has started, at which point the opportunity has generally closed and the cost is absorbed.
Budget neutrality is promised generally rather than conditionally, so a migration that recovered a substantial share of its cost is experienced as a shortfall.
Steady state cost is not modelled alongside project cost, producing an on-budget migration followed by an unforecast run rate.
Knowledge transfer is assumed rather than specified, so an organisation that intended to build internal capability ends up dependent on the delivery partner by default.
All four are avoidable at proposal stage, and none are technical. They are consequences of treating funding as a discount rather than as a programme with conditions, phases, and a defined order.
