Cloud Partner Programs and Specialisations Compared: AWS, Microsoft and Google Cloud

Before an ISV can co-sell with a hyperscaler or list on their marketplace, they need to be in the right program at the right level. Each hyperscaler runs its own formal partner program – with its own tier model, its own ISV-specific track and its own technical validation requirements – and all three were substantially revised in 2025 and 2026. This post maps the current state across AWS, Microsoft and Google Cloud so you can decide where to invest first.

TL;DR

  • Each hyperscaler runs a formal partner program – AWS Partner Network, Microsoft AI Cloud Partner Program (MAICPP) and Google Cloud Partner Network – with broadly parallel structures but meaningfully different mechanics, naming conventions and 2026 vintages.
  • Program membership is the gate, not the goal. The valuable assets sit one or two layers below: ISV-specific co-sell programs (ISVA / Azure IP Co-Sell Eligible / Co-sell Partner path), specialisations or competencies and the technical validations that underwrite them (FTR / Well-Architected Review / Architecture Review).
  • All three programs were substantially revised in 2025–2026. Microsoft’s rename from Microsoft Cloud Partner Program to MAICPP, Google’s rollout of the new Partner Network and partners report that AWS Specialisation renewal requirements have tightened in 2025–2026, with ACE activity increasingly connected to renewal outcomes – verify current renewal thresholds in AWS Partner Central before planning a renewal cycle.
  • Customer research is consistent: specialisations are a top-3 selection criterion for the buyer in a majority of enterprise software decisions. Choose programs to invest in based on which buyer your specialisation will be visible to.
  • Don’t try to take all three programs to their top tier simultaneously. Sequence: pick the hyperscaler with the largest customer footprint, get to a working co-sell-eligible status on that platform, then add the second.

How the Three Programs Compare at a Glance

The table below is the high-level orientation. Detailed mechanics are in the sections that follow.

DimensionAWSMicrosoftGoogle Cloud
Overarching programAWS Partner Network (APN)Microsoft AI Cloud Partner Program (MAICPP) – replaces Microsoft Cloud Partner Program (renamed July 2023)Google Cloud Partner Network – new programme formally rolling out Q1 2026, with six-month transition window; Partner Advantage remains the public-facing name on some pages during transition
Partner Paths / archetypesSoftware, Services, Hardware, Distribution, Training (Partner Paths)Solutions Partner designations across six solution areasCo-sell Partner, Services Partner, Technology Partner (new Q1 2026 paths; Build / Sell / Service are the former Partner Advantage archetypes)
Tier modelServices Partner Tiers: Select, Advanced and Premier (applies to Services Path only; Software and Hardware Path validation does not use this tier model)Solutions Partner designations with sub-specialisationsSelect / Premier / Diamond, outcome-based
ISV co-sell programISV Accelerate (ISVA)Azure IP Co-Sell Eligible + ISV SuccessCo-sell Partner path (ISVs developing or integrating solutions with Google Cloud and Google Workspace; see Google Cloud Marketplace for co-sell mechanics)
Reseller programSolution Provider Program (SPP)Cloud Solution Provider (CSP)Services Partner path (resellers)
Specialisation layerAWS Specializations (types: AWS Competency, Service Delivery, Service Ready, MSP); Qualified Software is an FTR-earned badge, not a Specialization categorySolutions Partner designations and “specialisations” sub-badgescompetency framework (revised Q1 2026)
Technical validationFoundational Technical Review (FTR)Azure Well-Architected ReviewArchitecture Review
2026 vintageNew: three Agentic AI categories in AWS AI Competency, Partner Greenfield Program, AWS Partner Central enhancements including Marketing Central AI-powered agents (2026); Marketplace private-offer enhancements; ISV Workload Migration Program direct credit disbursementExisting: MAICPP rename complete; AI-category additionsNew: complete programme reset rolling out Q1 2026

The names differ; the structural intent is similar. The mechanics for how to enrol, validate and progress are not.

Why the Formal Program Matters

