Cloud Provider Funding 101: MDF, Migration Funding and POC Credits Explained

Hyperscaler GTM Playbook Hub & overview ↗

Cloud Alliances P1 – Overview A1 – Partner Programs A2 – Alliance Team ► A3 – Funding A4 – Tenancy Model

Co-Sell P2 – Overview B1 – AWS Co-Sell B2 – Microsoft Co-Sell B3 – Google Co-Sell B4 – Co-Sell Operations

Cloud Marketplace P3 – Overview C1 – Marketplace Listings C2 – Private Offers C3 – Marketplace Operations

AWS, Microsoft and Google Cloud all fund partners – through marketing development funds, migration programs, POC credits and marketplace-transaction incentives. Most ISVs leave a significant portion of this funding on the table, either because they don’t know it exists or because they don’t meet the eligibility criteria they could realistically meet. This post maps what is available, how it works across the three hyperscalers and how to access it.

TL;DR

Hyperscaler partner funding falls into roughly four categories: Marketing Development Funds (MDF), migration and modernisation programs, POC and pilot credits and marketplace-transaction incentives. Each works differently across AWS, Microsoft and Google Cloud.
All funding is tied by design to cloud consumption – the hyperscaler funds partners because they drive consumption growth on the hyperscaler’s platform. Funding without consumption logic underneath it is either misunderstood or about to be discontinued.
Eligibility is often gated by program tier, specialisation or program membership. Funding access compounds with the partner-program investments covered in Cloud Partner Programs and Specialisations.
The unwritten rules matter more than the documented ones. The right relationship depends on the funding type: build the PDM relationship before asking for partner-side funding (MDF, POC credits to the ISV’s account); the AE is the gatekeeper for customer-side credits, and that relationship must be established before the ask is made. The ask has to map to a current hyperscaler priority and reporting back closes the loop on the next funding cycle.
The single most common failure mode is leaving funding on the table because the partner doesn’t know it exists or doesn’t have the operational capacity to apply for it.

Funding Programs at a Glance

The table below maps the major funding programs across the three hyperscalers. Detail per category follows in the sections below.

Category	AWS	Microsoft	Google Cloud
Marketing Development Funds	AWS MDF (cash or AWS Promotional Credits; Services Path Advanced and Premier tiers; ISV Accelerate partners newly enrolled after 1 January 2026)	Microsoft co-op funds (accrued from incentive-program earnings)	Google Cloud marketing funds (detailed MDF terms not publicly documented)
Migration / modernisation	Migration Acceleration Program (MAP); ISV Workload Migration Program (WMP)	Azure Migrate and Modernize; Azure Innovate	Google Cloud migration funding programs
Marketplace-transaction incentives	Marketplace Private Offer Promotion Program (MPOPP)	Marketplace Rewards; Azure sponsorship	Marketplace Customer Credit Program (MCCP) and adjacent incentives
POC and pilot credits	AWS customer credits (via PDM or AE) for partner-led POCs	Azure customer credits (via PDM or ATS)	Google Cloud customer credits (via PDM or AE / CE)
Eligibility gate	APN tier; ISV Accelerate; relevant Specialisation	MAICPP tier; Solutions Partner designation; Azure IP Co-Sell Eligible (varies by program – Marketplace Rewards needs only a Partner ID and a published offer)	Google Cloud Partner Network tier; relevant competency

Most programs operate on annual or semi-annual funding cycles aligned to the hyperscaler’s fiscal year, with some additional ad-hoc allocations for strategic pursuits.

Why Hyperscalers Fund Partners

The structural reason hyperscalers fund partners is simple: partners drive cloud consumption. Growing consumption on its own platform is the central commercial aim of a hyperscaler’s partner spending. MDF funds marketing activity that builds pipeline for the partner’s solutions on that cloud. Migration funding offsets the cost of moving a workload onto the hyperscaler’s infrastructure. POC credits underwrite trial usage that is intended to convert into committed consumption.

This logic has two practical consequences. First, every funding ask needs to articulate a consumption-uplift case to be approved. “We want to do a webinar” is unfunded; “we want to do a webinar targeting AWS-EDP customers in financial services, with a follow-on motion that produces marketplace transactions in Q3” is fundable. Second, funding programs change shape as the hyperscaler’s strategic priorities shift. The 2026 expansion of AWS’s MAP to include digital transformation and GenAI / agentic workloads is a representative example – the funding follows the consumption opportunity.

The CONNACT article Cloud Provider Funding 101 develops this framing at more length and is worth reading alongside this post.

Marketing Development Funds (MDF)

