Legacy System Modernisation
Legacy modernisation replaces a system in defined pieces, each with a demonstrable result, while the business keeps running on it. Big-bang rewrites fail for a reason that does not change: the old system contains undocumented rules nobody can restate.
Replacing a system nobody can switch off
The systems that need modernising are the ones too central to stop. They run payroll, or dispatch, or invoicing, and they have accumulated fifteen years of rules — some deliberate, some accidental, almost none documented. The people who wrote them have left.
That is why rewrites fail. A rewrite specified from documentation and interviews reproduces the system people believe exists, and the difference between that and the system that actually runs is discovered in production, by customers.
So the first deliverable is behaviour captured from the running system: inputs, outputs, edge cases, and the rules that only appear at month end. Only then is it possible to say what replacement means, and to carve the work into pieces that each end with something in production.
What a modernisation engagement covers
Six workstreams, sequenced so the business never loses a working system.
Behaviour capture
What the system actually does, established from code, data, logs and observed transactions rather than from documentation and recollection — including the edge cases that only surface at period end.
Sequencing
The estate divided into pieces that can be replaced independently, ordered by risk and dependency, each defined so that it ends with something running in production.
Strangler implementation
New components placed in front of or alongside the old system, taking over one responsibility at a time, with traffic moved deliberately and reversibly.
Data migration and reconciliation
Data moved with an auditable reconciliation, so that any disagreement between old and new is detected by a report rather than by a customer.
Parallel running
Both systems processing the same work for an agreed period, with differences investigated and exit criteria defined before the period starts.
Decommissioning
A plan for switching the old system off, including what is retained read-only for statutory or audit reasons — because an undecommissioned legacy system continues to cost money and attention.
How a modernisation runs
Capture behaviour
The running system observed and documented, with the rules nobody could restate written down and validated against real transactions.
Sequence the work
Independent pieces identified and ordered by risk, each with a definition that ends in production rather than in a milestone.
Carve off the first piece
The highest-risk-and-value component replaced first, behind a facade, with traffic moved gradually and reversibly.
Run in parallel
Old and new processing the same work, differences reconciled and investigated, with agreed exit criteria rather than a date.
Decommission
The old component switched off, with retained read-only access where statutory requirements demand it.
Modernisation approaches compared
Why incremental replacement is the default and when the others apply.
| Dimension | Incremental (strangler) | Big-bang rewrite | Lift and shift |
|---|---|---|---|
| Business risk | Low, reversible per piece | High, concentrated at cutover | Low |
| Time to first value | Weeks | At the end | Weeks |
| Handles undocumented rules | Yes, discovered per piece | Poorly | Not applicable |
| Total duration | Longer | Shorter on paper | Shortest |
| Improves the system | Progressively | Potentially | No |
| Right when | The system must stay live | Small and well understood | The constraint is hosting |
What we will not agree to
We will not run a modernisation where no stage can be defined as ending in production. If a piece of work cannot produce something running and judgeable, it is too large, and we resequence it rather than accepting a plan whose only checkpoint is the end.
We also will not modernise a system the business has already decided to replace with a package. Where a standard product genuinely covers the need, rebuilding bespoke software is the more expensive answer, and the assessment that establishes which is true belongs before this engagement rather than inside it.
- Capture what the system actually does before deciding what replacement means.
- Every stage must end with something running in production.
- Parallel running needs exit criteria, not an end date.
- An undecommissioned legacy system keeps costing money; plan the switch-off.
Questions buyers ask about this
Rewrite or refactor?
Usually neither, at first. We capture behaviour, carve off the highest-risk component, and decide on that piece with evidence about what the code actually does. Answering the question at whole-system level, before that evidence exists, is how both wrong answers get chosen.
How do you avoid a two-year project with nothing to show?
Every stage ends with something running in production. If a stage cannot be defined that way, it is too big and we resequence it before starting. That constraint makes the total duration longer than a rewrite plan claims and shorter than a rewrite actually takes.
What is the strangler pattern?
New components are placed in front of or alongside the legacy system and take over one responsibility at a time, with traffic routed to the new path gradually. The old system shrinks until it can be switched off. The advantage is that every step is reversible and the business always has a working system.
How long should parallel running last?
Until agreed exit criteria are met — typically a defined number of processing cycles with reconciliation differences at zero or explained — rather than until a date passes. Ending a parallel run because the date arrived is how undetected divergence reaches production.
What happens to the data?
It is migrated with an auditable reconciliation, so that any disagreement between old and new is caught by a report you can inspect. Where statutory retention applies, the old system is usually retained read-only for a defined period rather than switched off entirely, and that is planned rather than discovered.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.