Membership of a hyperscaler’s partner program is mostly a gating mechanism. The membership tier itself rarely produces revenue. What program membership does is unlock the next layer of capability: opportunity-sharing systems (ACE / PSC / Google Cloud’s partner portal), marketplace seller status, technical validation programs, MDF funding eligibility and the formal co-sell programs (ISVA / Azure IP Co-Sell Eligible / Co-sell Partner path) that are the meaningful currency.

This means a working strategy for partner programs is one stage removed from where most first-time alliance leaders look. The wrong question is “what tier of which programs should I be in?” The right question is “what does my motion need unlocked, and what is the minimum-friction path through the formal program structure to get to it?”

One category of benefit that deserves direct mention: most Specialisation-level and above programs include a tier of non-financial marketing benefits – co-branded press release rights, jointly-published collateral slots, co-hosted webinar entitlements, featured directory placement, conference presence allocations. These don’t accrue to the alliance team’s pipeline metrics and are consequently underused. They require a marketing owner with the brief and the bandwidth to activate them before the program year closes. The detailed treatment is in Cloud Provider Funding.

This post walks through each of the three programs as they exist in mid-2026, identifies the layers below the membership tier that actually produce value and offers a decision guide for where to invest if you’re starting from scratch or rationalising existing investment. The detailed per-platform co-sell mechanics are in AWS Co-Sell, Microsoft Co-Sell and Google Co-Sell; this post focuses on the program structures that sit underneath those motions. It also pairs naturally with Cloud Alliance Team (the team that operates these programs) and Cloud Provider Funding (the funding that program tier unlocks).

AWS Partner Network (APN)

The AWS Partner Network is structured around five Partner Paths, each describing the type of partner business AWS wants to recognise: Software, Services, Hardware, Distribution and Training. ISVs typically join the Software Path; SI and MSP partners join the Services Path. Most ISVs of any scale also hold a presence on the Services Path if they have a customer-success organisation that does delivery work.

Within Software Path, partners qualify software through the AWS Foundational Technical Review, reaching Validated or Differentiated status in AWS Partner Central. AWS Services Partner Tiers – Select, Advanced and Premier – use launched opportunities, MRR, certifications, accreditations, business planning and validations as their progression thresholds; these apply to the Services Path, not Software Path. AWS ISV Accelerate uses separate eligibility criteria – see below. Practitioners familiar with the programme note that AWS tightened renewal criteria in 2025 and again in 2026, moving the bar from activity-led (you submitted the work) to execution-led (the work produced an outcome). Verify current requirements in AWS Partner Central.

The ISV co-sell program is AWS ISV Accelerate (ISVA). Eligibility currently requires: one or more software products listed as general availability in AWS Marketplace; ACE programme eligibility; Validated or Differentiated status in AWS Partner Central; Amazon Payee Central setup; at least five launched opportunities from ACE or AWS Marketplace Private Offers in the past 12 months; at least 15 qualified ACE opportunities in the past 12 months; at least one individual completing the Co-Selling with AWS learning module; and at least $2,000 in recognised AWS Account revenue at enrolment. In practice, the binding constraint is usually accumulating the closed-won co-sell history these thresholds require – which is gated by the very motion ISVA is meant to support. Plan the runway accordingly. The benefits include co-sell support with AWS Account Managers, co-sell incentives when transacting through AWS Marketplace Private Offers, training, events and access to ISV-specific funding and resources. Beginning in January 2025, AWS expanded the SaaS Co-Sell Benefit – also known as SaaS Revenue Recognition – to all ISV Accelerate Partners transacting in AWS Marketplace, including eligible Startups. Full mechanics in AWS Co-Sell.

Services-path partners encounter the MSP Program (for managed service providers, with its own technical audit) and the Solution Provider Program (SPP, AWS’s reseller motion, distinct from marketplace channel partner motions like CPPO). Each has separate eligibility and separate audits; practitioners running multiple programmes simultaneously note that the combined reporting and renewal overhead can be substantial. The total ground covered by partner-program work is wider than a first-time alliance lead typically expects.

