HM Courts & Tribunals Service (HMCTS) has retooled its development platform with Kainos and Microsoft Azure, turning a slow, paper‑centric modernization programme into a developer‑friendly, AI‑enabled platform engineering practice that the organization says has dramatically reduced service friction, automated much of the Platform Operations intake, and accelerated delivery across more than a dozen digital services.
HMCTS runs the criminal, civil and family courts and a wide range of tribunals across England and Wales. Over the course of a multi‑year Reform Programme it moved from paper workflows to 14 new digital services and processed millions of digital cases—all while scaling a developer population that now numbers in the hundreds. The Reform Programme is explicitly framed as a long‑term modernization of the justice system, with digitalisation intended to improve access, speed and sustainability.
As HMCTS expanded its in‑house development activity, the organization discovered that the platform developers used had become a bottleneck: contention for environments, slow feedback loops and inconsistent toolchains were hurting throughput. In response, HMCTS selected Kainos—an established Azure delivery partner—to reframe the platform as a product, build a “golden path” of supported services, and embed Azure‑native tools (including Azure AI Foundry and Azure OpenAI) plus GitHub Copilot into developer flows. The Microsoft customer story outlines both the design intent and headline outcomes of that engagement.
This article examines what HMCTS, Kainos and Microsoft built, verifies the key technical claims against independent sources, evaluates strengths, and identifies real operational and governance risks public‑sector organisations should weigh when attempting similar transformations. It also offers practical takeaways for IT leaders planning platform engineering and AI‑enabled DevOps at scale.
Key characteristics include:
While the numbers are compelling, they should be read with context: they are reported by the vendor and customer, and represent internal measurements tied specifically to HMCTS’s workflows and knowledge base. That said, the architecture (Copilot + Azure OpenAI + RAG + searchable knowledge store) mirrors modern patterns used in other large public and private sector transformations and is technically consistent with Azure’s documented capabilities.
At the same time, the model highlights three enduring trade‑offs that any public body must handle deliberately: (1) the balance between velocity and auditability when using generative AI; (2) cloud dependency versus portability; and (3) the operational and cultural investment required to sustain platform outcomes over the long term.
For other public sector organisations considering a similar trajectory, the pragmatic path is clear: start small, measure diligently, govern strictly, and treat the platform like a product that developers love to use. That combination—technology plus culture—makes the difference between a modern platform that accelerates delivery and a fragmented set of services that merely replicate existing inefficiencies in the cloud.
HMCTS’s reported outcomes are impressive and align with broader DORA‑based expectations for platform‑led transformation, but readers should remember these are measured within a specific organisational context. The technical architecture and governance model HMCTS and Kainos implemented provide a real, replicable blueprint—yet the results will depend on local baselines, regulatory constraints and long‑term commitment to operational discipline.
Conclusion
HMCTS’s platform renewal with Kainos and Microsoft Azure illustrates how modern platform engineering—paired with pragmatic, governed AI—can unlock developer productivity at scale and support large digital reform programs in highly regulated environments. The reported metric improvements are startling and, where verified by public documentation, plausible given the scale of automation and process change. Public sector IT leaders will find in HMCTS a detailed case study of what works: opinionated platforms, developer advocacy, infrastructure‑as‑code, measured DORA metrics, and cautious, auditable AI use. The caveat remains that strong governance, FinOps discipline and an explicit strategy for portability and auditability are non‑negotiable when courts and tribunals handle sensitive, legally protected information.
Source: Microsoft HM Courts & Tribunals Service elevates DevOps with Kainos and Microsoft Azure | Microsoft Customer Stories
HMCTS runs the criminal, civil and family courts and a wide range of tribunals across England and Wales. Over the course of a multi‑year Reform Programme it moved from paper workflows to 14 new digital services and processed millions of digital cases—all while scaling a developer population that now numbers in the hundreds. The Reform Programme is explicitly framed as a long‑term modernization of the justice system, with digitalisation intended to improve access, speed and sustainability. As HMCTS expanded its in‑house development activity, the organization discovered that the platform developers used had become a bottleneck: contention for environments, slow feedback loops and inconsistent toolchains were hurting throughput. In response, HMCTS selected Kainos—an established Azure delivery partner—to reframe the platform as a product, build a “golden path” of supported services, and embed Azure‑native tools (including Azure AI Foundry and Azure OpenAI) plus GitHub Copilot into developer flows. The Microsoft customer story outlines both the design intent and headline outcomes of that engagement.
This article examines what HMCTS, Kainos and Microsoft built, verifies the key technical claims against independent sources, evaluates strengths, and identifies real operational and governance risks public‑sector organisations should weigh when attempting similar transformations. It also offers practical takeaways for IT leaders planning platform engineering and AI‑enabled DevOps at scale.
Why HMCTS changed course: the problem statement
Before platform reform, HMCTS ran into classic scale‑and‑speed problems:- A large and growing internal developer base (estimated ~700 developers) with diverse needs.
- Legacy on‑premises case management and manual processes that hindered iteration.
- A platform that could not give fast feedback at scale, causing contention and delivery delays.
The Kainos + Azure approach: platform as a product
Five pillars that shaped the platform
Kainos deployed a platform-as-a-product approach rooted in five strategic pillars: Educate, Evolve, Security, Self‑service, and Optimize. The strategy combines toolchain standardisation (the “golden path”), documentation and education, automated CI/CD, infrastructure as code, and observability driven by DORA‑style metrics. The goal: create a friction‑free, repeatable developer experience that teams choose to adopt rather than being forced to use.Key characteristics include:
- Curated, opinionated stacks and reusable templates (the golden path).
- Everything‑as‑code: IaC, pipeline-as-code, and configuration-as-code.
- Developer‑first UX: self‑service provisioning, on‑call playbooks and ChatOps.
- Observability and performance measurement using DORA metrics for lead time, deployment frequency and quality.
Technical building blocks
Kainos and HMCTS chose Azure as the foundation and stitched together a suite of managed services:- Azure Kubernetes Service (AKS) for container orchestration.
- Azure Front Door, Azure Firewall and virtual networks for secure application delivery.
- Azure Postgres, Cosmos DB and Azure Cache for Redis for state and caching.
- Azure AI Foundry and Azure OpenAI for controlled access to generative AI and agentic workflows.
- Azure AI Search (cognitive search) and retrieval‑augmented generation (RAG) patterns for knowledge retrieval.
- GitHub, GitHub Copilot, and CI/CD orchestration integrated into pipelines.
- Monitoring and logging via Azure Monitor/Log Analytics and application insights.
AI in the platform: Azure AI Foundry and developer agents
A distinguishing element of the HMCTS program is the integration of AI into core developer workflows, with two notable patterns:- GitHub Copilot for developer assistance (improving coding and automation productivity).
- An AI‑driven ChatOps agent that automates Platform Operations service‑desk intake, using Azure OpenAI, RAG and a curated knowledge base (Cosmos DB + Azure AI Search).
While the numbers are compelling, they should be read with context: they are reported by the vendor and customer, and represent internal measurements tied specifically to HMCTS’s workflows and knowledge base. That said, the architecture (Copilot + Azure OpenAI + RAG + searchable knowledge store) mirrors modern patterns used in other large public and private sector transformations and is technically consistent with Azure’s documented capabilities.
Measured outcomes: what changed, and how dramatic are the numbers?
HMCTS and Kainos report major improvements:- Platform Operations service‑desk autonomous handling: 74% on average; only 13% escalate to humans.
- DORA‑style performance improvements: Microsoft reports a 3,000% reduction in lead time for deployment and 4,900% improvement in deployment frequency as measured using the platform’s DORA metrics.
- Reuse and consolidation across services—teams following the golden path reduced siloes and simplified operations.
What worked: strengths and best practices
- Developer‑centric design. Treating the platform as a product—complete with product owners, documentation and measurable outcomes—changes the relationship between platform teams and service teams. It creates voluntary adoption rather than enforced use, which drives scale and consistency.
- Opinionated "golden path." Providing an approved stack of services, reusable templates and example pipelines reduces cognitive load, shortens onboarding, and makes compliance simpler. This is a core tactic in modern platform engineering.
- Automation and self‑service. Automating routine provisioning, testing and environment lifecycle removes handoffs and reduces lead time—matching DORA recommendations for continuous delivery and deployment.
- Measured governance (DORA metrics). Explicit measurement of lead time, deployment frequency and quality lets HMCTS quantify progress and focus investments where they matter. Using industry metrics also aligns technical work with business outcomes.
- Pragmatic AI adoption via RAG and knowledge‑driven agents. Starting with a narrow, well‑curated knowledge base (service‑desk tickets, runbooks, common fixes) makes the AI agent performant and auditable while minimising hallucination risk.
Risks, caveats and governance considerations
Modernising courts is not the same as modernising a commercial web app. HMCTS operates in a highly regulated domain with sensitive case data, strict compliance demands, and a public interest mandate. Several risk vectors deserve attention.- AI governance and auditability. Using Azure OpenAI and Copilot inside production workflows demands strict guardrails: policies on what prompts can access what data, explicit logging of model inputs/outputs, human‑in‑the‑loop checkpoints for production changes, and clear rules about model retraining and telemetry. HMCTS integrated Azure AI Foundry to provide controlled adoption, but public sector teams must still invest heavily in AI governance and explainability.
- Vendor lock‑in. The platform’s tight integration with Azure PaaS services, AKS and GitHub tooling accelerates delivery but increases dependence on a single cloud ecosystem. If multi‑cloud portability is a requirement, teams must build abstraction layers and avoid embedding business‑critical logic in proprietary services without migration plans. This trade‑off is explicit in other migration guidance and should be addressed in procurement.
- Measurement nuance. Dramatic percentage improvements (3,000% lead‑time reduction; 4,900% deployment frequency increase) are meaningful but need contextualisation: what were baseline measurement methods, how were deployments counted, which services were included, and over what time period? These metrics are best used for trend tracking and prioritisation rather than as raw, comparable KPIs across organisations.
- Security and data residency. Court systems often handle personally identifiable information (PII) and legally privileged content. Any use of AI must constrain sensitive data movement, avoid external model training unless explicitly permitted, and comply with data protection laws. Azure offers secure enclaves and compliance certifications, but architecture and contracts must be explicit about data flows.
- Cultural and skills gaps. Platform engineering and cloud‑native practices require different skills than traditional system administration. The programme included education and developer enablement, but long‑term success depends on continuous upskilling and careful role design (platform engineers, SREs, product owners).
- Overreliance on agentic automation. Using agentic tools for code transformations or automated remediation can speed work but increases risk if not subject to robust CI validation and staged rollouts. Other practitioners have warned about preview‑status features and the importance of test coverage before applying automated fixes.
Operational and financial implications
Adopting a cloud‑native platform and embedding AI has predictable cost and operational effects:- Shorter lead times and more frequent deployments reduce time‑to‑value but can increase consumption of ephemeral environments, CI minutes, and AI inference costs.
- A FinOps posture is essential: tagging, cost allocation, rightsizing, platform chargeback or showback, and business‑led environment scheduling will control run rate while preserving developer velocity.
- HMCTS and Kainos explicitly reference FinOps practices and cost optimisation as part of ongoing operations; organisations embarking on similar projects should budget for both migration and sustained platform operations.
Lessons and practical checklist for public sector adopters
- Start with outcomes, not tools. Define the citizen or business outcomes (reduced case processing time, fewer in‑person visits, faster triage) and map which technical changes materially move those needles.
- Treat the platform as a product. Assign product owners, publish roadmaps, measure adoption, and iterate based on developer feedback.
- Build a golden path—but make exceptions possible. Offer an opinionated stack for most teams and clear extension points for specialist cases.
- Measure with DORA metrics—but standardise definitions. Agree on how deployments and lead times are counted and automate metric collection so numbers are comparable over time.
- Pilot narrow AI use cases first. Start with curated knowledge bases (service‑desk, runbooks) and human‑in‑the‑loop flows before expanding AI into high‑risk areas. Maintain logs and access controls for all AI interactions.
- Bake security and compliance into the stack. Use managed services that meet required certifications, but validate contracts and data flow diagrams to prevent inadvertent data exposure.
- Invest in FinOps and operations playbooks. Define environment lifecycles, cost allocation, and automated shutdown schedules for non‑production resources.
- Be explicit about vendor boundaries. If portability is important, capture abstractions at the IaC and API level and avoid embedding business logic in provider‑specific managed services without a migration strategy.
Independent validation and context
- The HMCTS program and Kainos’ multi‑year partnership are documented on HMCTS and Kainos public pages that describe the Reform Programme and the platform work. These pages confirm the move to Azure, the use of Power Platform in some services, and the platform engineering approach.
- Microsoft’s customer story contains the specific outcome metrics quoted in this piece (AI agent handling 74% of interactions, 3,000% lead‑time reduction, 4,900% deployment frequency improvement, Copilot time savings). These are vendor‑published case metrics and represent HMCTS’s own deployment results.
- DORA (Accelerate) reports and independent summaries provide benchmarks that show elite performers can achieve transformational improvements in deployment frequency and lead time, supporting the plausibility of HMCTS’s results when moving from legacy, low‑velocity baselines to an automated, opinionated platform. However, DORA benchmarks vary across reports and the exact multiplicative improvements depend heavily on baseline state and measurement conventions. Use the DORA context to interpret HMCTS’s percentages rather than as a one‑to‑one comparison.
- Community and technical forum commentary (internal workshop notes and community archives provided in project files) reinforce that the behavioural and cultural shifts—the “developer experience” and productized platform operations—are the critical enablers of measurable performance gains in public sector platforms. These community artifacts reiterate the emphasis on education, product metrics and developer advocacy.
Final analysis: opportunity, pragmatism and what to watch next
HMCTS’s project is a strong example of how platform engineering, automation and carefully governed AI can transform public sector delivery. The program’s strengths are its developer‑first product thinking, the pragmatic use of Azure managed services, and a staged, measurable approach to AI adoption that began with targeted service‑desk automation.At the same time, the model highlights three enduring trade‑offs that any public body must handle deliberately: (1) the balance between velocity and auditability when using generative AI; (2) cloud dependency versus portability; and (3) the operational and cultural investment required to sustain platform outcomes over the long term.
For other public sector organisations considering a similar trajectory, the pragmatic path is clear: start small, measure diligently, govern strictly, and treat the platform like a product that developers love to use. That combination—technology plus culture—makes the difference between a modern platform that accelerates delivery and a fragmented set of services that merely replicate existing inefficiencies in the cloud.
HMCTS’s reported outcomes are impressive and align with broader DORA‑based expectations for platform‑led transformation, but readers should remember these are measured within a specific organisational context. The technical architecture and governance model HMCTS and Kainos implemented provide a real, replicable blueprint—yet the results will depend on local baselines, regulatory constraints and long‑term commitment to operational discipline.
Conclusion
HMCTS’s platform renewal with Kainos and Microsoft Azure illustrates how modern platform engineering—paired with pragmatic, governed AI—can unlock developer productivity at scale and support large digital reform programs in highly regulated environments. The reported metric improvements are startling and, where verified by public documentation, plausible given the scale of automation and process change. Public sector IT leaders will find in HMCTS a detailed case study of what works: opinionated platforms, developer advocacy, infrastructure‑as‑code, measured DORA metrics, and cautious, auditable AI use. The caveat remains that strong governance, FinOps discipline and an explicit strategy for portability and auditability are non‑negotiable when courts and tribunals handle sensitive, legally protected information.
Source: Microsoft HM Courts & Tribunals Service elevates DevOps with Kainos and Microsoft Azure | Microsoft Customer Stories