Marketing Development Funds (MDF) is the most widely understood and most widely misused category of partner funding. The core mechanic: the hyperscaler reimburses partner-marketing activity that drives demand for products on its platform or, at AWS, can pay in promotional credits. AWS runs a named MDF program; Microsoft’s nearest equivalent is co-op funds, and Google Cloud does not publish comprehensive terms – so the operating models differ more than the shared label suggests.

AWS MDF. AWS pays MDF as cash or AWS Promotional Credits to offset partner marketing that drives demand generation and pipeline. Its Services Path tier page lists MDF at Advanced and Premier tier only, not Select. For software partners, AWS made MDF a benefit of ISV Accelerate for partners newly enrolled after 1 January 2026, conditional on implementing Partner Revenue Measurement and meeting co-sell engagement requirements. More broadly, AWS’s PRM onboarding guide links Partner Revenue Measurement (PRM) compliance to APN funding benefits eligibility through the AWS account linked to Partner Central. Check the MDF Guide in AWS Partner Central for current MDF eligibility requirements and the relevant program guidance for other funding benefits.

Microsoft co-op funds. Microsoft’s nearest equivalent to MDF is co-op funds, and they work differently: rather than being requested, they accrue as a share of a partner’s earnings in Microsoft incentive programs, are used in the following six-month period and are claimed in Partner Center with proof of execution. Access depends on the applicable incentive program’s eligibility requirements – which can include a Solutions Partner designation – and on qualifying earnings, not on a single partner tier.

Google Cloud marketing funds. Google Cloud does not publicly document MDF terms in the way AWS and Microsoft do. Confirm current availability and eligibility in the Google Cloud Partner Network Hub or with your Google partner contact.

Eligibility is gated differently by each hyperscaler – by tier or program membership, plus program-specific conditions, at AWS and by incentive-program eligibility and earnings at Microsoft. Funding access compounds with the partner-program investments covered in Cloud Partner Programs and Specialisations – higher tiers generally unlock broader access to funding benefits than entry tiers.

Migration and Modernisation Funding

The largest category of partner funding by dollar volume is migration and modernisation. The hyperscaler funds the cost of moving a customer workload onto their platform, with the partner typically executing the migration and the customer receiving credits or fee reductions.

AWS Migration Acceleration Program (MAP). AWS’s flagship migration funding program. Mechanics: a three-phased framework – Assess, Mobilise and Migrate & Modernise – provides funding at each stage, with cash or AWS Promotional Credits available to originate opportunities, accelerate customer migrations and modernisations and grow partner migration practices on AWS. At the time of this post’s last review, MAP has expanded beyond traditional infrastructure migration to include digital transformation projects including GenAI and agentic workloads. MAP supports customer migrations through incentives that include customer AWS credits and partner funding; the recipient and form of funding in a given arrangement depend on the applicable terms.

AWS ISV Workload Migration Program (WMP). Distinct from MAP. WMP supports customers moving from a non-AWS-hosted workload onto the ISV’s own fully managed SaaS solution on AWS, gated on a completed FTR for the nominated workload. The ISV is typically the program execution lead; for eligible SaaS deployments through AWS Marketplace, the customer is the direct recipient of the disbursed credit. At the time of this post’s last review, WMP offers direct credit disbursement to end customers through AWS Marketplace, scoped to eligible SaaS deployments.

Azure Migrate and Modernize. Microsoft’s migration track covering server migration, data-platform migration, application modernisation and adjacent SAP-on-Azure motions. At the time of this post’s last review, Azure Migrate and Modernize operates as a component of the broader Azure Accelerate unified offer, which also includes Azure Innovate and the Cloud Accelerate Factory. Tier-gated; Solutions Partner designations remain the primary eligibility gate.

Azure Innovate. Announced at Microsoft Inspire in July 2023, focused on app innovation, AI and Copilot adoption. Introduced alongside a tripling of Azure Migrate and Modernize investment and a dedicated $100 million incremental fund. Since Microsoft introduced Azure Accelerate on 7 July 2025, both programs have been unified under that offer rather than operating as separate programs; funded volumes across the combined offer have grown faster than traditional migration tracks.

Google Cloud migration funding. Google runs a portfolio of migration-funding mechanisms broadly equivalent to MAP and Azure Migrate and Modernize. Coverage is narrower and the eligibility surface less well-documented; engagement typically happens through direct PDM negotiation rather than a published-tariff process.

The common pattern across all three: funding flows in stages tied to project milestones (assessment, mobilisation, migration, post-migration), with the partner executing and the customer benefiting financially. The partner’s gain is consumption-uplift on the resulting workload and a stronger relationship with the hyperscaler’s field organisation.