Three 2026 additions deserve flagging. The first is agentic AI categories within the AWS AI Competency – three new categories (Agentic AI Applications, Agentic AI Tools and Agentic AI Consulting Services) recognising partners building or operating AI agents on AWS. Partners applying must be Validated or Differentiated members of the Services or Software Path. The second is the Partner Greenfield Program (PGP), designed to help eligible partners build and scale an AWS Greenfield business practice in priority areas including Migration and Modernisation, Generative AI and Security. It provides multi-year co-investment, enablement resources, funding and co-sell support. Current public eligibility points to Differentiated status plus relevant Specialization or ISV Accelerate participation – this is not a general new-partner onboarding programme. Most established ISVs won’t need PGP, but the program’s existence signals where AWS is investing partner-recruitment effort over the next two to three years.

AWS Specialisations and Validations

One step below APN program tier sit the Specialisations and adjacent validations that genuinely move customer perception and AWS-field engagement. AWS Specializations is the broader validation programme. Current Specialization types include AWS Competency (validating technical excellence in industry and use-case challenges), AWS Service Delivery Specialization, AWS Service Ready Specialization and AWS Managed Services Provider Specialization. These are distinct programmes with separate eligibility and technical requirements. Service Ready designates a product validated against a specific AWS service. Qualified Software is a badge earned after an approved AWS Foundational Technical Review, conferring a listing in the AWS Partner Solutions Finder.

FTR is a foundational review that qualifies software or solutions and can unlock AWS partner benefits including certain Competency access and ISV Accelerate eligibility. AWS Specializations additionally require programme-specific technical assessments and customer-success evidence aligned to the chosen Specialization. FTR helps partners identify and remediate risks against a subset of AWS Well-Architected best practices, focusing on security, reliability and operational excellence. AWS now highlights automated review using Amazon Bedrock – submissions that meet FTR requirements can receive approval in as little as 30 minutes, though the preparation work (architecture evidence, documentation, controls) takes meaningful engineering time regardless of the review mechanism. FTR is valid for three years from the date of approval. Partners must submit renewal requests before that date to maintain Validated status, and AWS recommends periodic internal architecture reviews between cycles – the product evolving between renewals doesn’t automatically invalidate the validation, but significant architectural changes should trigger an early reassessment.

Partners report that the 2026 change with the largest operational impact is that Specialisation renewals now require demonstrable ACE activity tied to the relevant Specialisation Solutions, measured on a rolling 12-month basis – a shift from “did you do the work” to “did the work produce outcomes.” For ISVs operating ACE poorly, this is significant: a Specialisation that took around 200 person-hours to earn (AWS’s own APN Blog puts the Competency preparation effort at approximately 200 hours) can lapse if the co-sell motion underneath it isn’t running. The CONNACT article AWS Competencies: An Extremely Overlooked Sales Growth Lever for ISVs? makes this argument at length and is worth reading alongside this section.

Note: the author has a professional relationship with CONNACT; see the series disclosure on the hub page.

Two practical implications. First, Specialisation investment should be paired with co-sell motion investment, not treated as a one-time engineering effort. Second, if the co-sell motion is genuinely working, Specialisation renewal is largely a reporting exercise rather than a fresh effort. The two functions reinforce each other – or, if either is weak, drag each other down.

Microsoft AI Cloud Partner Program (MAICPP)

The Microsoft Partner Network (MPN) was rebranded as the Microsoft Cloud Partner Program in 2022, then rebranded again as Microsoft AI Cloud Partner Program (MAICPP) at Microsoft Inspire in July 2023. Current Partner Center documentation uses only the MAICPP name. The structure is built around six solution areas: Infrastructure (Azure), Data & AI (Azure), Digital & App Innovation (Azure), Modern Work, Security and Business Applications.

Partners earn a Solutions Partner designation in each solution area by accumulating points across three dimensions: performance (deal value, customer adds), skilling (certifications) and customer success (deployments, growth, retention). The threshold to qualify for a designation is meaningful; achieving designations in multiple solution areas requires both broad capability and operational commitment to point accumulation across all three dimensions. Partners with designations can earn additional “specialisations” – sub-badges within a solution area, validating depth in a particular workload like SAP on Azure, AI Apps or Identity & Access Management.

