Legacy software modernisation
When an old system still runs the business, but changing it has become the risk.
I help businesses replace or modernise legacy operational software in controlled stages, keeping the useful business logic and removing the parts that are fragile, opaque or hard to hand over.
Problem diagnosis
The risky part is usually not age. It is dependency.
- The system still works, but nobody is confident about changing it.
- A former employee, contractor or small supplier understands the important logic better than the current team.
- The business has newer tools around the old system, but the old system remains the source of truth.
That creates slow change, operational risk, awkward reporting and a quiet fear that one unavoidable update could break the process the business relies on.
Responsibility
Modernisation starts with finding what must not be lost.
I do not start by rebuilding everything. I start by mapping the workflow, data, edge cases and business rules that still matter, then choosing the smallest safe stage that reduces risk.
What I would build
The first useful version would be concrete.
- 01
A map of the current system
Screens, records, integrations, reports, manual workarounds and known failure points are turned into something the business can reason about.
- 02
A replacement path in stages
The first build targets one valuable, bounded part of the system rather than pretending the whole estate can be replaced in one leap.
- 03
Preserved business rules
The logic people rely on is made explicit before it is rebuilt, tested or retired.
- 04
Safer data movement
Important records are exported, checked and reconciled before the new system depends on them.
- 05
A handover pack
Setup, dependencies, access, rollback notes and operating instructions are written so another competent person could take over.
Fit filter
Probably right, probably not.
Probably right when…
- The old system runs a commercially important process.
- People are afraid to change it because the logic is not clear.
- You want a controlled modernisation or replacement, not emergency support.
Probably not me when…
- You need vendor support for a current product.
- You want a broad enterprise programme with committees and managed delivery.
- The issue is a one-off bug in someone else’s maintained system.
First step
Start with diagnosis, not a big commitment.
The first step is system archaeology: what does this system actually do, what depends on it, and what would make replacement safe?
£150 per hour plus VAT where applicable. Two hours minimum for new clients. No retainer, no minimum term, no lock-in. You own everything I build.
Useful things to send before a call
- Screenshots or a walkthrough of the current system
- Known failure points and risky changes
- Exports or schemas if available
- Reports and processes that must keep working
Objections
Questions this page should answer before you email.
Do we have to replace everything?
No. A staged path is usually safer, especially when the current system contains years of business knowledge.
Can you work with poor documentation?
Yes, but the first stage must make unknowns visible. Hidden logic is a project risk, not something to wave away.
What if the old system should stay for now?
Then the useful output may be a risk map, backup plan, change boundary and a later replacement sequence.
Next step
If this looks like your problem, send me the awkward bits.
The useful first email is short: what is breaking, what product or process cannot handle it, and what working would need to mean.