POC and Pilot Credits

Hyperscaler POC and pilot credits are among the most requested funding mechanisms in the co-sell motion – and among the most misunderstood, particularly for customer-deployed ISVs.

The credit transfer problem. Partner-side POC credits – whether Microsoft’s Azure Credit Offer (ACO), AWS’s partner funding portal credits or their Google Cloud equivalents – accrue to the ISV’s account. For an ISV-hosted SaaS product, this is straightforward: the ISV runs the POC in its own tenant, and the credits offset the ISV’s own infrastructure costs. For a customer-deployed product, the problem is structural. The POC runs in the customer’s cloud environment, on the customer’s bill, and the ISV’s credits cannot be transferred to the customer’s subscription or billing account. The ISV’s available credit balance is irrelevant to the customer’s POC cost.

This is a consistently underestimated operational problem. The ISV’s sales organisation, aware that partner credits exist, will often ask the alliance team to apply credits to a customer POC. The alliance team cannot – not because the credits aren’t available, but because the mechanism doesn’t work that way for customer-deployed products.

The two workarounds and their limitations. Faced with this constraint, ISVs typically land on one of two approaches:

Run the POC in the ISV’s tenant. The ISV bears the infrastructure cost using its own credits. The customer tests against a non-production, ISV-controlled environment, typically using synthetic or anonymised data. The compliance implications of running customer workloads in a third-party environment are real and must be addressed contractually. More damagingly, the customer often doesn’t fully trust the result: there is a reasonable suspicion – usually unstated – that the ISV has optimised the environment in ways that won’t be reproducible in the customer’s own infrastructure. A POC that wins on the ISV’s turf but then underperforms in production is worse than no POC at all.

Discount the final purchase by the anticipated POC cost. The ISV agrees to reduce the first-year contract value by the customer’s estimated infrastructure spend during the POC period. This is a legitimate commercial approach but requires commercial conversations to be at least partially advanced before the POC begins, adds deal structure complexity and leaves the cost burden on the ISV rather than the hyperscaler.

The customer-side credit route and why it requires care. Each hyperscaler does have a mechanism for directing credits to the customer’s account rather than the partner’s – typically gated by the customer’s cloud AE. Microsoft’s account teams can request customer-side Azure credits; Google Cloud has equivalent mechanisms. But all of these require the hyperscaler AE’s active involvement and approval.

This is where the relationship risk is significant and frequently underestimated. An ISV that approaches a hyperscaler AE cold – with no prior relationship and no established co-sell engagement – and asks for customer-side POC credits is effectively asking the AE to give away margin on their own customer’s account on behalf of a partner the AE has never worked with. The AE’s reaction is predictably negative. An ISV that tells the customer “just ask your cloud AE for free credits” fares even worse: it creates an awkward, unsolicited conversation between the customer and their AE that the AE did not ask for and did not originate. Either approach damages the AE relationship in a way that is difficult to repair and will affect the ISV’s co-sell motion well beyond the single deal.

The customer-side credit route is available, but it requires the AE relationship to have been established and the co-sell engagement to be active before the POC begins. It is a joint conversation between the ISV, the AE and the customer – not a unilateral request.

ECIF and Its Equivalents: A Frequent Misunderstanding

Microsoft’s End Customer Investment Funds (ECIF) is one of the most frequently misunderstood funding programs in the ISV co-sell context. ISV sales teams – and sometimes Microsoft field employees – will suggest that an ISV pursue ECIF to fund a customer POC or deployment engagement. For most ISVs, this is not possible and the suggestion is a distraction.

ECIF is a program under which Microsoft pays approved partners to deliver services that accelerate customer adoption of Microsoft cloud technologies. The key word is services. ECIF is for partners who deliver implementation, migration, deployment or professional services work – system integrators, managed service providers, consulting firms. It is understood that eligibility requires a relevant Advanced Specialisation and ECIF supplier registration – requirements an ISV that sells software but has no services arm will not typically have met – and that the program is not available to pure-play software vendors, although Microsoft seems unwilling to state this in any documentation, which inevitably results in confusion about eligibility.

The recommended workaround – identifying an ECIF-accredited services partner and engaging them to deliver the funded work – is theoretically sound but difficult in practice. Introducing a new services partner into an active sales cycle creates a significant coordination overhead. The services partner has their own commercial interests, their own view of the engagement scope and their own incentive to turn a short POC engagement into a longer services relationship. Managing that dynamic while simultaneously trying to close a new logo is rarely a comfortable experience. Partners report that the workaround is seldom successful. If the services-partner route is ever going to work, the partner needs to be identified, qualified and relationship-built before a deal needs them – introduced cold into a live pursuit, the coordination overhead the workaround requires is exactly what kills it.

