Microsoft MPSA to MCA Transition: What You Lose and What to Do About It

The Microsoft Products and Services Agreement (MPSA) was Microsoft's flexible volume licensing vehicle for mid-market and enterprise organisations that needed a single agreement to cover perpetual licences, subscriptions, and cloud services without committing to the three-year Enterprise Agreement structure. MPSA allowed organisations to purchase what they needed, when they needed it, under a single master agreement with negotiable terms, without minimum user commitments.

Microsoft has been systematically moving MPSA customers toward MCA (Microsoft Customer Agreement) — its simplified, digitally-accepted, non-negotiated agreement framework. The MPSA is no longer available for new customers, and existing MPSA holders are being encouraged (with increasing urgency) to transition. The framing from Microsoft is simplicity and modernisation. The commercial reality for enterprise buyers is considerably more nuanced.

What MPSA Was: The Commercial Structure

MPSA was structured as a single master agreement with purchasing accounts. The commercial characteristics that made it attractive for enterprise buyers included:

• Negotiable terms: Unlike MCA, MPSA could be negotiated. Organisations with significant Microsoft spend could secure price protection clauses, custom payment terms, audit scope limitations, and other commercially important provisions.
• Perpetual licence clarity: MPSA explicitly governed perpetual licence purchases with clear entitlement documentation, VLSC access, and rights management. The relationship between a perpetual licence, its version rights, and any associated Software Assurance was clearly defined.
• Stable contractual framework: MPSA terms could not be changed unilaterally by Microsoft during the agreement term. Commercial certainty over multi-year periods was contractually protected.
• Mixed purchasing flexibility: MPSA allowed perpetual purchases, subscriptions, and cloud services under a single agreement without a minimum commitment threshold. This made it the right model for organisations that needed flexibility across a mixed-maturity licensing estate.
• Software Assurance: MPSA supported SA purchases on perpetual products, providing licence mobility, step-up rights, disaster recovery entitlements, and training vouchers — benefits entirely absent from MCA.

What MCA Is: The Commercial Reality

The Microsoft Customer Agreement is Microsoft's cloud-era standard terms framework. It replaces negotiated agreements with digitally-accepted standard terms. The MCA structure has genuine advantages for some use cases — particularly small organisations purchasing cloud services who do not have the volume or leverage to negotiate an EA or MPSA. For organisations with significant Microsoft spend, the MCA's commercial weaknesses are material.

The critical MCA characteristics that differ from MPSA:

Unilateral Term Change Rights

Microsoft reserves the right to change MCA terms with 30 days' notice. This is not a theoretical risk — Microsoft has exercised its right to update terms multiple times. The practical consequence is that commercial protections negotiated at agreement inception can be removed by Microsoft without your consent. MPSA did not include this provision for terms within the agreement period.

No Price Negotiation

MCA pricing is list price. There is no negotiation mechanism. For M365 and other core products, this represents a significant cost increase versus either an EA (which provides negotiated discounts of 15–30%) or a well-structured MPSA (which provided pricing leverage for volume purchasers). When Microsoft implements a price increase — and the history of price increases suggests this happens regularly — MCA customers absorb it immediately with no protection.

No Software Assurance

MCA does not include Software Assurance on perpetual Microsoft products. For organisations with a meaningful on-premises estate (Windows Server, SQL Server, Office perpetual), the loss of SA removes licence mobility rights, step-up entitlements, disaster recovery rights, and training benefits that may have significant value. See our Software Assurance guide for a benefit-by-benefit valuation framework.

Perpetual Licence Entitlement Complexity

MCA does not provide the same clarity of perpetual licence governance that MPSA offered. For organisations with perpetual licences acquired under MPSA, the transition to MCA creates questions about entitlement documentation, VLSC record management, and ongoing version rights that Microsoft's transition guidance does not comprehensively address. Before transitioning, all MPSA perpetual licence records should be comprehensively documented and independently verified.

MPSA vs MCA: Side-by-Side Commercial Comparison

The Four Key Risks in the MPSA-to-MCA Transition

Risk 1: Perpetual Licence Entitlement Loss

When an MPSA is transitioned to MCA, the mechanism for documenting and proving perpetual licence entitlements changes. VLSC (the Volume Licensing Service Centre) records should be preserved and independently verified before transition. Any perpetual licences — Office, Windows Server, SQL Server, Exchange Server, SharePoint Server — should have their entitlements extracted, documented, and archived before the MPSA closes. Post-transition, recovering proof of these entitlements becomes significantly harder. This is not a hypothetical: Microsoft audit programmes have cited insufficient entitlement documentation as a gap in organisations that transitioned without adequate records preservation.

Risk 2: Software Assurance Expiry Without Replacement

If your MPSA includes active Software Assurance on perpetual products, SA benefit expiry timing relative to the MPSA transition is critical. SA benefits — particularly licence mobility, step-up rights, and disaster recovery — should be consumed before they expire through the transition. Licence mobility rights (which allow SA-covered licences to run on third-party shared servers and cloud infrastructure) are specifically at risk. Once SA expires and you are on MCA with no SA, those mobility rights are gone unless you acquire them through an EA.

Risk 3: Pricing Exposure Crystallisation

MPSA pricing arrangements — including any negotiated volume discounts or price protection provisions — do not transfer to MCA. On transition, you move to MCA list pricing. For M365 products, this typically represents a 15–25% price increase versus negotiated MPSA rates. If you have been purchasing M365 at MPSA rates below current list price, the transition will crystallise that price increase in your first MCA billing cycle.

