Chapter 1 · About 5 minutes
Modernising legacy
Most organisations do not get to start again. They have systems that work, mostly, but cost more each year to keep alive and are slow to change.
- Legacy system
- Software that still does an important job but has become difficult, risky or expensive to change — often because knowledge, suppliers or technology have moved on.
Why “big bang” replacement is risky
Replacing a whole system in one go means a long period with nothing new in users’ hands, followed by a single high-stakes switchover. When it goes wrong, it tends to go wrong in public.
We prefer to replace systems piece by piece, so that each part is proven with real users before the next one starts.
In practice
An illustrative example: a council’s permit system might keep its existing database while a new online application form is built in front of it. Once the form is stable, the back-office screens follow, and finally the old database is retired.
Understanding what you have
Before changing anything we map the current system: what it does, who uses it, where data flows and which parts are fragile. This usually involves reading code, talking to the people who run it, and watching how staff actually use it.
- Strangler pattern
- A way of modernising where new components gradually take over functions from the old system until the old system can be switched off.
Keeping the service running
Every step should be reversible. We aim for small releases, automated tests around the old behaviour before it is changed, and monitoring so problems show up early.
Things to have ready
Access to existing documentation (however out of date), a contact who knows how the current system is operated, and an honest view of what is already known to be broken.
What you receive
A clear map of the current estate, a sequenced plan for replacement, and working software released in increments — with the knowledge transferred to your team as we go.