SPA24 and Open Source: Can the UK Public Sector Cut Costs Safely?

The UK government’s five‑year Memorandum of Understanding with Microsoft — the Strategic Partnership Arrangement 2024 (SPA24) — commits public bodies to a scale of procurement that the Crown Commercial Service expects will amount to roughly £9 billion over the life of the deal, and that commitment raises a simple fiscal and strategic question: should ministers and procurement teams actively hunt for open source alternatives to Microsoft to save money and reduce vendor lock‑in, or does the public sector’s dependency on Microsoft reflect legitimate operational realities that outweigh potential savings?

Background​

SPA24 replaced the earlier Digital Transformation Arrangement and began on 1 November 2024, intentionally broadening access across central government, devolved bodies and local public sector organisations to Microsoft products and services — from Microsoft 365 and Azure to Business Applications and, notably, Copilot. The arrangement was presented as a way to secure “enhanced value” through central negotiation and aggregation while preserving compliant procurement routes for individual organisations.
Public reporting and parliamentary answers show that in the final five months of the 2024/25 financial year the public sector spent about £1.9 billion on Microsoft licences and related purchases via CCS‑managed arrangements and their resellers. The government’s own planning figures imply a steady pattern of usage under SPA24 that, when extrapolated, aligns with the CCS estimate of around £9 billion over five years — roughly £1.9 billion per year on average. That number has dominated public conversation because it is large, tangible, and politically salient in a tight fiscal environment.
At the same time, Microsoft has been enjoying record revenues and robust margins: the company reported $76.4 billion in revenue for the quarter ended 30 June 2025, with net income of $27.2 billion — figures that reflect very high profitability in cloud, productivity suites, and AI‑driven services. Market valuations have tracked these results: by mid‑2025 Microsoft’s market capitalisation moved well above the multi‑trillion‑dollar mark. Those corporate dynamics make negotiating downward pressure on price harder and raise questions about how much “discount” aggregation can realistically extract.

---

What SPA24 actually covers (and what it doesn’t)​

Scope and mechanics​

• SPA24 is a five‑year Memorandum of Understanding between CCS and Microsoft that provides a vehicle for eligible public sector organisations to purchase Microsoft licences and cloud services through resellers and frameworks.
• The arrangement explicitly includes Microsoft 365, Azure, Business Applications, and Microsoft Copilot — the latter being the first time generative AI products have been covered explicitly in this type of public‑sector MoU.
• Public bodies are not forced to buy via SPA24; they can still run their own compliant procurements. CCS promotes aggregated competitions via resellers to leverage scale.

Key procurement features​

• Aggregation: CCS can run bulk buying exercises through resellers to secure standardised pricing and terms.
• Flexibility: Organisations can choose frameworks or individual procurements to meet specific needs.
• Skilling and support: The MoU includes commitments to skills programmes and interoperability advice designed to accelerate public‑sector uptake of AI and cloud capabilities.

What is not centrally controlled​

• The Cabinet Office does not hold a complete, single‑line record of all Microsoft spending across departments and arm’s‑length bodies. Individual entities retain procurement responsibility, which complicates central oversight and makes it difficult to produce a single definitive figure for Microsoft spend outside CCS frameworks.

---

The financial argument: headline numbers, reality checks, and total cost of ownership​

The eye‑catching figure — roughly £9 billion over five years — is useful shorthand but needs unpacking.

• The £1.9 billion reported for the 2024/25 year is an aggregation that includes spend through SPA24 and the expiring DTA‑21 arrangement; it covered only a partial year of SPA24 in 2024/25.
• CCS expects comparable future spending patterns under SPA24 that produce the circa‑£9 billion five‑year total. That is an agency projection, not a legally binding capped commitment.
• Large headline licence costs are only part of the financial picture. The government should evaluate total cost of ownership (TCO), including:
• Migration costs (people, tools, legacy application rework)
• Training and transition time
• Support and operations (in‑house or contracted)
• Multiyear licence inflation, renewals and maintenance
• The cost of vendor lock‑in and future price negotiating leverage
• The opportunity cost of not investing elsewhere (healthcare staff, school repairs, capital projects)

A fair financial analysis therefore requires modelling the migration and disruption costs of any move away from Microsoft as carefully as it models licence savings. In many real‑world cases, short‑term licence savings can be swallowed by transition and integration expenses if the migration plan is not surgical and well‑funded.

---

The open source alternative case: where savings are realistic and where they aren’t​

Advocates of open source argue that many Microsoft‑branded functions — word processing, spreadsheets, email clients, some server workloads, and certain web stacks — have mature FOSS equivalents with negligible licence cost. But license cost is only one axis.
Strengths of the open source case:

