HMCTS Azure Platform as a Product: Self-Service, Governed AI, Faster Releases

HM Courts & Tribunals Service has become one of the clearest public-sector examples of what happens when a large, complex organisation stops treating platform engineering as plumbing and starts treating it as a product. In a new Microsoft customer story published this week, HMCTS describes how it worked with Kainos on Microsoft Azure to support an estimated 700 developers with self-service tooling, reusable components, and governed AI services. The reported gains are striking: 74 percent of platform operations demand now resolves autonomously, deployment lead times have been cut from around 120 hours to as little as 1–4 hours, and deployment frequency has improved by 4,900 percent. (microsoft.com)

Background​

HMCTS sits at the centre of the justice system in England and Wales, with responsibilities spanning criminal, civil, family and tribunal services. That makes its technology estate unusually consequential: when a digital service fails, the impact is not just technical inconvenience but delay in access to justice. Microsoft’s case study notes that HMCTS has been on a 10-year modernisation journey designed to move casework away from paper and toward a digital model that can increase capacity and efficiency. (microsoft.com)
That modernisation effort has been formal, expensive, and long-running. The Ministry of Justice’s 2024–25 annual report says the HMCTS reform programme formally concluded in the financial year 2024–25, after investing over £1.2 billion since 2016 in modernising courts and tribunals. The same report frames digital capability as a strategic risk area for the department, underscoring that this is not a side project but core public infrastructure. (assets.publishing.service.gov.uk)
The scale of the transformation helps explain why a conventional team-by-team DevOps model eventually hit limits. Microsoft says HMCTS grew to an estimated 700 internal developers across digital transformation projects, and as complexity rose, the development platform became a bottleneck. That is a familiar story in enterprise IT, but in a justice context the stakes are higher because delays ripple into hearings, case progression, and service quality for citizens and legal professionals alike. (microsoft.com)
HMCTS’s earlier digital work also showed how deep the appetite for change had become. A 2024 THINK Digital Partners profile of the organisation described Common Platform on Azure Cloud as a system designed to integrate government agency and police force systems, support case management and progression, and serve thousands of court hearings per day. The same article said the criminal courts service had already been rolled out across 100 percent of criminal courts in England and Wales. (thinkdigitalpartners.com)
This matters because the latest story is not a fresh start. It is the next layer in a long-running public-sector rebuild that has moved from “get services online” to “make the development machine itself sustainable.” In that sense, the new platform engineering model is less about one application and more about whether HMCTS can keep scaling digital justice without drowning its teams in repetitive operational work. (microsoft.com)

Overview​

The headline shift is architectural as much as organisational. HMCTS and Kainos moved away from a traditional “DevOps by team” model toward a platform-as-a-product strategy, where shared tools, APIs, documentation, support and environments are centrally designed and exposed through self-service. That turns the platform from an invisible cost centre into a managed internal product with users, feedback loops and a roadmap. (microsoft.com)

Why the old model broke down​

At small scale, team-based DevOps can work well because the people building a service also own much of the infrastructure around it. At HMCTS scale, though, that model creates duplication, conflicting patterns and friction every time a new team or service comes online. The Microsoft story is explicit that the platform was failing to provide rapid feedback loops at scale, and that contention increased as teams, moving parts and demand grew. (microsoft.com)
That bottleneck effect has a compounding cost. If every team has to repeat environment setup, infrastructure work or governance steps, then the system rewards persistence more than speed. In public service delivery, that can quietly turn into a productivity tax across hundreds of developers and dozens of service lines. The larger the programme, the more expensive every unnecessary repetition becomes.

Why the “product” framing matters​

Treating the platform as a product changes incentives. A product has users, service levels, onboarding, support and continuous improvement, whereas an internal utility often becomes “everyone’s problem and no one’s priority.” Kainos’s approach, as described by Microsoft, was to create a scalable model with APIs, tools, documentation, education and support as deliberate components rather than afterthoughts. (microsoft.com)
That framing also helps explain the “golden path” idea referenced in the case study. Kainos identified the most popular and effective services already used across HMCTS and used that evidence to shape a standard path for developers to follow. In practical terms, that means fewer bespoke choices, fewer unsupported variants and more predictable outcomes. (microsoft.com)

The Azure foundation​

Microsoft says the team chose Azure for speed, flexibility and a broad set of services across networking, containers, storage, caching, AI and databases. That is a classic cloud-native rationale, but in this setting it also matters because public-sector organisations need a platform that can carry both legacy modernisation and future AI adoption without forcing a second migration later. (microsoft.com)
The Microsoft customer story also makes clear that Azure AI Foundry and Azure OpenAI were brought in under a governed framework, not as free-roaming experimentation. That distinction is critical. In regulated or mission-critical environments, AI is only useful if it is wrapped in controls that preserve auditability, security and responsible use. (microsoft.com)

