--- title: "AWS Partner Funding: POC, MDF, ISV Workload, PIF" url: https://www.suger.io/resources/blog/aws-partner-funding-programs/ canonical: https://www.suger.io/resources/blog/aws-partner-funding-programs/ type: Blog description: "AWS partner funding programs explained for ISVs: POC funding, MDF, the ISV Workload Migration Program, and innovation funding — and when to use each." --- # AWS Partner Funding: POC, MDF, ISV Workload, PIF > Canonical HTML version: https://www.suger.io/resources/blog/aws-partner-funding-programs/ 1. [Home](/) 2. / 3. [Resources](/resources/) 4. / 5. [Blog](/resources/blog/) 6. / 7. AWS Partner Funding: POC, MDF, ISV Workload, PIF # AWS Partner Funding: POC, MDF, ISV Workload, PIF Four AWS partner funding programs, four different jobs. Here's which one fits which deal stage — and why the funding request usually fails on the opportunity, not the form. [![Sabrina Xie](/authors/sabrina-xie.jpg)](/resources/blog/author/sabrina-xie/) [Sabrina Xie](/resources/blog/author/sabrina-xie/) Aug 6, 2026 ![AWS Partner Funding: POC, MDF, ISV Workload, PIF](/images/blog/aws-partner-funding-programs/hero.png) Explore AI Summary [![](/logos/company/openai.svg)](https://chat.openai.com/?q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Faws-partner-funding-programs%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20AWS%2C%20Co-Sell. "Summarize with ChatGPT")[![](/logos/company/anthropic.svg) ](https://claude.ai/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Faws-partner-funding-programs%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20AWS%2C%20Co-Sell. "Summarize with Claude")[![](/logos/company/gemini.svg)](https://www.google.com/search?udm=50&aep=11&q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Faws-partner-funding-programs%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20AWS%2C%20Co-Sell. "Summarize with Gemini")[](https://www.perplexity.ai/search/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Faws-partner-funding-programs%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20AWS%2C%20Co-Sell. "Summarize with Perplexity") Table of Contents - [What is AWS partner funding?](#what-is-aws-partner-funding) - [The four programs, and what each one is for](#the-four-programs-and-what-each-one-is-for) - [Which program fits which deal stage](#which-program-fits-which-deal-stage) - [The prerequisite that decides most funding requests](#the-prerequisite-that-decides-most-funding-requests) - [Why funding programs go unused](#why-funding-programs-go-unused) - [Frequently asked questions](#frequently-asked-questions) - [Takeaways](#takeaways) _AWS partner funding programs are AWS-funded incentives that offset the cost of proving, marketing, or migrating a customer workload. Each one is tied to a different stage of a deal, and requesting the wrong one is the most common reason a funding request goes nowhere._ * * * Every partner manager eventually has the same conversation. A deal needs something AWS could pay for — a proof of concept, a migration, a joint campaign — and somebody asks which fund it comes out of. The answers arrive as acronyms, from four different people, and none of them agree. The programs are not actually confusing. They map cleanly onto deal stages: one funds proving it works, one funds telling people about it, one funds moving the workload, one funds the strategic bet. The confusion comes from asking for money at a stage the program was not built for. Here’s the decision framework, and the prerequisite that decides more funding outcomes than the framework does. * * * ## **What is AWS partner funding?** AWS partner funding is a set of programs through which AWS contributes to the cost of partner-led customer activity — proofs of concept, marketing campaigns, workload migrations, and strategic co-investments. Funding is requested through AWS Partner Central, and approval depends on your partner tier, your program designations, and the state of the specific customer opportunity behind the request. One structural point governs everything below: **amounts, caps, eligibility criteria and even program names change from one AWS program year to the next.** Treat any figure you read anywhere — including in a partner’s blog post — as a snapshot, and confirm the current terms in AWS Partner Central before you commit a number to a customer or an internal forecast. * * * ## **The four programs, and what each one is for** **POC funding** offsets the cost of a proof of concept — the phase where a customer is willing to try your product on AWS but has not committed to it. It exists to remove the cost objection from an evaluation, which means it belongs _before_ a commitment, not after. **MDF (Market Development Funds)** funds demand-generation activity: joint campaigns, events, content, field marketing. Eligibility is normally attached to partner designations and tiers, and spend is typically pre-approved and reimbursed against evidence. MDF is a pipeline instrument, not a deal instrument — asking for it to rescue a specific late-stage negotiation is asking the wrong fund. **The ISV Workload Migration Program** supports moving an existing customer workload onto your SaaS offering running on AWS. It is aimed at software partners with validated offerings, and it is the program most ISVs under-use, because the migration cost sits with the customer and nobody thinks to ask who else might pay for it. **Partner innovation and co-investment funding** covers the strategic end — multi-year, jointly agreed investments in a specific motion such as migration, generative AI, or security. These are negotiated relationships rather than transactional requests, and they start with your AWS partner development manager, not a form. * * * ## **Which program fits which deal stage** Deal stage What the customer is doing Program that fits What it does not do No opportunity yet Doesn’t know you exist **MDF** Won’t fund delivery work on a named deal Early evaluation Willing to test, not to commit **POC funding** Won’t cover full production rollout Committed, migration blocked Wants to buy, has an existing workload to move **ISV Workload Migration Program** Won’t fund a greenfield deployment with nothing to migrate Strategic, multi-deal A repeatable motion you and AWS both want to scale **Innovation / co-investment funding** Isn’t a per-deal request; it’s a negotiated plan Read the table left to right and the pattern is obvious: **the fund follows the customer’s state, not your need.** A team that requests POC funding for a customer who has already signed, or MDF for a single account already in late stage, is not being denied for paperwork reasons. * * * ## **The prerequisite that decides most funding requests** Funding requests sit on top of a registered opportunity, and the quality of that opportunity record is what most approvals actually turn on. That means the real prerequisite is your co-sell hygiene. If the opportunity is not in **APN Customer Engagements (ACE)**, or it is there with a stale stage, a missing value, or no AWS-side owner, then the funding request is asking AWS to co-invest in something AWS cannot see. [AWS ACE: a practical co-sell guide for ISVs](/resources/blog/aws-ace-guide-for-isv-sellers/) covers how opportunity sharing actually works, and [who at AWS gets assigned to your deal](/resources/blog/aws-decides-whether-you-get-a-rep/) covers why the AWS-side owner matters more than the form does. The order that works: 1. **Register the opportunity in ACE first**, with a real value, a real close date, and a real AWS contact. 2. **Match the program to the customer’s stage** using the table above. 3. **Talk to your partner development manager before submitting** anything strategic. Innovation funding in particular is a conversation, not a submission. 4. **Submit through AWS Partner Central**, with the evidence the specific program asks for. 5. **Track the request against the deal**, not in a separate spreadsheet — because the reason you asked will be relitigated at close. Teams that do step 1 well rarely have a funding problem. Teams that skip it have a permanent one. * * * ## **Why funding programs go unused** The most common failure is not rejection. It is that nobody asks. Funding lives with the partner team; the deals that qualify live with sales. If the rep working a migration-shaped opportunity does not know the ISV Workload Migration Program exists, the deal closes without it — or worse, it stalls on a cost the customer would not have had to bear. The fix is unglamorous: make funding eligibility a field on the opportunity, reviewed at the same cadence as the pipeline. If your co-sell records and your CRM opportunities are the same records, that review costs nothing. If they are two systems reconciled by hand, it will not happen at all, which is the case for [most ISVs running co-sell out of a spreadsheet](/resources/guides/co-sell/). Suger keeps co-sell opportunities synced between your CRM and AWS, Microsoft, and Google Cloud, so the opportunity a funding request depends on is the same record your rep is already updating. [Co-sell automation](/platform/cosell/) covers how that sync works in practice. * * * ## **Frequently asked questions** **What is AWS partner funding?** AWS partner funding is a set of AWS programs that offset partner-led customer costs — proofs of concept, marketing activity, workload migrations, and strategic co-investments. Requests are submitted through AWS Partner Central against a registered opportunity. **What’s the difference between MDF and POC funding?** MDF funds demand generation before an opportunity exists — campaigns, events, content. POC funding offsets the cost of proving your product for a specific customer that is evaluating but has not committed. **Do I need ACE to request AWS funding?** In practice, yes. Funding requests sit on a registered opportunity, so an opportunity that isn’t shared in APN Customer Engagements — or is there with stale data — gives AWS nothing to co-invest against. **How much AWS partner funding can an ISV get?** Amounts, caps, and eligibility change by AWS program year and depend on your tier and designations. Confirm current figures in AWS Partner Central rather than relying on any published number. **Which program covers migrating a customer onto our SaaS?** The ISV Workload Migration Program is designed for moving existing customer workloads onto a software partner’s offering running on AWS. It is the most under-used program among ISVs. **Who should own funding requests internally?** The partner or alliances team owns the request, but eligibility has to be visible to sales on the opportunity itself. Funding that only the partner team can see is funding that goes unclaimed. * * * ## **Takeaways** - Match the program to the customer’s stage: MDF before an opportunity, POC funding during evaluation, workload migration funding at commitment, co-investment for a repeatable motion. - Confirm amounts and eligibility in AWS Partner Central every program year. Published figures age badly. - Fix ACE hygiene first. Most funding requests fail on the opportunity record, not the request. - Start strategic co-investment conversations with your partner development manager, not a submission form. - Make funding eligibility visible on the opportunity so sales can flag it — otherwise the programs stay unused. * * * Funding follows the opportunity, so the opportunity has to be current. See how [co-sell automation in Suger](/platform/cosell/) keeps AWS, Microsoft, and Google Cloud opportunities in sync with the CRM your reps already use. ### Stay Updated Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.