• Lower licence bills: Replacing proprietary desktop productivity suites and certain server applications with open alternatives reduces per‑seat licence fees.
• Competition and diversity: A broader vendor mix can create competition, lower long‑term price escalation, and reduce single‑vendor dependence.
• Sovereignty and transparency: Open code means more control over data handling, potential to audit code paths, and reduce reliance on commercial roadmaps.
• Community innovation: Certain domains (Linux, PostgreSQL, Kubernetes, OpenStack and many web platform components) benefit from rapid community evolution matching or surpassing vendor features.

Practical limits and costs:

• Workload fit: Many departments run bespoke applications and third‑party integrations built on the Microsoft stack (Active Directory, Exchange, Teams integrations, Office macros). Replacing these is not a one‑to‑one substitution.
• User experience and productivity: Desktop and collaboration tool differences can impose retraining costs and friction that reduces productivity in the short term.
• Support and resilience: Commercial support for enterprise‑grade open source can be costly, and procuring robust SLAs from multiple suppliers increases supplier management overhead.
• Cloud dependencies: Microsoft Azure features and managed services (AI acceleration, identity services integrated across products) are embedded in both vendor and third‑party solutions; moving workloads away from Azure may require refactoring applications.

In short: open source can save money where workloads are modular, standard, and loosely coupled to the Microsoft ecosystem. But converting complex, integrated back‑office environments that rely on Microsoft identity, messaging, and productivity APIs into a hybrid or fully FOSS stack is a multi‑year programme that has to account for TCO, not just licence avoidance.

---

Vendor lock‑in, sovereignty and security — technical and political risks​

Consolidating large amounts of public‑sector data and services on a single global cloud/stack has effective operational advantages, but it concentrates risk.

• Vendor lock‑in: The deeper public services embed Microsoft APIs, managed services and operational practices, the harder and costlier it becomes to switch. Lock‑in isn’t always malicious; it can be the accidental result of efficiency choices.
• Data sovereignty and control: While major cloud providers offer data‑region guarantees and compliance controls, political questions remain when core services and AI tooling are provided under foreign corporate governance regimes. For sensitive government data, legal clarity about access, incident response and jurisdiction matters.
• Single‑point target for attacks: Centralising services can create high‑value targets. A successful breach in a core identity service, for instance, can propagate widely.
• Supply‑chain risk: Reliance on a small number of global platform providers increases exposure to geopolitical supply disruptions and market dynamics.

Mitigations require a deliberate architecture: hybrid cloud strategies, robust identity and encryption models, multicloud redundancy for critical services, and contractual protections around data portability and exit support.

---

Procurement behaviour: aggregation vs competition, and the role of CCS​

CCS argues SPA24 achieves scale discounting and better procurement terms across the public sector. Aggregation can be effective — but it also creates incentives to preserve established providers.
Key procurement questions:

• Are aggregated competitions structured to include credible non‑Microsoft alternatives, including hosted open source offerings and managed services?
• Do procurement frameworks require suppliers to provide data portability and detailed exit plans to preserve future options?
• Does CCS track and publish centralised, granular spend figures with Microsoft so Parliament and taxpayers see where money is going?

The current decentralised model — individual departments driving the final procurement — mixes benefits (local control) and risks (inconsistent negotiating leverage and lack of visibility).

---

Security assessments and AI: is Copilot in government a bridge too far?​

Including Microsoft Copilot in SPA24 is a material change: Copilot is an AI assistant that processes text, files and code to generate outputs. AI introduces new data‑handling issues:

• Prompt leakage risks: Sensitive inputs typed into an AI assistant can be logged or used to train models depending on contract terms.
• Model provenance and explainability: Determining the origin of AI outputs, hallucinations, or bias becomes difficult in mission‑critical contexts.
• Regulatory compliance: Public bodies must ensure AI services meet public‑sector standards for privacy, accessibility and fairness.

Any adoption of Copilot‑style services should require specific contractual clauses on data use, model training exclusions, rigorous red teaming, and an approved risk assessment. Where such clauses are not ironclad, AI adoption increases the case for cautious, staged pilots rather than wholesale rollouts.

---

Practical migration strategies: how the UK could realistically increase FOSS usage without chaos​

• Map and Categorise:
• Inventory all Microsoft‑dependent workloads.
• Categorise by business criticality, integration complexity, and migration difficulty.
• Tiered approach:
• Low‑hanging fruit: Replace standalone, non‑integrated desktop productivity clients and document formats where interoperability is high.
• Medium complexity: Migrate file servers, non‑messaging collaboration, and standard web apps to open source foundations with managed support contracts.
• High complexity: For heavy integration points (identity services, mission‑critical systems), invest in adapters, rewrite schedules, and hybrid models that gradually de‑couple core dependencies.
• Build an “exit playbook”:
• Mandatory contractual exit clauses in all frameworks.
• Standardised data export formats and identity federation steps.
• Financial reserves for transition costs.
• Invest in skills and change management:
• Targeted training to reduce productivity loss.
• Funding for technical teams that know both Microsoft and FOSS toolchains.
• Use competitive procurement to force price discipline:
• Require vendors to bid for slices of the estate, not only as resellers.
• Encourage managed open source vendors and SaaS providers into aggregated competitions.