What Changed Operationally​

The most visible effect of the new model is that HMCTS turned platform support into a largely self-service experience. Microsoft says an AI agent now handles an average of 74 percent of platform operations demand autonomously, with only 13 percent of requests reaching the service desk. That is not a marginal optimisation; it is a structural reduction in operational friction. (microsoft.com)

The AI support layer​

The support agent is integrated into developers’ existing Slack workflows and linked to JIRA, Azure OpenAI, a curated knowledge base, Cosmos DB and Azure AI Search. That combination is important because it shows the organisation did not merely bolt on a chatbot; it embedded retrieval, workflow and governance into a service pathway developers already use. (microsoft.com)
The practical effect is better self-resolution. Instead of waiting on platform operations for every question or permission issue, developers can get guided signposting, resolve common problems faster and keep moving. In a large development organisation, that can save far more time than the ticket numbers alone suggest, because the hidden cost is usually context switching. Less waiting means less interruption, and less interruption means more code actually ships.

Copilot as an accelerator, not a substitute​

Microsoft also says HMCTS uses GitHub Copilot across the engineering function, with Kainos reporting improvements of up to 60 percent in time spent on certain tasks. The important nuance is that the tooling is augmenting developers rather than replacing them. In a justice system context, that is the only sensible approach: AI can compress routine effort, but human accountability still has to anchor the final product. (microsoft.com)
There is also a subtle cultural benefit here. When engineers see AI tools remove low-value work, they are more likely to treat the platform as something that helps them succeed rather than a governance layer that slows them down. That matters because internal adoption is often the difference between a promising platform and a platform people work around.

The developer support problem​

Microsoft says the development teams were generating around 6,000 platform operations service tickets each year. That is an enormous amount of support traffic for infrastructure questions, access issues and workflow friction. By moving the first line of support into an intelligent self-service layer, HMCTS has reduced demand on human operators and freed them to focus on the exceptions that actually require judgement. (microsoft.com)
The broader lesson is that platform engineering only pays off when the organisation converts abstraction into usability. If the shared platform is hard to consume, teams will keep reinventing their own tools. But if the platform is easy, reliable and faster than the alternative, standardisation stops feeling imposed and starts feeling rational.

Measurable Performance Gains​

The claimed performance improvements are eye-catching, but they make the most sense when viewed as outputs of an organisational redesign rather than isolated metrics. The Microsoft story says lead time for deployment fell by 3,000 percent and deployment frequency improved by 4,900 percent using DORA metrics. That signals a dramatic shift in release confidence, not just a speed boost. (microsoft.com)

How to read the numbers​

A 3,000 percent improvement sounds enormous because it is. In practice, it implies that workflows which once took days can now be executed in hours. The customer story elsewhere says deployment lead time moved from around 120 hours to as little as 1–4 hours in some cases, which gives the headline some concrete shape. (get.kainos.com)
Deployment frequency rising by 4,900 percent tells a similar story. More releases usually mean smaller batches, tighter feedback loops and less risk concentrated in any single change. In a public-sector environment, that is especially valuable because service improvements can reach users sooner without waiting for large, high-risk release trains. (microsoft.com)

Why speed is not the whole story​

It is tempting to treat faster deployments as the main win, but the more important gain is consistency. If teams can use standardised paths, governed tooling and reusable components, then quality tends to improve as speed rises. That is because the platform absorbs repetitive engineering work and leaves more of the team’s cognitive load for business logic and service design.
That also helps explain the reported cost savings. The THINK Digital Partners article cites an estimated £14.7 million in annual savings from efficiency gains. That figure should be treated as a vendor- and partner-reported estimate rather than an independently audited public accounting line, but it still suggests that standardisation has moved from theory into budget impact. (microsoft.com)

The hidden efficiency story​

The deeper savings are likely to come from reduced duplication, faster onboarding and less operational sprawl. Every reused component lowers the total cost of maintenance because fewer teams are building, securing and updating near-identical bits of infrastructure. In that sense, the platform does not merely make developers faster; it makes the organisation less fragile.

• Fewer duplicated environments
• Less repetitive infrastructure work
• Faster onboarding for new teams
• More predictable governance
• Reduced support ticket load
• Better developer morale

Governance, Security and Responsible AI​

In public justice technology, every efficiency win has to survive the scrutiny of governance. That is why the way HMCTS has introduced AI is at least as important as the fact that it has done so. Microsoft says Azure AI Foundry was used to enable controlled, safe and governed adoption of AI services within HMCTS’s responsible AI framework. (microsoft.com)

Why governance is not optional​

