By use case
Legacy Modernisation
Change the engine without stopping the car
Usually owned by
- Engineering
- CTO office
- Operations
- 18 mo
- Typical programme, value each quarter
- 0
- Big-bang rewrites we recommend
- 10x
- Release frequency on modernised paths
Rather than one big-bang cutover
They have a well-documented failure rate
The change
What actually differs afterwards
Not a maturity model. The concrete difference in how the work happens.
Today
- One monolith nobody wants to deploy
- The only person who understands it is close to retirement
- Releases quarterly, and each one is an event
- No test coverage, so no safe way to change anything
- Vendor support ending on a component you depend on
Afterwards
- Highest-risk capabilities extracted and independently deployable
- Behaviour captured in tests before anything is rewritten
- Weekly releases for the modernised paths
- Legacy core wrapped in a documented API layer
- A sequenced plan with value arriving each quarter
Why big-bang rewrites fail
The plan is eighteen months. At month fourteen the new system does 70% of what the old one does, the business has kept asking for changes to the old one, and both are now being maintained by a team that has stopped enjoying its job.
This is not a failure of skill. It is arithmetic: a system that has accumulated fifteen years of edge cases encodes more requirements than anyone can enumerate up front.
Strangling instead
Rewrite
- Freeze features and rebuild everything
- One cutover date for the whole system
- Value arrives at the end, if it arrives
- Requirements gathered from documentation
Incremental extraction
- Extract one capability at a time behind a facade
- A sequence of small, reversible cutovers
- Value arrives every quarter
- Behaviour captured from the running system and its tests
Traffic for one capability is routed to the new implementation behind a facade. The old path stays available until the new one is proven. Repeat. The legacy core shrinks until what remains is small enough to either replace or leave alone deliberately.
The first deliverable is tests
Before extracting anything, we capture what the system currently does — characterisation tests, written against actual behaviour rather than intended behaviour. This routinely documents bugs that downstream systems have come to depend on, which is exactly the class of surprise that derails rewrites.
Sequencing by risk
The order is driven by risk and coupling, not by what is most interesting to build. Anything with an end-of-support date or a single point of human knowledge goes first, because those are the items where the cost of waiting is real and rising.
What the database usually reveals
The code tells you what the system was designed to do. The database tells you what it actually does, and the two disagree more often than anyone expects.
Columns named for one purpose and reused for another after a project in 2016. A status value that appears in production but in no enumeration anywhere in the source. Two tables that should have a foreign key between them and do not, with the relationship maintained by application logic that no longer runs consistently.
Reading the schema and profiling the actual data early is one of the cheapest ways to find out what you are dealing with. It routinely reprices the programme, and it is better to reprice in week three than in month nine.
The knowledge problem
The technical risk on these programmes is usually manageable. The person risk often is not.
If one person is the only one who understands a system that runs the business, that is a live operational exposure regardless of whether you modernise. It gets worse quietly — they take less leave, they become the escalation for everything, and the retirement date approaches.
Extraction work is one of the few reliable ways to convert that knowledge into something durable, because it forces the behaviour into tests and documentation as a by-product of the work rather than as an initiative someone has to be nagged about. Where that person exists, we would start sooner than the technical case alone suggests.
What we would leave alone
Not every legacy system is a problem. A component that is stable, understood, cheap to run and not blocking anything is doing its job, and modernising it converts a working system into a project with risk attached.
The honest test is whether anything is actually constrained by it — release frequency, a compliance obligation, a hiring problem, an end-of-support date, or a capability the business needs and cannot have. If nothing is, "leave it, deliberately, and write down why" belongs in the plan as a decision rather than as an omission. Revisit it when one of those constraints changes.
Where this shows up by sector
- Financial services — core banking peripheries and reporting systems, usually with the integration surface as the first problem to solve.
- Manufacturing — plant systems and the bespoke tooling built around an ERP over two decades.
- Logistics — transport management systems and the partner integrations layered onto them.
- SaaS and technology — the monolith that shipped the company to Series B and is now the reason releases are quarterly.
FAQ
Questions we get asked
Should we just rewrite it?
Almost never. A full rewrite means two systems to maintain, a feature freeze nobody honours, and a delivery date that moves. Incremental extraction is slower on paper and finishes considerably more often.
There are no tests. How do you change anything safely?
Characterisation tests first — capture what the system currently does, including behaviour that is arguably wrong but that something downstream depends on. Those tests are the safety net that makes the rest possible, and building them is genuinely the first deliverable.
Nobody understands the system. Can you work with that?
It is the normal starting point. We reconstruct behaviour from the code, the database, production traffic and whoever is still around, and we document as we go. The documentation is a deliverable, not a side effect.
What gets extracted first?
Something with a clear boundary, real business value, and low coupling — often reporting, notifications or a specific integration. The first extraction proves the pattern and builds the scaffolding the rest reuses.
What does a first engagement cost and how long does it take?
Six to eight weeks to characterise the system, agree the sequence and complete the first extraction. That first slice is deliberately modest, because its job is to prove the pattern and build the deployment and testing scaffolding the rest reuses. The full programme is typically eighteen months with something delivered each quarter, and we would rather commit to the first slice and re-scope than quote eighteen months of unknowns as though they are known.
A vendor built it and will not hand over the source. Now what?
Then the options narrow to wrapping rather than extracting, at least initially. An API layer or integration facade in front of the vendor system gets you interoperability and lets you build new capability alongside it, without touching what you cannot see. It is a worse position than owning the code and worth improving through the contract if you can. Where the vendor is also end-of-support, the commercial conversation is usually more urgent than the engineering one.
The business will not stop asking for changes during an eighteen-month programme.
Correct, and any plan that assumes otherwise will fail. This is the main argument for incremental extraction over a rewrite — there is no feature freeze to break, because the legacy system stays live and changeable throughout. Changes to a capability already extracted go to the new implementation. Changes to one still in the monolith go where they always did. Nobody has to be told no for a year.
Can we modernise and move to cloud at the same time?
Sometimes, and often you should not. Doing both at once means that when something breaks you cannot tell which change caused it, and the debugging cost usually exceeds whatever was saved by combining them. The sequence that tends to work is to lift the system to cloud roughly as it is, stabilise, and then extract — or extract first and deploy each new component to cloud as it emerges. Both are defensible. Doing them simultaneously to one component rarely is.
How do we keep this funded when nothing visible ships for months?
By making sure something visible ships, which is a sequencing decision rather than a communications one. We pick a first extraction with a user-facing or cost-visible outcome even when a more architecturally satisfying candidate exists, because a programme that cannot show progress at the two-quarter mark tends not to reach the third. If your sponsor changes, an eighteen-month programme with no delivered value is the first thing their successor cancels.
Let's find out what is actually automatable
Bring a process that annoys you. In 30 minutes we will tell you whether AI helps, what it would cost, and where it would fail — even if the answer is don't bother.
Or email [email protected] · we reply within 1 business day