AWS and Google Cloud equivalents. AWS has the Migration Acceleration Program (MAP) and the Partner Opportunity Acceleration (POA) program for POC and migration funding, but these are similarly oriented toward services-delivery partners. This funding agreement is between AWS and the ISV, not automatically between AWS and the end customer – if an ISV receives migration support, that benefit may indirectly influence customer onboarding costs, but it does not automatically reduce a customer’s AWS bill unless explicitly structured that way. The structural constraint is the same as ECIF. Google Cloud’s Deal Acceleration Funds (DAF) exist for sales-cycle acceleration but are not a direct ECIF equivalent in terms of services-delivery funding for partners.

The practical implication for ISV alliance teams. When the sales team asks “can we get ECIF for this customer?” the honest answer for a pure-play software ISV is almost always no. The alliance team should be prepared to explain clearly why – not as a failure to access funding, but as an accurate description of what the program is and is not – and to discuss what alternatives genuinely exist (customer-side Azure credits via an engaged hyperscaler AE, commercial POC cost accommodation or the customer-funded infrastructure model described above). Allowing the misconception to persist wastes time and creates false expectations with both the ISV sales team and the customer.

The better approach is to address the misconception before it arises. Sales team enablement on funding program scope – what ECIF is, what ACO is, what POC credits can and cannot do for a customer-deployed product – should be part of onboarding for every new ISV AE and a standing topic in the alliance team’s internal communications. An ISV AE who has been told upfront that ECIF is unavailable to a pure-play software ISV will not be disappointed when the answer is no; an ISV AE who discovers this mid-pursuit, after raising the topic with the customer, will be. The latter scenario reliably produces the “department of no” dynamic: the ISV AE concludes that the alliance team lacks relationships, lacks influence or is simply obstructing a deal rather than helping close one. That conclusion is wrong, but it is understandable given the information the ISV AE had at the time. The alliance team that prevents this by educating first never has to defend itself against it.

The POC urgency dynamic. There is a broader sales-cycle implication to the credit transfer problem that affects customer-deployed products structurally. When the customer pays for their own POC infrastructure, they have skin in the game: the meter is running, and there is a natural incentive to drive the POC to a conclusion efficiently. When the ISV funds the POC infrastructure (either by running it in the ISV’s tenant or by absorbing the cost through a commercial hack), the POC is effectively free to the customer. Free POCs are frequently deprioritised: the customer has no cost pressure, competing priorities easily displace them and they can extend indefinitely without commercial consequence. The customer-paid infrastructure model, uncomfortable as it is for the ISV, produces better POC discipline and faster sales cycles.

AWS Marketplace Private Offer Promotion Program (MPOPP)

MPOPP launched in August 2025 as AWS’s incentive program tied to partner-led Marketplace private-offer transactions. The core mechanic: the ISV submits a self-service funding request through the AWS Partner Funding Portal; following Private Offer acceptance and Marketplace transaction verification, AWS Promotional Credits are issued to the customer’s AWS account based on Total Contract Value (TCV) and applicable program rates. At the time of this post’s last review, the program includes end-to-end automation and next-day credit delivery. Benefits are differentiated between new Marketplace sellers (immediate funding support) and established sellers (renewal incentives). Partner-tier and co-sell-program eligibility requirements apply.

MPOPP incentive terms should be checked against current AWS documentation for any deal modelling – specific program rates and eligibility requirements may shift. Detail on the operational mechanics of marketplace private offers is in Private Offers.

Marketplace Rewards and Azure Sponsorship

Microsoft’s marketplace-transaction incentives operate through two distinct channels. Marketplace Rewards provides partners with funding tied to marketplace transactions and the consumption those transactions drive – typically structured as Azure credits the partner can deploy against customer workloads or as cash-equivalent rewards reimbursed against marketing activity.

Azure sponsorship is a separate vehicle: Microsoft provides sponsored Azure consumption to partners or customers for strategic-pursuit purposes (training environments, ISV-internal development, joint customer evidence). Sponsorship is more discretionary and typically negotiated through the PDM rather than applied for through a published program. Marketplace Rewards requires only a Partner ID and a published offer – it is available to all partners regardless of MAICPP tier, Solutions Partner designation or Azure IP Co-Sell Eligible status. Higher benefit tiers unlock through Marketplace Billed Sales performance. Azure IP Co-Sell Eligible status gates access to IP co-sell top-tier benefits, which are a separate program, not Marketplace Rewards itself. Detail on the underlying marketplace mechanics is in Microsoft Co-Sell.

