Section303
Case study
Modernizing a public-sector service without a big-bang rewrite
A legacy public service moved onto a modern, accessible platform while it stayed in service.
Government technology / Software architecture / Cloud & infrastructure
Problem
A government service ran on an ageing system that was hard to change, hard to secure and hard to use on a phone. Residents still depended on it every day, so switching it off to rebuild was not an option.
Constraints
- Continuous public availability
- Accessibility (WCAG) and security review as release gates
- Procurement and hand-over: the agency team must own the result
- Legacy data that could not be migrated in one step
Architecture & approach
Put an API facade in front of the legacy system, then replace one journey at a time behind it. New services run as containers on AWS, provisioned with Terraform, and ship through a pipeline with automated accessibility and security checks.
- Web app to API facade
- API facade to New services
- API facade to Legacy system
- New services to PostgreSQL
- Legacy system to Legacy data
- New services to Legacy data (sync)
Key decisions
How do we replace a system the public relies on daily? 303-3.1
What stack will the agency own after we leave? 303-3.2
Outcome
- Resident journeys moved to the new platform one at a time, with the service up throughout
- Accessibility and security checks built into every release
- Infrastructure and runbooks handed over to the agency team
Technology
Python / Django, React, AWS ECS, RDS PostgreSQL, Terraform, CI/CD, WCAG accessibility
Lessons & tradeoffs
- In government, hand-over is the product. Design for the team that inherits it.
- A facade turns one terrifying migration into a series of boring releases.