The ISV-relevant programs sit alongside the solution area structure rather than within it. ISV Success is a 12-month programme for early-stage ISVs to innovate rapidly, build well-architected applications, publish to Microsoft Marketplace and grow sales. It is free in the first year. ISV Success is not the exclusive path to co-sell-ready status, but enrolment and Marketplace publication are prerequisites to co-sell-ready and, in turn, Azure IP Co-Sell Eligible status. Azure IP Co-Sell Eligible is the upgraded status – the meaningful one for enterprise Microsoft business – that makes the ISV’s offer count toward customer MACC drawdown and earns the offer a Microsoft Preferred Solutions badge in Marketplace. Co-Sell Ready (a softer status, without MACC eligibility) is a useful intermediate state; the gap between Co-Sell Ready and IP Co-Sell Eligible is where most ISVs spend the most program-engineering time.

The reseller channel is the Cloud Solution Provider (CSP) program – Microsoft’s margin-based resale channel, distinct from marketplace-channel mechanics like the MPO. CSP transactions don’t draw down MACC, which is the structural reason MPO exists separately and is increasingly preferred for ISV-channel-customer triangles.

The technical validation for Azure IP Co-Sell Eligible status is an Azure-platformed technical validation confirming the solution meets Microsoft Marketplace policies and is primarily platformed in Azure – described in Partner Center documentation as a subset of reference architecture diagram review. The Azure Well-Architected Review is a separate, valuable but not formally required self-assessment tool aligned to the Azure Well-Architected Framework, covering five pillars: Reliability, Security, Cost Optimisation, Operational Excellence and Performance Efficiency. The terminology is worth being precise about: the Azure Well-Architected Framework is the body of architectural guidance (the methodology); the Azure Well-Architected Review is the structured assessment that scores a workload against it. AWS has a parallel distinction: the AWS Well-Architected Framework is the methodology, the AWS Well-Architected Tool is the self-service instrument, and the Foundational Technical Review (FTR) is the specific partner-program gating assessment that draws on it. Like FTR, the Azure Well-Architected Review is not one-and-done. Like FTR, it benefits from preparation and documentation groundwork before the formal assessment begins – ISVs who treat either review as a box-ticking exercise rather than an architectural evidence exercise typically find it harder than expected. Detailed Microsoft co-sell mechanics, including the day-to-day operation of PSC and the MACC dynamics, are in Microsoft Co-Sell.

Google Cloud Partner Network

Google Cloud’s partner programme was substantially reset with the formal rollout of Google Cloud Partner Network in Q1 2026, with a six-month transition window for partners on the previous programme. Some public Google pages continue to carry the Partner Advantage name during the transition. The change is not a rename: it’s a structural reset with a new tier model, a new competency framework and a new approach to outcome measurement.

The new tier model has three levels – Select, Premier and Diamond – with progression based on proven customer success and exceptional outcomes across Google Cloud and Google Workspace. The competency framework separately measures capacity – through certifications and sales credentials – and capability – through contributions to validated closed-won opportunities. The new competency framework replaces the older specialisation model; it directly distinguishes capacity (skills and certifications held by the partner’s team) from capability (closed-won customer outcomes proving that capacity in production). It is understood that progress on both dimensions is needed for meaningful tier and competency advancement, though the relative weighting is not detailed in current public documentation.

The partner paths under the new Partner Network are Co-sell Partner, Services Partner and Technology Partner – replacing the Build / Sell / Service archetypes that belonged to Partner Advantage. ISVs developing or integrating solutions with Google Cloud typically align to the Co-sell Partner path; channel partners and resellers to the Services Partner path; systems integrators and other service providers to the Technology Partner path – though Google’s public documentation does not map these one-to-one exclusively, and partners can hold multiple paths. It is understood that many sophisticated partners maintain presence across more than one.

A 2026 development worth noting: Cloud Next 2026 saw a $750 million partner fund announced for agentic AI development – one of the most significant single partner investment commitments announced by any hyperscaler at the time. The fund is directed at helping partners build and deploy agentic AI on Google’s platform rather than at partner co-sell operations tooling, but it signals the competitive intensity of Google’s partner investment and the direction of the program’s strategic focus.