Google MCCP and Marketplace Incentives

Google’s marketplace incentive structure runs primarily through two mechanisms. The Marketplace Customer Credit Program (MCCP) – generally available as of May 2025 – provides customers with up to 3% in Google Cloud first-party service credits when they purchase an eligible ISV solution through Google Cloud Marketplace for the first time; the credit is customer-facing, not partner-facing, and is designed to incentivise net-new workload adoption. Separately, Google Cloud operates a tiered revenue-share model, allowing eligible partners to retain more revenue on larger new-deal private offers and qualifying native renewals, channel shifts and migrations.

MCCP reached general availability in May 2025 and the variable revenue-share schedule was also introduced at that point – both predating the Q1 2026 Google Cloud Partner Network rollout. The Q1 2026 program reset restructured partner tiers (adding a new Diamond tier) and replaced specialisations with a competency framework, but did not specifically reset MCCP incentive percentages. Pre-2026 documentation on Google marketplace incentives remains relevant for MCCP mechanics; partners should verify current program-tier eligibility requirements against the Google Cloud Partner Network. Detail in Google Co-Sell.

How to Get Funded

The published documentation describes what programs exist. The unwritten rules describe how to access them:

Build PDM support before the ask. In the author’s experience at Microsoft, discretionary funding requests rarely went ahead without the PDM’s sponsorship. Microsoft’s co-op funds are the exception: they are earned through incentive programs and claimed against proof of execution, not requested. Build the relationship first; the funding form comes second.

The ask has to map to a current hyperscaler priority. Every hyperscaler runs an annual or semi-annual strategic priority cycle: which industries they’re prioritising, which workloads they’re prioritising, which customer segments they’re targeting. Funding flows toward asks that align; asks that don’t align get deprioritised regardless of merit. The first conversation with a PDM about funding should establish what their current priorities are.

“Thank you for the budget” is not a measurable outcome. Funding cycles renew based on demonstrated outcomes. A partner who consumes MDF, runs a campaign and reports “we ran a successful campaign, thank you” without consumption-uplift evidence gets no additional funding consideration next cycle – or, more often, gets de-prioritised. Reporting back with attributable pipeline and consumption outcomes is what compounds funding access over time.

Apply for everything you’re eligible for. The single biggest cause of unspent partner funding is partners not knowing what they’re eligible for or not having the operational capacity to apply. A junior partner-ops resource directly tasked with tracking eligible funding programs and getting applications in typically pays back several times over.

Treat funding cycle timing as a hard deadline. Hyperscaler fiscal years matter. AWS and Google Cloud both run on calendar-year fiscal cycles (January to December); Microsoft runs July to June. Funding deadlines don’t always align with those boundaries, so check each program’s usage, claim and expiry deadlines: Microsoft’s co-op funds, for example, run on six-month earning and usage periods, and unused earnings are forfeited.

Hyperscaler field availability follows the fiscal year. This has implications beyond funding that are worth understanding explicitly. Cloud AEs operate under intense end-of-quarter and especially end-of-fiscal-year pressure. Attempting to engage an enterprise Microsoft AE in late May or June – the final weeks of Microsoft’s fiscal year – is unlikely to produce results unless the ISV is bringing a demonstrably near-term, material close that moves the needle before fiscal year end. The same pattern applies in November and December for AWS and Google Cloud AEs. These are not windows for relationship-building or pipeline development; they are windows for closing what is already in flight.

The inverse is also true, but with an important qualification. The early weeks of a new fiscal year are not uniformly receptive. At Microsoft in particular, July tends to be a popular vacation month – sellers who have just survived a high-pressure year-end run often take time off immediately afterwards. Compounding this, hyperscalers periodically reassign accounts between AEs at fiscal year boundaries, and in the first weeks of a new year it is not uncommon to find that the AE you have been building a relationship with is no longer on the account, or is uncertain whether they will be. Starting a new joint account plan conversation with an AE who may not own the account in a month’s time is unproductive for both parties.

The more reliable receptive window is Q1 once the dust has settled – typically six to eight weeks into the new fiscal year, when sellers are back, account assignments are confirmed and quota is set but pipeline pressure has not yet built. This window is genuinely productive: AEs have fresh quota and an incentive to build early-quarter pipeline with well-qualified co-sell opportunities. New joint account plans, introductory meetings and Specialisation discussions all land better here than at any other point in the year. Q3 (the mid-point of the fiscal year) is a secondary window for the same reasons – quota pressure has eased relative to Q4 and sellers are open to building H2 pipeline.