These steps turn an ideological argument into a staged, risk‑managed programme focused on value.

---

Balance — not binary choice: pragmatic hybrid procurement​

The best outcome is rarely full replacement or full entrenchment. Instead, a mixed architecture and procurement policy can achieve fiscal prudence and operational resilience:

• Preserve Microsoft where it delivers unique value (e.g., specific enterprise‑grade integrations, large‑scale Azure capabilities tied to platform services).
• Use open source where it provides parity or superior economics (e.g., Linux server stacks, database engines, container orchestration, standard web platforms).
• Require all large‑scale procurements to present a “no‑regret” argument for vendor choice that includes TCO modelling and exit planning.

This hybrid approach reduces single‑vendor risk while avoiding expensive, disruptive, and politically fraught “big‑bang” migrations.

---

Governance and transparency: what the Cabinet Office and Parliament should demand​

• Central visibility: A single, searchable register of major software and cloud contracts, values and renewal dates should be maintained. This enables Parliament and audit bodies to assess concentration risk and value.
• Standardised ROI/TCO templates: Departments should publish consistent TCO assessments for any project likely to change platform choices.
• Independent gatekeeping for large migrations: Any programme projected to cost more than a defined threshold should require independent review and a formal gateway approval with public reporting.
• Public interest clauses in MOUs: MOUs involving national infrastructure should include clauses protecting data portability, audit rights and explicit exit support.

These changes would increase accountability and make it harder for a single arrangement to entrench unintended costs.

---

Strengths and risks: a critical appraisal​

Strengths of staying with Microsoft under SPA24:

• Rapid onboarding with a single large supplier reduces integration risk for some cross‑department initiatives.
• Central discounts and aggregated buying can deliver immediate price relief for departments that lack procurement scale.
• Deeply integrated managed services, single‑sign‑on ecosystems, and AI tooling can accelerate some digital transformation programmes.

Risks and downsides:

• High long‑term licence spend with limited central oversight increases budgetary exposure.
• Vendor lock‑in constrains future policy flexibility and negotiating leverage.
• AI and cloud services introduce data‑use and sovereignty concerns that demand strict contractual guardrails.
• Overreliance on a single supplier may suppress competition and reduce innovation from smaller providers and the open source community.

Some claims circulating in public debate are less verifiable: precise five‑year totals will change with adoption patterns, renewals, and the extent to which departments use SPA24 versus bespoke procurements. Public statements by CCS and government ministers are authoritative on the structure of SPA24 and observed spend to date; projections beyond that are estimates that should be treated as planning assumptions not fixed commitments.

---

Recommendations: how to save money without breaking services​

• Enforce a central spend register and publish regular, departmental Microsoft‑spend dashboards.
• Require exit and portability terms in every framework and aggregated competition.
• Prioritise open‑source pilots in areas where migration costs are low and interoperability is mature.
• Negotiate AI‑specific privacy and non‑training clauses for any generative AI service used by public bodies.
• Establish a multi‑year “migration fund” to pay for the upfront costs of moving suitable workloads to open alternatives where TCO modelling shows net savings within 3–5 years.
• Drive competition in aggregated competitions by explicitly inviting bids from managed‑open‑source providers, multicloud offerings, and hybrid solutions.
• Publish TCO studies for the top 10 Microsoft‑dependent systems and require independent verification before large renewals.

---

Conclusion​

The question is not whether the UK government should categorically abandon Microsoft — in many cases doing so would be impractical and expensive — but whether the public sector should complacently accept a decade of rising licence bills and increased dependency without a credible countervailing plan. SPA24 delivers scale and convenience, and it can accelerate AI and cloud adoption. Yet the fiscal scale of the arrangement — the equivalent of multiple billions of pounds over a parliamentary term — demands rigorous oversight, transparent accounting, and an active strategy to introduce competition and open source where it reduces total cost and increases resilience.
A responsible middle path is available: combine disciplined procurement, hardened contractual protections, visible spend tracking and targeted open‑source migration projects that together reduce long‑term exposure while preserving operational continuity. That approach gives the UK government the best chance of getting value for taxpayers, maintaining technical sovereignty, and avoiding the worst effects of vendor lock‑in — without exposing frontline public services to sudden, expensive disruption.

---

Source: theregister.com Should UK.gov save money by using Microsoft's FOSS rivals?