Modernising a citizen-facing service for a UK central government department

Context and constraints

The department operated a citizen-facing digital service that processed a high volume of applications and status enquiries every working day. The front end had been refreshed several times over the years, yet the system of record remained a mainframe back end that few people in the organisation still understood in depth. Batch windows governed when data could be updated, which meant that a citizen who submitted information in the morning often could not see it reflected until the following day. For a public service that people rely on at stressful moments in their lives, that lag was more than an inconvenience: it generated avoidable contact, eroded trust, and created a steady stream of corrections that case workers had to handle manually.

The constraints were significant and, in our experience, typical of the sector. The service could not go dark; citizens depended on it continuously, and there was no acceptable maintenance window long enough to perform a single large cutover. Accessibility was a legal and ethical requirement rather than an aspiration, so any new interface had to meet the relevant standard and be tested with assistive technologies and with real users who had access needs. Spending was subject to scrutiny and to the GOV.UK Service Standard, which meant we had to demonstrate user research, iterative delivery, and a credible plan for operating the service sustainably rather than simply shipping a replacement and walking away.

Finally, the knowledge risk was acute. The mainframe encoded decades of policy logic, some of it undocumented and some of it visible only in the behaviour of the code. Retiring it safely meant understanding not just what the system did, but why, so that we did not quietly drop a rule that protected a vulnerable group or change an outcome that had legal weight. We treated that discovery work as a first-class activity rather than a preamble.

The approach in depth

We began with a discovery phase grounded in the Service Standard. That meant talking to citizens, case workers, and the operational teams who lived with the existing service, and mapping the real journeys rather than the idealised ones described in old documentation. We deliberately resisted the urge to design the target architecture before we understood demand, failure modes, and the edge cases that consumed most of the operational effort. The most expensive parts of a public service are usually the exceptions, not the happy path, and the legacy system handled those exceptions through a mixture of code, spreadsheets, and institutional memory.

From discovery we moved to a strangler approach. Rather than rebuilding the whole platform and attempting a single switch, we placed a routing and integration layer in front of the mainframe and began carving out capabilities one at a time. Each capability we extracted was reimplemented on a modern, cloud-hosted stack with its own data store, its own tests, and its own observability, while the routing layer decided whether a given request should be served by the new component or passed through to the legacy back end. This let us deliver value early, reduce risk per release, and keep a clear rollback path at every step.

Delivery phases and sequencing

We sequenced the work to retire risk in the right order. The first phase concentrated on read-only journeys: letting citizens check status and view their own information through a new, accessible interface that read from the mainframe via the integration layer. This delivered a visible improvement quickly, exercised the integration plumbing under real load, and gave the team confidence before we touched anything that wrote data.

The second phase tackled the write paths, starting with the highest-volume and best-understood transactions. Here we introduced an event-driven pattern so that updates captured in the new components could be reflected to citizens promptly while still being reconciled with the system of record. We ran the old and new paths in parallel for a period, comparing outputs to build evidence that the new logic matched the legacy behaviour before we let it become authoritative. The final phases addressed the long tail of complex cases and the eventual decommissioning of the mainframe components, by which point the integration layer was routing the overwhelming majority of traffic to the new platform.

Sequencing was a continuous conversation with the business, not a fixed plan. As we learned more about demand and risk, we reprioritised, and because each slice was independently deployable, reordering the backlog did not require expensive replanning.

Architecture and technology decisions and trade-offs

We chose a cloud-hosted, container-based platform with managed services where they reduced operational burden, and we kept the architecture deliberately boring in the places that mattered most. The integration layer used well-understood patterns rather than anything exotic, because it sat on the critical path and needed to be transparent to operate. For data, we favoured giving each new capability ownership of its own store, which improved isolation and let teams evolve independently, accepting in exchange the need for clear contracts and reconciliation between services.

One important trade-off concerned consistency. The legacy batch model offered a kind of simplicity: everything was consistent once a day. Moving to near-real-time updates meant embracing eventual consistency in places, which we managed with idempotent processing, careful event design, and reconciliation jobs that detected and surfaced divergence rather than hiding it. We also invested early in observability, structured logging, tracing, and meaningful dashboards, because a distributed service is only as operable as its telemetry.

Measurable outcomes

We are careful not to overstate results, and the precise figures belong to the department, but the direction of travel was clear and consistent with what we typically see on engagements of this kind. Citizens received up-to-date information without waiting for an overnight batch, which reduced avoidable contact and the rework that followed it. The accessible interface passed independent testing and performed reliably under seasonal peaks that had previously caused concern. Operationally, the move to managed cloud services and clearer telemetry reduced the effort spent firefighting and made cost more predictable and easier to attribute to demand.

• Near-real-time status updates replaced overnight batch delays for citizens.
• An accessible front end meeting the relevant standard, validated with assistive technology users.
• A clear rollback path preserved at every release through the strangler routing layer.
• Reduced avoidable contact and case-worker rework on high-volume journeys.
• Improved resilience during seasonal peaks with autoscaling and better observability.
• A credible, documented plan for sustainable in-house operation after handover.

Lessons learned

The first lesson is that discovery is not optional in this setting. The temptation to treat a modernisation as a straightforward rewrite is strong, but the value and the risk both live in the details of exception handling and policy logic. Time spent understanding those details paid for itself many times over, and the parallel-running comparison gave everyone the confidence to retire legacy behaviour without anxiety.

The second lesson is that small, reversible steps beat heroic cutovers. By keeping each slice independently deployable and preserving a rollback path, we turned a frightening replatforming programme into a series of manageable releases. The third lesson concerns people: investing in handover, documentation, and shared ownership meant the department was not left dependent on us, which is the proper outcome for public money. We treated capability transfer as part of the delivery rather than an afterthought.

Talk to us about a similar engagement. Email sales@halfteck.com.