Justice systems deal with sensitive case data, professional users, citizen information and legal process constraints. A careless AI rollout could create disclosure risks, misinformation, or workflow confusion. A governed rollout, by contrast, can give developers access to useful capabilities while keeping the organisation inside approved boundaries. (microsoft.com)
That matters especially because AI is often most persuasive when it is embedded invisibly into daily workflows. The problem is that invisible AI can also be hard to audit. HMCTS appears to have avoided that trap by pairing AI with curated knowledge, search, workflow tooling and platform controls.

Why Azure matters here​

Azure’s value in this scenario is not simply compute or storage. It is that Microsoft can offer a stack broad enough to support networking, containers, databases, AI and developer tooling in one operating model. That reduces the temptation to assemble a patchwork of vendor tools with inconsistent policy enforcement. (microsoft.com)
The platform also aligns with the broader Microsoft strategy of pushing AI into governed, enterprise-ready environments. That is important because public sector buyers increasingly want innovation without surrendering oversight. In that respect, HMCTS is not just a customer story; it is a template for how Microsoft wants regulated industries to adopt AI.

The human factor​

The customer story repeatedly emphasises developer experience, which is the right emphasis. Governance that slows every request to a crawl tends to drive shadow IT; governance that makes the safe path the easiest path tends to win. The HMCTS case suggests the latter approach is being pursued intentionally. (microsoft.com)
There is a broader public-service implication too. When the platform is easy to use, developers are less likely to waste time on infrastructure wrangling and more likely to spend time on services citizens actually notice. That is the real promise of platform engineering in government: not just better IT, but better throughput for public value.

Public-Sector Delivery and Citizen Impact​

For citizens, the value of this kind of platform work is usually indirect but substantial. People do not see deployment pipelines or AI ticket deflection, but they do notice when services are more reliable, forms are easier to use and case progress is less dependent on manual back-office effort. HMCTS’s reform programme was always about turning that invisible machinery into something faster and more accessible. (assets.publishing.service.gov.uk)

Access to justice as a technology outcome​

The Ministry of Justice’s annual report explicitly frames the reform programme as part of the department’s effort to deliver swifter justice and a beacon for the rule of law. That is notable because it confirms digital transformation is being judged not only by technical delivery but by systemic outcomes. (assets.publishing.service.gov.uk)
In practice, a better platform can support more frequent releases, quicker fixes and more consistent service behaviour across criminal, civil and tribunal domains. That does not eliminate the complexity of justice administration, but it does make the digital side less of a drag on operations.

Enterprise versus consumer-style impact​

Unlike a consumer app, HMCTS does not win by delight alone. It wins when users can complete legal and administrative tasks accurately, professionally and on time. That means the benefits of platform engineering often show up as fewer delays, less duplication and less friction between systems that used to be siloed.
The Microsoft story notes that the “golden path” helped eliminate unnecessary silos and consolidate development into a unified tech stack. That is exactly the sort of hidden architecture work that enables better public outcomes even when the citizen-facing surface changes slowly. (microsoft.com)

What this means for other departments​

The HMCTS model is likely to resonate across government because it addresses a universal problem: too many teams, too much repetition, not enough standardisation. Departments that are still managing bespoke infrastructure for every service will recognise the appeal immediately. The challenge, of course, is whether they have the leadership discipline to adopt the same model instead of defending local exceptions.

The Role of Kainos​

Kainos is the quiet engine in this story, and that matters. The company is not merely implementing cloud resources; it is shaping the operating model that determines how developers behave. That is a much more strategic role than the usual system-integration brief. (kainos.com)

From delivery partner to platform architect​

The Microsoft story describes Kainos as designing the platform engineering model and treating each element of the platform as a product with product owners. That approach reflects a mature understanding of how internal platforms succeed: they need ownership, roadmaps and a user experience that teams actually prefer. (microsoft.com)
Kainos has also been publicly linked to HMCTS for years, including a 2022 success story about applying product thinking to speed up justice reform. That long relationship likely mattered because platform transformation is not a one-off install; it is a sustained exercise in organisational trust and technical iteration. (kainos.com)

The partner ecosystem effect​

The wider lesson is that public-sector cloud transformation increasingly depends on partners who can blend engineering depth with product thinking. It is not enough to know Azure services or DevOps tools in isolation. The real value comes from knowing how to package those capabilities into a developer experience that scales across teams and programmes.
That is where Kainos appears to have differentiated itself. The story suggests it was not just an implementer but a translator between HMCTS’s operational reality and the platform discipline required to modernise it. In a programme of this size, that translation layer is often the difference between adoption and drift.

The business model shift​

For integrators, this kind of work is also commercially meaningful. Platform engineering creates more durable relationships than one-off project delivery because the platform itself becomes a continuing product. That aligns the partner’s incentives with long-term performance rather than short-term implementation milestones.