The underlying technical validation process – referred to in practitioner circles as an Architecture Review, broadly comparable in purpose to AWS FTR and Microsoft’s Well-Architected Review – requires that Marketplace-listed products meet Google Cloud’s onboarding and architectural standards, with re-review required if changes affect compliance. The specific mechanics and naming within the current Google Cloud Partner Network are not fully documented in current public sources; verify current requirements in Google Cloud Marketplace partner documentation. Practitioners familiar with the programme note that Google Cloud’s validation bar is generally regarded as rigorous, partly because of the relative scale and selectivity of the programme.

Two practical observations on the Google program. First, the program reset means much of what was true about Partner Advantage no longer applies; legacy practitioner advice from before late 2025 is suspect and should be re-validated. Second, practitioners familiar with the programme note that Google’s co-sell tooling has historically been lighter than AWS’s or Microsoft’s – the formal opportunity-sharing system less workflow-driven, with more work happening through direct AE / CE engagement than through a portal. Google’s 2026 programme updates do include new automation and tooling enhancements; verify current capabilities in the partner portal. This shapes how ISVs should staff their Google motion. Detail in Google Co-Sell.

How the Three Programs Map to Each Other

Despite the wildly different names and operating mechanics, the three programs are recognisably the same skeleton with three different coats of paint. The structural correspondences are worth mapping directly because they make multi-cloud program planning tractable.

The ISV and technology-partner motions correspond most closely to AWS ISVA, Microsoft Azure IP Co-Sell Eligible (often via ISV Success for new ISVs) and Google’s Co-sell Partner path for partners developing or integrating solutions with Google Cloud and Google Workspace. All three are the gates to meaningful co-sell-eligible engagement with the hyperscaler’s field. The eligibility criteria differ; the destination is functionally equivalent.

The services and capability programs correspond: AWS Specializations (current types: AWS Competency, Service Delivery, Service Ready and MSP), Microsoft Solutions Partner designations (with sub-specialisations), Google’s new competency framework. All three validate that the partner has demonstrated technical and commercial proficiency in a specific workload or industry.

The reseller programs correspond: AWS Solution Provider Program, Microsoft CSP, Google Services Partner path (resellers). All three structure margin-based resale, distinct from marketplace channel motions (CPPO / MPO / channel-partner private offers).

The technical validations correspond: AWS FTR, Microsoft Well-Architected Review, Google Architecture Review. Each is a foundational technical review that unlocks or supports the programs above it. For AWS, FTR qualifies software and can unlock Competency access and ISV Accelerate eligibility; specific Specialization types also require additional programme-specific assessments and customer-success evidence.

This mapping is genuinely useful when planning a multi-cloud program portfolio. Once you’ve earned one platform’s equivalent in a category, the technical-validation work on the second is typically lighter – the engineering rigour is largely transferable. The commercial evidence transfers less cleanly: each hyperscaler’s field weights platform-specific customer references and consumption proof, and the relationship capital does not transfer at all. Plan for the second platform’s programme work to take roughly half the effort of the first, but its traction timeline to look more like a fresh start. The underlying programme mechanics are not three entirely separate efforts – that is a genuine multi-cloud efficiency. The field motion, however, is.

Why Customers Care About Specialisations

AWS cites Canalys 2023 research showing that 87% of customers rank AWS Specializations as a top-three partner-selection criterion, with 60% ranking them as the top criterion. Treat these specific percentages as directional and as AWS-cited rather than independently verified primary-source research – they are specific to AWS Specializations, circulate through vendor channels and rely on methodologies that aren’t always fully transparent. The direction is consistent: customers use specialisations as a filter when sorting through which partners can legitimately deliver on a specific workload.

This buyer behaviour translates into hyperscaler-field behaviour. Hyperscaler AEs use specialisations as a filter when bringing partners into a deal: the specialisation tells the AE that the partner has been validated for the workload at hand, lowering the perceived risk of partner-attach and shortening the AE’s mental qualification process. An ISV without the relevant specialisation is functionally invisible in that conversation; an ISV with it is at least in the consideration set.

This is the structural reason specialisations are worth investing in even when the engineering effort feels disproportionate. The specialisation isn’t valuable in itself – it’s valuable because it changes who sees you, both on the buyer side and on the hyperscaler-field side. Treat it as marketing infrastructure, not as a quality kitemark.