Risk 4: Loss of Negotiated Commercial Protections

Any commercially sensitive provisions negotiated into your MPSA — audit scope limitations, specific payment terms, affiliate coverage clauses, data processing terms, limitation of liability provisions — do not transfer to MCA. MCA is a take-it-or-leave-it agreement. If your MPSA contained hard-won protections (particularly audit scope limitations or change-of-control provisions), their loss in the MCA transition is a real commercial deterioration.

The Alternatives: EA or Staying on MPSA

When Microsoft pushes an MPSA transition, the framing is "MPSA to MCA." But for organisations of sufficient scale, the real decision is "MPSA to MCA or MPSA to EA." For many organisations that have been on MPSA, an EA is actually the commercially superior alternative — not because the EA is perfect, but because it preserves negotiated pricing, Software Assurance access, MACC economics, and price protection that MCA strips away.

When EA Is the Better Alternative

Consider an EA transition instead of MCA when any of the following apply:

• Your annual Microsoft spend exceeds £200,000 and headcount is stable (±10% per year)
• You have an active on-premises estate with perpetual products where Software Assurance has meaningful value
• Your Azure consumption exceeds £150,000 annually and MACC economics are relevant
• You have negotiated commercial protections in your MPSA that you want to preserve or improve
• You can negotiate an EA at a lower per-seat cost than MCA list pricing (which is almost always achievable for organisations above the EA minimum threshold)

The EA's three-year commitment is a real constraint. But for organisations where the conditions above apply, the EA's commercial advantages — negotiated pricing, price lock, SA access, MACC, and negotiable terms — make it a substantially better model than MCA. Our full EA vs CSP vs MCA cost comparison provides the methodology to model this decision for your specific circumstances.

When MCA Is Acceptable

MCA is commercially acceptable (though not optimal) when: your seat count is below 200 and EA's minimum commitment threshold makes it impractical; your Microsoft estate is entirely cloud-native with no perpetual products and no SA benefits at risk; your Azure consumption is modest (below £100,000 annually); and your headcount is volatile enough that a three-year EA commitment creates significant over-commitment risk.

Even in these scenarios, CSP through a well-selected Direct Bill partner typically provides better commercial terms than MCA direct for M365 products — the same flexibility without the MCA's structural price increase and with the ability to benchmark partner pricing competitively. See our guide to direct vs indirect CSP for the partner selection framework.

MPSA-to-MCA Transition Playbook

If you are on MPSA and facing a transition — whether because your MPSA is expiring, Microsoft is pushing the conversation, or you are evaluating options proactively — the following sequence applies:

Step 1: Conduct a Full MPSA Entitlement Audit

Before any transition discussion, extract all perpetual licence entitlements from VLSC. Document every product, version, edition, quantity, and SA status. This record becomes the baseline for your perpetual licence inventory regardless of which model you transition to. Do this before the MPSA closes — after closure, documentation access is significantly more difficult. The licence compliance audit methodology provides the framework.

Step 2: Consume Unused SA Benefits Before Expiry

Review all active SA benefits — training vouchers, step-up rights, planning services, home use programme. Identify any that expire at MPSA close and accelerate consumption. Licence mobility documentation should be updated while SA is still active. Step-up licence rights should be exercised if they are commercially beneficial.

Step 3: Model the Three-Year Economics

Before accepting MCA, model the three-year total cost of MCA versus a negotiated EA. Include: licence fee delta, SA value loss, Azure MACC differential, price increase exposure, and switching costs. In most scenarios above 500 seats, the EA will be materially cheaper over three years even accounting for the commitment structure.

Step 4: Negotiate Simultaneously

Use the MPSA expiry as a negotiation trigger. Microsoft has commercial motivation to retain your spend — they want to move you to MCA but they equally do not want to lose the relationship to a competitor. A competitive evaluation (Google Workspace, AWS for the Azure component, Slack/Zoom for M365 workloads) during the MPSA transition period creates the leverage for meaningful EA discount conversations. See our competitive pressure guide for the methodology.

Step 5: If Choosing MCA, Extract What Protections You Can

If MCA is genuinely the right model (or the only practical option), negotiate what you can within its constraints. The MCA itself is not negotiable, but the Order or purchasing terms may contain provisions (payment terms, billing frequency, support package) that can be structured to minimise commercial risk. Ensure Data Processing Addendum terms are reviewed and accepted appropriately. Document all perpetual licence entitlements independently before the MPSA closes.

Summary

The MPSA-to-MCA transition is not a neutral modernisation exercise. It is a commercial change that removes negotiated pricing, Software Assurance access, stable contractual terms, and price protection — replacing them with a non-negotiated, list-price, unilaterally-modifiable agreement framework. For most enterprise organisations above 200 seats, the transition presents a genuine decision point between accepting MCA and evaluating whether an EA provides better commercial terms.

The practical sequence is: document all perpetual entitlements before your MPSA closes, consume remaining SA benefits, model the three-year EA vs MCA economics, and use the transition timing as a negotiation trigger. Do not accept MCA as the default path without conducting that analysis — and do not rely on Microsoft's account team or your current LSP to conduct it for you. Both parties have financial incentives that are not aligned with your cost minimisation. Independent analysis is the prerequisite for a well-informed transition decision.