• Longer customer engagement cycles
• Higher switching costs
• More recurring optimisation work
• Stronger productisation of services
• Better alignment with cloud consumption
• Greater opportunity for AI enablement

Competitive Implications​

HMCTS may be a public body, but the competition story is still real. The deeper Microsoft and Kainos embed Azure into justice operations, the more difficult it becomes for alternative platforms to displace that stack in future programmes. That is especially true when the organisation has already standardised around containers, databases, AI services and GitHub-based workflows. (microsoft.com)

Microsoft’s strategic gain​

For Microsoft, the win is not just a reference customer. It is proof that Azure can underpin a complex, highly regulated, AI-enabled internal developer platform at government scale. That strengthens Azure’s narrative against AWS and Google Cloud in the kind of account where credibility matters as much as raw feature count.
The inclusion of Azure AI Foundry is especially telling. Microsoft is positioning AI not as a bolt-on but as part of an enterprise operating fabric that can be governed from the start. That message will resonate with public-sector buyers who want innovation without improvisation. (microsoft.com)

What rivals have to answer​

Competitors will need to show they can deliver the same combination of developer autonomy, governance and rapid AI enablement in similarly regulated environments. It is one thing to promise cloud-native agility; it is another to make that agility safe enough for justice, health or financial services.
That means the bar is no longer just infrastructure performance. It is the total quality of the internal platform experience: self-service, documentation, observability, policy controls and AI support. In that sense, HMCTS is a benchmark for the whole market, not just for government.

Why this is more than a Microsoft win​

The broader industry lesson is that platform engineering is becoming a competitive differentiator in its own right. Organisations that treat the developer platform as a first-class product will iterate faster and scale more cleanly than those that leave teams to solve the same problems repeatedly. That is true in government, and it is increasingly true everywhere else.

Strengths and Opportunities​

The strongest feature of the HMCTS model is that it connects technology change to operational value instead of treating transformation as a vanity metric. It reduces friction for developers, creates a clearer support model, and gives the organisation a repeatable way to scale digital justice services. The opportunity now is to turn those gains into a durable capability that survives beyond any single programme or vendor relationship.

• Developer productivity improves when shared services replace repeated infrastructure work.
• Operational support becomes more scalable when AI handles common platform requests.
• Governance is easier when the platform offers a standard path rather than many bespoke ones.
• Release velocity improves when teams can deploy through self-service and reusable components.
• Service quality benefits from more frequent, smaller, less risky changes.
• AI adoption becomes safer when it is embedded in controlled, enterprise-grade workflows.
• Public value grows when digital justice services can scale without excessive manual overhead.

Risks and Concerns​

The biggest concern is that the reported gains, while impressive, are still partner- and vendor-reported rather than independently audited in the public materials we have. That does not make them invalid, but it does mean readers should treat the percentage improvements as directional evidence of success rather than as a final financial account. A second concern is whether the model remains manageable as more services, users and AI use cases are added.

• Metric inflation risk if percentage improvements are not read alongside absolute baselines.
• Vendor dependence if too much operational knowledge resides in the partner ecosystem.
• Governance drift if AI use expands faster than policy and oversight can mature.
• Platform lock-in if internal standards become too closely tied to one cloud stack.
• Cultural resistance if teams that prefer autonomy see standardisation as central control.
• Data quality issues if AI and automation are asked to do too much with inconsistent inputs.
• Sustainability questions if savings depend on continued adoption rates and not just initial rollout.

Looking Ahead​

The real test for HMCTS is no longer whether it can modernise in principle. The formal reform programme has already concluded, the digital services are in place, and the platform engineering model appears to have delivered material operational gains. The next challenge is whether HMCTS can keep the platform healthy while expanding digital services, adopting more AI and reducing reliance on legacy patterns that still lurk in the background. (assets.publishing.service.gov.uk)
That will require the organisation to keep doing the boring things well: maintain the golden path, keep the self-service experience useful, preserve strong governance, and avoid letting the platform fragment again as new demands emerge. It will also require honest measurement. If the savings and speed gains hold, HMCTS will have one of the strongest public-sector platform engineering case studies in Europe. If they fade, the lesson will be just as important: scale is easy to promise, but only disciplined product thinking makes it last.

• Sustaining the golden path across more teams and services
• Expanding AI use without weakening responsible AI controls
• Keeping platform support lightweight as demand grows
• Measuring whether claimed savings persist over time
• Preventing new silos from forming around special cases
• Translating engineering wins into visible citizen benefits

HMCTS now has a more credible answer to one of the hardest questions in digital government: how do you let hundreds of developers move quickly without losing control? The answer, at least for now, is a platform built as a product, governed as a public service, and scaled with enough automation to make the old way of working look increasingly uneconomic.

---

Source: THINK Digital Partners In the Spotlight: HMCTS | THINK Digital Partners : THINK Digital Partners