National Care Records Service Modernisation

Executive summary

The National Care Records Service (NCRS) gives health and care workers secure access to national patient information, surfacing more than 57.5 million Summary Care Records and over 60 million Personal Demographics Service records to clinicians, pharmacists, dentists and optometrists. NHS England wanted to rearchitect the front end around microfrontends to scale product delivery, but first the service had to be lifted out of another team’s AWS platform and into new accounts owned by the new team.

Doza was engaged to provide the infrastructure technical leadership for that move. Between November 2025 and July 2026 we untangled the existing infrastructure, rebuilt it as standalone Terraform with automated pipelines, built it to the NHS red lines - NHS England’s mandated engineering standards - and cut live traffic over to it with no downtime and no incidents. The microfrontend rearchitecture is now underway.

The challenge

NCRS is a critical national service. Clinicians make prescribing and treatment decisions with it, so an outage isn’t an inconvenience - it’s a patient safety problem. Any migration had to be provably safe before it touched real users.

The starting position made that difficult. The service wasn’t a standalone system: it was embedded inside a wider platform owned by a different team, with its infrastructure tangled up in that platform’s Terraform. That team weren’t part of the migration project, and the team that owned NCRS owned the application rather than the platform underneath it.

The tooling predated current engineering practice. Deployments ran through bash scripts with no test coverage. There were no deployment pipelines, and releases went out on the wider platform’s fixed two-weekly window rather than when the team was ready. The Terraform was hard-coded to a fixed set of environments, so standing up anything new meant editing code rather than changing config. And monitoring was dashboard-based and reactive. It depended on someone looking, it didn’t span every component, and it had no visibility of AWS’s own metrics. Nothing raised its hand when something went wrong.

The NHS red lines move as well. They’re raised continually, particularly around CI/CD security practices and the ability to recover an account or system quickly, so the new platform had to be built to the current bar rather than the one the service was originally built against.

Moving accounts also cost the service access it had previously relied on. It could no longer reach a reference data set it depended on, and it could no longer ship logs to the Splunk instance it had always used. Both needed solving before cutover, not after.

Approach and methodology

Team composition

A rainbow team of engineers from several consultancies working alongside NHS England’s permanent staff: around ten application developers and testers, and two infrastructure engineers.

We took the infrastructure technical lead: owning the migration plan and building it - the Terraform, the pipelines, the alerting and the cutover - then making sure the team could run it without us.

Untangling the existing infrastructure

The first job was archaeology. We worked through the wider platform’s Terraform to establish which resources actually belonged to NCRS, then extracted them into their own modules and repositories. With the Terraform extracted, we built new GitHub Actions pipelines to deploy it, replacing the bash scripts entirely.

We also introduced PyInvoke to wrap development, deployment and maintenance work in self-describing, testable commands. That was a deliberate choice for the people, not just the code: a named command says what it does on the face of it, in a way a shell script never surfaces. The commands are deployment-environment agnostic too, so if NHS England ever want to move from GitHub to AWS build tooling, the day-to-day interface doesn’t change.

Environments as configuration

We reworked the Terraform so adding an environment is a config change rather than a code change. That unlocked the environment estate the service needed:

• Four Path to Live (PTL) environments, including production
• A dedicated non-functional test environment
• Two development and CI environments
• On-demand ephemeral environments, created for every pull request

The pull request environments let us integrate automated tests into the pipeline for the first time, so changes are now exercised in a real environment before anyone reviews them.

Observability from scratch

We built a new Amazon Data Firehose delivery pipeline to get logs into the new Splunk instance, and adapted the existing dashboards to match.

Then we added the proactive alerting the service had never had. CloudWatch alarms roll up into composite critical and warning alarms per component, firing into Slack with the metrics and a link to the runbook. Tech Ops liked it for the usability: everything needed to start diagnosing is in the notification, and the composite roll-up means one incident produces one message rather than a storm.

A cutover nobody noticed

We went live in two stages. First a shadow deployment: the new production environment was gated to a chosen set of users and invisible to everyone else. Only once they were happy did we open it up.

Then a percentage-based redirect to the new URL, on newly registered domains in Route 53, moving a small proportion of traffic first and ramping up rather than betting the service on a big bang switch. Blue/green container deployments were already in place and we kept them.

Traffic moved across through July 2026 with no downtime and no issues.

Making ourselves unnecessary

Operating procedures and system dependencies are documented in Confluence, and we worked directly with the developers to get them running the release pipelines themselves. The measure of success was always that releases would keep happening without us.

Results and outcomes

A safe migration of a critical service

The migration completed in July 2026 with no downtime and no incidents. NCRS now runs in AWS accounts owned by the team responsible for it, with the infrastructure defined in Terraform they control.

Capability the service didn’t have before

In November 2025 there was no deployment pipeline, no way to test a change in a dedicated environment, and no alerting. All three now exist:

• Every pull request gets an ephemeral environment and an automated test run
• Releases go out through a pipeline the developers run themselves, on their own schedule rather than a fixed two-weekly window
• Security, performance and health events in AWS raise alerts instead of waiting to be noticed

That last one paid for itself early. The new alarms surfaced a memory leak - exactly the kind of slow climb a dashboard won’t reveal.

Capability in the team, not just the platform

The team began the engagement owning the application and nothing underneath it. They now run both. Releases, new infrastructure and changes to the pipelines are handled by the developers themselves.

The rearchitecture is unblocked

The successful migration of NCRS improved the team capability and unblocked the rearchitecture work that allows NHS England to scale NCRS development and improve it faster. Better views and more features mean improved experiences for clinician staff and better care for patients.