The PDM-side seasonality is different. A PDM under end-of-quarter pressure to show pipeline and marketplace metrics can be more motivated to push ISV opportunities forward – but only for ISVs who have built a track record of delivering quality submissions. A PDM managing 30 or 60 partner accounts will prioritise the ones with the strongest historical delivery at exactly the moments when their own metrics are under scrutiny. Poor-quality or template submissions at end of quarter are not just ignored – they can actively damage the PDM relationship at the moment when goodwill matters most.

Compliance and Tax Considerations

Funding arrangements include MDF (marketing reimbursement, paid against approved marketing activity, evidenced by proof of performance) and marketplace incentives and benefits – a descriptive grouping, not a single vendor category. MPOPP and MCCP issue cloud credits to the customer following a closed-won or accepted private offer; Marketplace Rewards is a partner-side benefit that unlocks progressively as marketplace sales accumulate, not a payment triggered by a single transaction. These mechanics differ enough in recipient and trigger that they shouldn’t be treated as interchangeable examples of one thing.

MDF received against documented marketing expenses is generally treated as a reduction in marketing cost rather than as revenue.

The principal-vs-agent question matters here too: in marketplace-routed transactions with associated incentive payments, the partner’s revenue-recognition determination affects how the incentive flows through the books. Finance should be consulted on the structure of any new funding program before the first dollar flows. The detailed marketplace revenue-recognition mechanics are in Cloud Marketplace Operations.

VAT, withholding taxes and FX considerations also vary by jurisdiction. The finance plumbing is often an under-appreciated component of multi-cloud funding strategy.

What This Looks Like in Practice

A composite example, built from recurring patterns rather than a single case.

A data-platform ISV with $50M ARR built a deliberate funding strategy over 18 months. The starting state: $0 in attributable hyperscaler funding, despite three years of AWS Premier tier status and a Microsoft Solutions Partner designation in Data & AI.

Month 1–3: hired a junior partner-ops resource with explicit mandate to track and apply for every funding program the company was eligible for. First cycle of MDF applications submitted to AWS and Microsoft. PDM relationships re-established with explicit funding conversations at the first rhythm call.

Month 4–6: first MDF disbursement closed (~$80k from AWS for a joint financial-services-vertical campaign). MAP discussions opened with two enterprise prospects through the AWS PDM. First POC credits arrived for a strategic Microsoft prospect.

Month 7–12: $400k in total funding consumed across MDF, MAP-funded migration projects and POC credits. Half from AWS, the remainder split between Microsoft and Google Cloud (Google Cloud Partner Network enrolment had completed mid-year). The funding produced an attributable $2.3M of new pipeline and $850k of marketplace transactions.

Month 13–18: the funding-cycle compound effect arrived. The reporting-back discipline established in months 7–12 produced visibly stronger PDM relationships and noticeably more pre-emptive funding offers. Second-year MDF allocations were roughly 60% higher than first-year. None of this involved exotic programs – the trajectory came from operational discipline: knowing what was available, applying for it on time, reporting back on outcomes and treating PDM relationships as central to funding.

Non-Financial Program Benefits and Who Owns Them

Partner program tiers unlock more than financial funding. Most programs at Specialisation level and above include a tier of marketing and go-to-market benefits that are distinct by design from MDF and that require a different owner inside the ISV to realise.

Typical marketing benefit entitlements at mid-to-upper program tiers include: a co-brandable press release or announcement with a named hyperscaler executive quote; one or two jointly-published pieces of collateral (a solution brief, a reference architecture document, a case study); a co-hosted webinar slot with the hyperscaler’s partner marketing team; featured placement in the hyperscaler’s partner directory or solution catalogue; a marketplace badge or “preferred” designation surfaced in the marketplace listing; eligibility for hyperscaler-sponsored conference presence (a speaking slot, a booth allocation, a sponsored session).

These benefits are not trivial. A hyperscaler executive quote in a press release is a credibility signal that a small infrastructure ISV could not otherwise obtain. A featured placement in the marketplace solution catalogue can significantly change organic discovery for an ISV whose primary go-to-market is marketplace. A co-hosted webinar with the hyperscaler’s audience reach is a demand-generation event that would cost significantly more to produce independently.

They are also almost universally underused. The structural reason: alliance teams are sales-funnel oriented. Their attention is on ACE submissions, AE engagement, co-sell pipeline and program tier progression. The marketing benefit entitlements sit inside the partner portal as a list of options that nobody in the alliance team has the brief or the skills to activate. The result is that the entitlements expire – most have a use-by window tied to the program year – while the ISV’s marketing team, which would know exactly what to do with a hyperscaler executive quote or a co-branded webinar slot, has no visibility into the entitlements at all.

