Most enterprises pay full price for their AWS migration. They do not have to.

AWS routinely invests in migrations, modernisation projects, assessments and proofs of concept that are led by qualified AWS Partners, and for a well-scoped project that investment can offset a meaningful share of the cost. Most enterprises across our markets never benefit, because they do not know the support exists, they engage a partner too late, or they scope the project in a way that does not qualify. This post explains why the support exists, what it typically covers, how eligibility is judged and how to prepare, without turning into a catalogue. The specifics depend on your project, and the right way to learn them is a conversation with a partner who does this regularly.

Why AWS pays for part of your migration

AWS grows when workloads move onto it and stay there. Migration is the slowest, riskiest and most expensive step in that journey, so AWS has a direct commercial interest in removing the friction: it helps pay for the assessment that tells you what to move, the planning that de-risks it, and the execution itself, in exchange for the consumption that follows for years afterwards.

Partners are central to the model. The Omdia Partner Ecosystem Multiplier study found that AWS Partners earn $7.13 in revenue for every $1 of AWS sold, and that 61 per cent of that arrives after the initial procurement, in services, managed operations and software (Omdia, 2025). AWS channels its investment through partners because partners carry the delivery risk, hold the competencies AWS has validated, and remain with the customer long after the first workload lands.

For a customer, the practical effect is simple. A migration that would have cost a certain amount in consulting fees and initial cloud spend can cost materially less, provided it is structured and submitted correctly from the start. The money is not a discount you negotiate afterwards. It is an investment AWS makes in a project it has reviewed and believes will succeed.

What kinds of work AWS supports

The support is not one thing. It is a family of mechanisms, each aimed at a different stage or a different kind of organisation. The names and rules change over time, which is one reason we deliberately avoid listing them here. The shapes are stable.

Engagement type	What it covers	Who it suits
Assessment	Inventory of the current estate, dependency mapping, target cost model, business case and a sequenced migration plan	Enterprises with on-premises or hosted infrastructure due for refresh
Mobilisation and migration	Landing zone, security baseline, operating model, pilot waves and full migration execution	Enterprises with an approved business case and an executive sponsor
Modernisation	Re-platforming to containers, serverless, managed databases, data platforms and AI workloads	Enterprises already on AWS or migrating with a modernisation scope
Proof of concept	A time-boxed test of a specific workload against defined success criteria, with the AWS consumption covered	Any organisation with a concrete “will this work?” question
Startups and software companies	Early-stage credits, technical support and go-to-market help for companies building on or selling through AWS	Startups, fintechs and independent software vendors

Two points matter more than the table. First, the assessment is the foundation: the business case it produces, including the projected annual AWS spend, is the document that unlocks everything that follows. Second, the proof of concept is often the easiest place to start, because it is small, time-boxed and answers a question the business already has. Typical proofs of concept we run from Nairobi include a core banking module on Amazon EKS, a warehouse comparison on Amazon Redshift, an agentic assistant on Amazon Bedrock and an SAP test migration.

How eligibility is actually judged

AWS does not fund enthusiasm. Every request is reviewed against a short set of criteria, and understanding them explains most of the outcomes we have seen.

• Projected AWS footprint. Support scales with the annual recurring spend the migrated or new workloads are expected to generate. A larger steady-state footprint attracts a larger investment, and a scope carved too narrowly may fall below the threshold entirely.
• Phase. The mechanism, the share and the paperwork differ between assessing, mobilising, migrating and modernising. A request that mixes phases, or asks for migration support before an assessment exists, is usually sent back.
• A qualified partner. Most mechanisms require the engagement to be led by an AWS Partner holding the relevant competency, such as the AWS Migration and Modernization Competency for migration work, the AWS Data & Analytics Competency for data platforms, or the AWS AI Competency for generative and agentic AI proofs of concept. The competency is AWS’s evidence that the partner has done this type of work before.
• Milestones. Support is released against deliverables, not up front. An assessment pays on delivery of its outputs. Migration support is released as workloads land. This keeps everyone honest about progress and means the timeline in the request has to be real.
• Timing. The request must be approved before the work starts. Retroactive support is rarely granted, and it is the single most common way a qualifying project ends up paying full price.

Practical steps to prepare

Step 1: Have a specific project in mind

Support follows scope. “We want to explore cloud” does not qualify. “We want to migrate our core banking test environments and our data warehouse within 12 months” does. If the project is still vague, an assessment is the right first step, and it is often supported on its own.

Step 2: Know your current cost

The business case needs your current infrastructure cost: hardware depreciation, data centre or hosting fees, licences, power, support contracts and the people who maintain it all. A starting figure, even an approximate one, accelerates everything. The assessment will refine it.

Step 3: Name an executive sponsor

Requests require customer sign-off on scope and timeline. A sponsor who can commit the organisation is essential, and their involvement signals to AWS that the migration will happen rather than drift.

Step 4: Engage the partner before you design the project

The partner submits the request, structures the engagement to fit the mechanism, and reports completion. Engaging a partner after you have designed the project yourself usually means the scope does not fit and has to be reworked, which costs weeks.

Step 5: Plan modernisation from the start

The largest long-term savings and the largest follow-on support come from modernising rather than lifting and shifting. Designing the first wave to include a modernisation candidate builds the case for the next tranche.

Common reasons requests fail

We see the same handful of problems repeatedly, and every one of them is avoidable with an early conversation.

• The projected AWS spend is below the threshold, usually because the scope was cut too small to feel safe.
• There is no credible timeline, so AWS cannot forecast when consumption will begin.
• The partner lacks the competency the mechanism requires.
• The assessment was done informally and the outputs do not match what the review expects.
• The project started before approval, so the work is treated as already funded by the customer.
• The customer treats the support as a discount to negotiate at the end rather than an investment to structure at the beginning.

For public entities in Kenya there is a further reason to get this right: the assessment outputs that AWS expects, an application inventory, dependency map, target architecture and cost model, are largely the same artefacts the Cloud Policy 2025 implementation guidelines expect in a migration plan. One piece of work serves both purposes.

What this looks like across our markets

The pattern we have seen in Nairobi, across East Africa and increasingly in the Middle East is that the enterprises that benefit are not the largest ones. They are the ones that start the conversation early, with a real project and a sponsor, and let a partner shape the scope so that it fits. A mid-sized bank refreshing its test estate, a logistics company retiring a hosted ERP, a public entity with a data centre contract approaching renewal: each of these is a candidate, and each would typically pay full price if nobody asked the question.

Eligibility genuinely depends on the project. The honest answer to “how much will AWS cover?” is that nobody can say until the scope, the footprint and the phase are known. The honest answer to “is it worth asking?” is almost always yes.

What to do next

If you have infrastructure due for refresh, a hosting or data centre contract approaching renewal, or a modernisation you have been deferring on cost grounds, make the first conversation about support rather than architecture. A short scoping call establishes whether your project fits an assessment, a proof of concept or a full migration, and what a realistic path to approval looks like.

Shujaa.ai is an AWS Advanced Tier Services Partner headquartered in Nairobi, holding the AWS Migration and Modernization Competency, the AWS Data & Analytics Competency and the AWS AI Competency, which qualifies us to lead supported assessments, migrations and AI proofs of concept across Africa, the Middle East and Europe. Learn more about our AWS partnership.