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

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 almost always gated by program tier or specialisation. 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 champion depends on the funding type: the PDM champions 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 (accrual-based for higher tiers; activity-based at entry tiers)	Microsoft MDF / Co-op funds (tier-gated, activity-based)	Google Cloud MDF (program-tier-gated, activity-based)
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)	Azure 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	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. Every dollar a hyperscaler spends on a partner is – directly or indirectly – an investment in growing consumption on their own platform. MDF funds marketing activity that produces pipeline that closes as marketplace transactions. Migration funding offsets the cost of moving a workload onto the hyperscaler’s infrastructure. POC credits underwrite the trial usage that converts 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 (or pre-funds) partner-marketing activity that drives demand for products on its platform. All three hyperscalers run MDF programs; the operating models differ.

AWS MDF. At Advanced and Premier tier, and for ISV Accelerate partners, MDF is available on an activity-based model: the partner proposes a specific marketing activity, AWS pre-approves the budget, the partner executes, the partner submits proof of performance and AWS reimburses. Select-tier partners do not have access to MDF under current published programme terms. At Premier tier and for ISV Accelerate partners, higher MDF allocations are available, with eligibility criteria – including co-sell engagement and Partner Revenue Measurement implementation – applying to ISV Accelerate enrolees from January 2026.

Microsoft MDF / Co-op funds. Microsoft’s MDF runs through Partner Center on a tier-gated, activity-based model. Eligibility ties to Microsoft AI Cloud Partner Program (MAICPP) designation and (for some campaigns) Azure IP Co-Sell Eligible status. Co-op funds for resellers run separately through CSP channels.

Google Cloud MDF. Program-tier-gated under the Google Cloud Partner Network reset. Activity-based, with budget cycles aligned to Google’s fiscal year. Less mature than AWS’s or Microsoft’s but growing in funded volume.

Eligibility across all three is gated by program tier or specialisation. Funding access compounds with the partner-program investments covered in Cloud Partner Programs and Specialisations – a Premier-tier or Diamond partner with relevant specialisations sees significantly more funding than an entry-tier partner with the same marketing plan.

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. As of 2026, MAP has expanded beyond traditional infrastructure migration to include digital transformation projects including GenAI and agentic workloads. The customer is the recipient of MAP funding; partners participate in execution and benefit from the consumption uplift.

AWS ISV Workload Migration Program (WMP). Distinct from MAP. WMP supports customers migrating off third-party technology onto an ISV’s AWS-native solution. The ISV is the program execution lead; the customer is the financial recipient. As of 2026, WMP offers direct credit disbursement to end customers via marketplace.

Azure Migrate and Modernize. Microsoft’s migration track covering server migration, data-platform migration, application modernisation and adjacent SAP-on-Azure motions. As of October 2025, 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 October 2025, both programmes have been unified under the Azure Accelerate offer rather than operating as separate programmes; 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, mobilization, 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. AWS’s ISV Workload Migration Program can disburse credits directly to the customer’s AWS account; 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. An ISV that sells software but does not have a services arm, and therefore has not completed the Advanced Specialisation and ECIF supplier registration requirements, cannot apply for or receive ECIF funding. The programme is not available to pure-play software vendors.

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. In practitioner experience the workaround is seldom successful in practice. 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 programme 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 programme rates. As of January 2026, the programme 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-programme eligibility requirements apply.

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

Azure Marketplace Rewards and Azure Sponsorship

Microsoft’s marketplace-transaction incentives operate through two distinct channels. Azure 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 programme, 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 variable revenue-share model (3% down to as low as 1.5% for eligible deals), allowing partners to retain a larger proportion of deal value on large-volume or channel transactions.

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 programme 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 programme-tier eligibility requirements against the Google Cloud Partner Network. Detail in Google Co-Sell.

How to Actually Get Funded

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

The PDM has to champion the ask. Funding decisions almost always require PDM-side advocacy. A partner submitting a funding request through a portal with no PDM relationship behind it gets either rejected or deferred. The PDM relationship is the prerequisite, not the funding form.

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. MDF and other programs reset at fiscal-year boundaries, and unused budget typically does not roll over.

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 before Microsoft’s July 1 year-end – 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 is typically structured as either MDF (marketing reimbursement, paid against documented marketing activity) or POP (proof-of-performance credits, paid against documented business outcomes). The tax and revenue-recognition treatment differs.

MDF received against documented marketing expenses is generally treated as a reduction in marketing cost rather than as revenue. POP credits paid for closed-won business outcomes are sometimes treated as additional revenue and sometimes as a customer-acquisition-cost offset, depending on contract structure and local tax treatment.

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, drawn from patterns across multiple real situations.

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 the funding gatekeepers they actually are.

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 actually 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 actually receive $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 that arrive at the funding committee without PDM championship get rejected or deferred. 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 POP have different rev-rec treatments. 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 that vocabulary is load-bearing: 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 – MDF, 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.

Sources

The following primary sources were used to verify factual claims in this post. Inline hyperlinks on high-stakes claims (fee rates, programme 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 tier eligibility (Verified June 2026)
Funding Benefits for AWS Partners – MAP, WMP and POA programme descriptions (Verified June 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 (Verified June 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)

Google Cloud

Upgrades to Google Cloud Marketplace for Partners – MCCP GA (May 2025), variable revenue-share schedule (Verified June 2026)
Introducing Google Cloud Partner Network – Q1 2026 programme tier restructure (Verified June 2026)

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

Updates

(No updates yet. This section will record dated corrections, program changes between reviews and community-contributed clarifications as they arrive.)

© 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. Full disclosure and terms: flashdba.com/about/legal/.