The fix is structural, not individual. The alliance team’s job is to surface the available entitlements and create a formal handoff to marketing at the start of each program year. This requires a named interface between alliance and marketing – either the Alliance Marketing Lead role, where it exists, or a named marketing owner who has been briefed on what the program provides, how to access it and what the deadlines are. Without that handoff, the benefits will not be claimed.

Two practical observations:

Quality matters more than volume. A single well-executed co-branded asset tied to a named joint customer and a real use case is worth more than four generic “ISV + Hyperscaler: better together” brochures that no AE ever uses. The marketing team needs to know that the brief is to produce something field sellers will use in customer conversations, not to produce something that satisfies the program deliverable.

The hyperscaler partner marketing manager is a resource. Every major hyperscaler has a partner marketing organisation alongside the PDM structure. These teams have templates, content guides, design resources and in some cases co-production support for partners who are entitled to joint marketing benefits. They are systematically underutilised by ISV alliance teams who don’t know they exist or don’t think to engage them. The alliance team’s counterpart mapping (see Cloud Alliance Team) should include the partner marketing manager alongside the PDM, the technical team and the field counterparts.

Common Pitfalls

Leaving funding on the table. The single most common pattern. Partners qualified for $200k of annual funding receive only $50k because nobody is tracking eligibility or applying on time. A junior partner-ops resource often pays back in the first 90 days.
Spending MDF without tracking attributable pipeline. MDF without consumption-uplift evidence renews at the same level or lower. Build attribution discipline into the campaign before the budget arrives.
Treating credits as a discount mechanism. POC credits and migration funding are pipeline levers, not negotiation tools. Using them to close price-pressured deals burns the funding without producing the consumption case that earned it.
Submitting funding asks without PDM advocacy. Asks with no PDM relationship behind them are easy to defer. Build the relationship first.
Missing fiscal-year deadlines. Unused funding usually doesn’t roll over. Calendar the deadlines and the application lead times directly.
Ignoring the compliance and tax structure. MDF and marketplace incentives don’t necessarily share an accounting treatment. Get finance involved before the first dollar flows, not afterwards.
Charging hyperscaler conference costs to the alliance budget. Conference attendance – sponsorship fees, booth costs, staff travel – belongs in the marketing events budget, not the alliance budget. The two lines serve different purposes: alliance funding is for relationship investment, program activity and technical validation work; events funding is for brand presence and demand generation at scale. Coupling them forces the alliance leader into trade-offs that should never sit in the same decision. See Cloud Alliance Team for the conference management model.

Using a generalist marketer to adapt collateral across hyperscalers. Each hyperscaler has its own vocabulary, and precision with that vocabulary matters: MACC and EDP are not interchangeable; customer tenant and customer account are not interchangeable; Partner Center and Partner Central are not interchangeable. A content creator without hyperscaler domain knowledge, asked to produce an AWS version of a Microsoft asset, will do exactly what they’ve been asked – swap the logo – while leaving Microsoft-specific terms intact throughout. The resulting asset is not just wrong; it signals to any hyperscaler-field reader that the ISV’s marketing team doesn’t understand the platform they are claiming to specialise in. Hyperscaler-facing collateral must be reviewed by someone with domain knowledge of the specific hyperscaler before it is used. This is a second argument for the Alliance Marketing Lead having genuine hyperscaler fluency rather than being a generalist hire; see Cloud Alliance Team.

Where to Go Next

Within this pillar:

Cloud Partner Programs and Specialisations – the formal program tiers that gate most funding eligibility.
Cloud Alliance Team – where the partner-ops resource that tracks funding fits in the team.
Cloud Alliances – the broader pillar this post sits under.

Per-cloud co-sell mechanics (where funding-program engagement happens in practice):

AWS Co-Sell – AWS PDM engagement, MAP and WMP mechanics.
Microsoft Co-Sell – Microsoft PDM engagement, Azure Migrate and Modernize, Azure Innovate.
Google Co-Sell – Google PDM engagement and the post-2026 Partner Network funding structure.

Adjacent: Hyperscaler Co-Sell – the broader co-sell motion that funding programs sit alongside.

The full series glossary is at Glossary.

External References

Vendor Primary Sources

AWS Partner Network – MAP, WMP, MPOPP and partner-funding program documentation.
Microsoft Partner Center documentation – co-op funds, Azure Migrate and Modernize, Azure Innovate, Marketplace Rewards.
Google Cloud Partner Network – the Q1 2026 funding-program structure including MCCP.

Practitioner Models and Industry Commentary

These sources are influential within the cloud-GTM practitioner community but published from a commercial or advisory vantage point. Cited with attribution.