Industry and Vertical Specialisations

All three hyperscalers run vertical specialisation programs covering financial services, healthcare and life sciences, retail, public sector and (more recently) energy and manufacturing. Industry specialisations are commercially distinct from horizontal workload specialisations: a horizontal badge tells the AE “this partner can do data work”; an industry badge tells the AE “this partner can do data work within this industry’s regulatory and operational context.”

For ISVs serving specific verticals deeply – fintechs, healthtechs, regtechs – the industry specialisation typically unlocks more co-sell value than the horizontal equivalent, because the hyperscaler’s industry sales leads use it as the primary filter for partner introductions. For ISVs operating horizontally, industry specialisations are usually a lower-priority investment.

Technical validation overhead is higher for industry competencies (or specialisations on AWS and Microsoft), particularly in regulated sectors where compliance evidence becomes part of the audit. Plan engineering and compliance time accordingly.

Costs and Effort: What to Budget

Program enrolment is free at the entry tier on all three platforms. The real cost is time. A single AWS Specialisation typically requires 100–200 person-hours of engineering, product, marketing and customer-evidence work across the certification cycle – partners report spending around 100 hours for AWS Service Ready and around 200 hours for AWS Competency, per AWS’s own APN Blog. Effort at the higher end is real for complex implementations and industry specialisations. A first Well-Architected Review or Architecture Review requires comparable preparation – the engineering evidence-gathering and documentation work typically runs to several weeks regardless of the final review turnaround. For AWS FTR specifically, automated review can return results quickly once a submission meets requirements; the investment is in the preparation, not the review clock.

The compounded total for meaningful presence across all three hyperscalers’ specialisation programs is a multi-quarter engineering investment. For most ISVs under $50M ARR, sequencing (one platform at a time, two-quarter offset) is the right answer. For ISVs past that, parallelisation usually pays back faster but requires a proportionally larger team to execute. Some validations and audits carry direct fees; check current program documentation rather than relying on figures that change annually.

Where to Start If You Have to Choose One

A decision guide for the common case of an ISV with limited bandwidth that has to pick one hyperscaler to invest in first:

  1. Where is your customer base? Look at the existing customer footprint by hyperscaler. Pick the one with the largest committed-spend customer cohort. This is almost always the right answer for ISVs past first product-market fit.
  2. What is your product’s tenancy archetype? The answer reshapes which hyperscaler suits your motion best. ISV-hosted SaaS products align naturally with the partner-side PDM motion that all three hyperscalers run; customer-deployed products align with the customer-facing AE motion, which varies in vibrancy across the three. The structural dynamics are in ISV-Hosted vs Customer-Deployed and they matter more than the program-tier differences.
  3. What does your team capacity allow? A two-person alliance function cannot meaningfully run all three programs at once. Pick one, get to co-sell-eligible status, then add the second when the first has produced a working motion. Adding the third typically happens 12–18 months after the first.
  4. Where are your strongest customer references already? Joint references with hyperscaler-side AEs are the most valuable currency in tier progression. The hyperscaler where you already have strong references is the one where the next mile of program progression will be cheapest.

The decision guide does not address “which program is best designed” or “which is most mature.” All three programs are well-developed enough to be worth the effort if there’s a customer-side case. The cost of choosing wrongly is small compared to the cost of trying to do all three at once.

For an ISV with a strong reason to multi-home, the sequence usually plays out as: cloud #1 to working co-sell-eligible status (months 0–9), cloud #2 to enrolment and basic validation (months 6–12), cloud #2 to working co-sell-eligible status (months 12–18), cloud #3 enrolment and basic validation (months 12–18), cloud #3 to working co-sell-eligible status (months 18–24). Faster sequencing is possible with proportionally more dedicated headcount.

What This Looks Like in Practice

A composite example, drawn from patterns across multiple real situations.

