Legacy modernization
Modernizing software you cannot switch off
The system still runs the business. That is the problem — it cannot be paused, and the people who built it have gone. Modernization is a sequence of survivable steps, not a rewrite.
In short
Legacy modernization is the staged replacement of a system that the business still depends on, done without an outage and without a full rewrite. The usual approach is to put a facade in front of the old system, move one capability at a time behind it, and keep both running until the last consumer has moved. A full rewrite is the option that fails most often, because it restarts a clock that has already been running for years and rediscovers every requirement the original team learned the hard way.
When it applies
Signals this is the work
If more than one of these is true today, the problem is usually further along than it looks from the outside.
Nobody will touch one module
There is a part of the codebase everyone routes around. Changes there are quoted in weeks and estimated nervously.
The vendor is gone, or the version is
The framework is out of support, the hosting is end-of-life, or the original supplier no longer exists.
Integration is the bottleneck
Every new tool needs a custom bridge, because the old system exposes nothing a modern product expects.
Reporting happens in spreadsheets
The data is in there, but getting it out reliably means someone exporting and reconciling by hand.
Onboarding takes months
New engineers cannot be productive because the knowledge is in people, not in the code or the documentation.
How we do it
The sequence
- 01
Map what it actually does
Not what the documentation claims. We trace the real behaviour, including the undocumented rules that someone added for one customer in 2014 and that the business now depends on.
- 02
Find the seams
Modernization is only survivable where the system can be cut. We identify the boundaries where a capability can be lifted out without dragging the rest with it.
- 03
Put a facade in front
New consumers talk to an interface, not to the old system. That lets the thing behind it change without every caller changing at the same time.
- 04
Move one capability at a time
Each step ships, runs in production alongside the old path, and is reversible. Nothing is a point of no return.
- 05
Migrate the data honestly
Legacy data is never as clean as anyone expects. The cleanup is scoped as its own piece of work rather than discovered mid-cutover.
- 06
Decommission deliberately
The old path is switched off only when nothing is calling it, and the check for that is evidence rather than confidence.
What we will not do
The refusals
- Recommend a rewrite because the code is unfashionable. Old is not the same as broken.
- Modernize a module nobody uses, because it is the easy one to start with.
- Move to microservices to solve a problem that was never about deployment topology.
- Promise a cutover date before the data quality is known.
Questions
Before you ask
Tell us what isn't working.
One process, one system, one decision you are stuck on. We will come back with how we would approach it, what it would take, and whether it needs building at all.