One person understands it
There is a name everybody says when it breaks. That name is your single point of failure, and eventually they retire.
✦ Legacy modernisation
Legacy software modernisation without the big-bang rewrite
The system still works. That is exactly the problem - it works well enough that replacing it feels reckless, and badly enough that it costs you every week. We replace legacy systems in stages, with the old one running until the new one has earned the traffic.
✦ Symptoms
Signs your system has become a liability
The vendor has gone quiet
No updates, no roadmap, support that is really one contractor. Nobody is fixing the next security problem.
It can't be reached remotely
It only runs on machines in one building, so anything flexible about how your team works stops at the door.
Nothing integrates with it
Data comes out as a CSV somebody emails around, if it comes out at all.
Changes are refused
A small change is quoted at an absurd number or declared impossible, so the business bends around the software.
It runs on unsupported infrastructure
An operating system or database version that no longer receives security patches. This is the one that turns into an incident.
✦ Options
Four routes, honestly compared
| Route | What it involves | When it's right |
|---|---|---|
| Leave it alone | Do nothing, keep it running, plan for later. | It is stable, supported and not blocking anything. Sometimes the right answer. |
| Wrap it | Put an API around it and build new interfaces on top. | The core logic is sound but it is closed off and hard to use. |
| Replace in stages | Move one process at a time onto new software, old system alive alongside. | Most cases. Lowest risk and value arrives early. |
| Full rewrite | Build the replacement, cut over in one move. | Rarely - only for small, well-understood systems. Big-bang rewrites are where projects die. |
✦ Method
The staged approach
1
Understand what it actually does
Including the undocumented rules encoded in it over twenty years. Some of them are the business; some are bugs everyone adapted to.
2
Get the data out and understood
Extract, profile and clean. Legacy data is always messier than anyone expects, and finding that out early is the whole game.
3
Pick the first slice
One process, valuable enough to matter and self-contained enough to move safely. It proves the approach with real users.
4
Run both systems in parallel
New system live for that slice, old one still running. Outputs compared until the numbers match and people trust it.
5
Repeat, then retire
Slice by slice until the legacy system holds nothing anyone needs, then archive it properly so history is not lost.
✦ Data
Your data is the part that must not be lost
Twenty years of records is often the most valuable asset in the building. Migration is not a copy: it is profiling, cleaning, deduplication, mapping to a sane structure and validating that the new system produces the same answers as the old one.
We keep an immutable archive of the original data regardless of how the migration goes, and we agree the reconciliation checks - record counts, financial totals, spot-checked records - before we cut anything over.
✦ Questions we get asked
Legacy modernisation questions
Can you work with our old system if we've lost the source code?
Usually. We can work from the database, the screens, the outputs and the people who use it. It costs more in discovery, but no source code is not a dead end.
How long can we run both systems in parallel?
As long as it takes to trust the new one - typically weeks per slice. Running both costs a little more for a period, and it is the cheapest insurance in the project.
What about our twenty years of historical data?
It comes with you. Active records migrate into the new system; older history is either migrated or kept in a queryable archive, depending on what you actually need to reach and how fast.
Our team is used to the old system. Will they cope?
That is a design constraint, not an afterthought. We involve the people who use it daily during scoping, keep familiar terminology, and train before cutover rather than after.
Is it cheaper to just keep patching it?
Sometimes, and we will tell you if so. The point where it stops being cheaper is usually unsupported infrastructure or a change the business needs and the system refuses to allow.
Tell us what isn't working. We'll tell you what we'd build.
Thirty minutes. Bring the process, the systems it touches and the deadline. You'll leave with an approach and an honest answer on whether custom software is the right call.
No pitch deck · We map your process · You own the software