CONNACT – Cloud Provider Funding 101. The model that underpins the funding-category structure used in this post and the consumption-driven funding logic developed in the “Why hyperscalers fund partners” section. Note: the author has a professional relationship with CONNACT; see the series disclosure on the hub page.

Sources

The following primary sources were used to verify factual claims in this post. Inline hyperlinks on high-stakes claims (fee rates, program names, eligibility thresholds and specific numeric values) link directly to the relevant source.

AWS

AWS Migration Acceleration Program – MAP phase framework (Verified June 2026)
AWS Services Partner Tiers – MDF availability by Services Path tier (Verified October 2026)
Funding Benefits for AWS Partners – MAP, WMP and POA program descriptions; MDF purpose and payment as cash or AWS Promotional Credits (Verified June 2026; MDF October 2026)
AWS ISV Workload Migration Program – WMP mechanics (Verified June 2026)
Announcing New Incentives for ISVs Selling in AWS Marketplace – MPOPP launch and mechanic (Verified June 2026)
Powering Next-Level Partner Success: Innovations for Growth and Scale in 2026 – MAP GenAI expansion and MPOPP enhancements (Verified June 2026)
New AWS ISV Accelerate Benefits – ISV Accelerate MDF eligibility for partners newly enrolled after 1 January 2026 (Verified October 2026)
AWS Partner Revenue Measurement onboarding guide – Prerequisites – linked-account PRM compliance and APN funding benefits eligibility (Verified September 2026)

Microsoft

ISV Success and Marketplace Rewards – Marketplace Rewards gate requirements (Verified June 2026)
Azure Accelerate – Azure Migrate and Modernize unified under Azure Accelerate (Verified June 2026)
Azure updates for partners: October 2025 – Azure Accelerate unification and Azure Innovate context (Verified June 2026)
Incentives Co-op and Claims Overview – co-op funds accrued from incentive earnings, six-month periods and proof of execution (Verified October 2026)

Google Cloud

Upgrades to Google Cloud Marketplace for Partners – MCCP GA (May 2025) (Verified June 2026)
Google Cloud – Marketplace revenue-share schedule – tiered revenue-share rates for standard offers, new-deal private offers and qualifying native renewals, channel shifts and migrations (Verified 7 September 2026)
Introducing Google Cloud Partner Network – Q1 2026 program tier restructure (Verified June 2026)

Last reviewed: 2026-09-28. Vendor-neutral clusters in this series are reviewed annually. Major program-related changes between reviews are flagged in the Updates section below.

Updates

Updated 9 October 2026: Corrected the Marketing Development Funds coverage. AWS documents MDF at Advanced and Premier tier on the Services Path and, for software partners, for those newly enrolled in ISV Accelerate after 1 January 2026; the earlier description of AWS MDF as accrual-based at higher tiers, an unsupported claim of higher allocations for ISV Accelerate partners and an unsourced description of AWS’s approval process were removed. Microsoft’s co-op funds are now described as they work – accrued from incentive-program earnings and claimed with proof of execution – rather than as tier-gated MDF, and the unsourced Google Cloud MDF description was replaced with a note that Google does not publish equivalent terms. The point that funding requests need PDM sponsorship is now presented as the author’s experience at Microsoft. Following review, related statements were also qualified, including the eligibility comparison, funding-deadline guidance, the effect of tier on funding and the description of POC credits. Factual corrections were checked against the cited sources and independently reviewed.

Updated 28 September 2026: Corrected the MAP and WMP descriptions to match AWS’s program terms: who receives MAP funding, and in what form, depends on the applicable terms; WMP supports customers moving to the ISV’s own fully managed SaaS on AWS, requires a completed Foundational Technical Review and pays credits directly only for eligible SaaS deployments through AWS Marketplace. Added the documented link between Partner Revenue Measurement compliance and eligibility for APN funding benefits. Removed “POP” (proof of performance) as a separate funding category – it is evidence supporting an MDF claim – and corrected “Azure Marketplace Rewards” to Marketplace Rewards. Presented ECIF’s eligibility requirements as practitioner understanding. Corrected the Azure Accelerate introduction date (7 July 2025), Microsoft’s fiscal year (July to June) and the Google Cloud Marketplace fee description, now the actual tiered schedule. Also made several smaller clarifications. Factual corrections were checked against the cited sources and independently reviewed.

© Chris Buckel / flashdba. Part of the Hyperscaler GTM Playbook. If you quote or reproduce this content – in writing or as material for AI systems – please attribute it to Chris Buckel / flashdba.com and link to the source. Legal information and terms: flashdba.com/about/legal/.