A data-platform ISV with $60M ARR and a hybrid tenancy model (control plane in the ISV’s account, data plane in customer accounts) enrolled in APN and earned an AWS Data & Analytics Specialisation in 2023. The Specialisation renewal came around in Q4 2025. Partners familiar with the updated renewal requirements note that ACE activity is increasingly connected to renewal outcomes; in this case the ISV’s ACE activity had drifted, with opportunities being submitted but launched counts below what renewal tracking required. A six-week recovery sprint, focused on closing out three stalled co-sell opportunities and getting clean attribution on two more, kept the Specialisation current.

The ISV had a long-standing Microsoft Co-Sell Ready status but had never upgraded to Azure IP Co-Sell Eligible because the engineering effort had been deferred multiple times. In 2025, the alliance leader pursued a 12-month ISV Success engagement with Microsoft, using that structure to drive the Azure-platformed technical validation and marketplace listing required for IP Co-Sell Eligible status. The first MACC-drawing Microsoft Marketplace transaction closed two months after the status was achieved.

Google Cloud was a deliberate “not yet” decision through 2025. The Q1 2026 programme reset shifted the calculus: the new outcome-based tier model rewarded ISVs willing to commit early, and a Google CE relationship had been quietly building for 12 months around a strategically interesting joint customer. The ISV enrolled in Google Cloud Partner Network in Q2 2026, completed the product approval and validation process in 13 weeks – the architectural rigour built for the other two platforms compounded here – and reached Premier tier with one customer reference by Q4 2026.

None of this is unusual. The pattern – AWS as the established motion, Microsoft as the deferred-then-recovered investment, Google as the late-but-deliberate addition – is the most common multi-cloud trajectory for ISVs in the mid-sized ARR band. The total program-engineering effort over 24 months was real but manageable, and the parallel benefits across all three platforms exceeded what any single-platform investment of the same total effort would have produced.

Common Pitfalls

A handful of the patterns that recur in alliance teams new to formal program work:

  • Chasing badges that don’t unlock revenue. A Specialisation is valuable when paired with a working motion that the Specialisation makes visible. A Specialisation earned without that motion produces a wall ornament. Decide what the Specialisation is going to unlock before you start the engineering work.
  • Joining all three programs simultaneously. The total program-management overhead of three concurrent enrolments is more than triple the overhead of one – the operational interference and the difficulty of holding all three to the same standard amplify the cost. Sequence first; parallelise once the first program has produced a working motion.
  • Ignoring program changes that invalidate your tier. Hyperscaler programs change roughly annually. A renewal cycle missed by 30 days can cost a tier that took a year to earn. Build the renewal schedule into the alliance team’s operating rhythm with explicit calendar ownership.
  • Letting Specialisations lapse. Closely related to the previous point but worth flagging separately. Once a Specialisation is earned, the marginal cost of maintaining it is far below the cost of re-earning it. Don’t let it lapse for want of administrative attention.
  • Doing FTR / Well-Architected / Architecture Review once and never again. The product evolves. The validation must too. ISVs that treat technical validation as one-and-done are running on lapsed credentials sooner than they expect – AWS FTR has a three-year validity window, but the renewal deadline arrives faster than it looks and significant architectural changes should trigger earlier reassessment. The catch is that product and engineering teams often don’t own the renewal calendar; alliance teams typically need to.
  • Over-claiming coverage. Specialisations are unforgiving of partners who claim capability they can’t demonstrate. Customer references that fall over under hyperscaler-side reference-check can cost renewals faster than under-investment in the program itself.

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 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.

Where to Go Next

Within this pillar:

Per-cloud co-sell mechanics:

  • AWS Co-Sell – the operating manual for ACE, ISVA and the AWS co-sell motion that Specialisation status unlocks.
  • Microsoft Co-Sell – PSC, Azure IP Co-Sell Eligible and the MACC dynamics that Microsoft co-sell runs on.
  • Google Co-Sell – the new Google Cloud Partner Network and the AE-mediated motion underneath it.

Adjacent posts:

The full series glossary is at Glossary.

Sources

AWS

Microsoft

Google Cloud

Practitioner Sources

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

Note: the author has a professional relationship with CONNACT; see the series disclosure on the hub page.

Last reviewed: 2026-07-01. Vendor-specific clusters in this series are reviewed twice yearly after the major hyperscaler conferences plus mid-cycle for major program changes (renames, fee structure changes, new offer types). Major 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/.