Legacy software rescue & modernisation
The engagement for a production system nobody dares change — assessed, stabilised, and modernised in that order, by one senior team throughout.
Last updated:Legacy software rescue is the work of making an inherited or failing production system safe to run and safe to change: first stabilising whatever could take the business down, then modernising the system incrementally rather than replacing it wholesale. Revenant Systems runs legacy software rescue as one engagement — assessment, stabilisation, and modernisation — with the same senior in-house team across all three.
When does a system need rescuing?
A system needs rescuing when the risk of changing it has grown larger than the cost of leaving it alone. The signals are concrete: releases have become rare and frightening, the people who built it have gone, dependencies have passed end of life, and nobody has tested a restore from backup recently enough to be sure it works.
Revenant Systems tests the recovery path by exercising it rather than by reading the runbook — on a system this old the two rarely match.
- Releases are rare because every release is risky
- The original developers have left
- Dependencies or runtimes are past end of life
- Backups exist but restores are untested
- Documentation no longer matches the running system
How does a legacy rescue engagement run?
A legacy rescue runs in three stages, in order: assessment, to establish what is actually at risk; stabilisation, to get the system deploying and recovering reliably; and modernisation, to bring down the cost of every future change. Each stage is scoped and priced separately, so the engagement can stop at any boundary once the business is out of danger.
The assessment stage is also sold on its own as a fixed-price package, so a business can buy the diagnosis before committing to the treatment.
| Stage | Question it answers | Output | Published price |
|---|---|---|---|
| Assessment | Where is the risk? | Risk register and first-90-days plan | From £6,500 |
| Stabilisation | Can we run it safely? | A working deploy, backup, and restore path | Typically £15,000–£45,000 |
| Modernisation | Can we change it safely? | Incremental strangler-fig migration | Typically £40,000–£150,000+ |
UK company and contracting entity · UK GDPR-aware delivery · Independent — nothing to resell · Reports written for your team to act on
Rewrite, or modernise incrementally?
Modernising incrementally is the lower-risk route for a system the business depends on daily, because the existing system keeps serving traffic while replacement components take over one route at a time. A full rewrite is justified when the current system cannot meet a requirement at all — a hard compliance deadline, or a runtime whose vendor has withdrawn support.
Revenant Systems has no platform of its own to migrate you onto, so which of the three routes gets recommended is settled by the assessment rather than before it.
| Route | Fits when | Main risk |
|---|---|---|
| Incremental (strangler fig) | The system runs the business daily and must stay up | Two systems to maintain during the transition |
| Targeted rewrite of one component | One part is the bottleneck and its boundary is clean | The boundary is rarely as clean as it looks |
| Full rewrite | The system cannot meet a hard requirement at all | Feature parity takes longer than anyone forecasts |
Who does the rescue work?
Revenant Systems is a UK software consultancy working as a small, senior, in-house team: whoever runs the assessment stays to do the stabilisation. On legacy work that matters more than it does on a greenfield build, because much of what an assessment produces is context the assessor carries afterwards, and a hand-off throws that away.
Revenant Systems is led by Ian Compton, whose twenty years of engineering covers high-throughput production systems — platforms processing billions of events a month — and the operational work of keeping them running.
Which systems can Revenant rescue?
Revenant Systems covers current runtimes and the ones most firms have stopped taking on. Go, Node.js, Python, PHP, and .NET on the modern side; Visual Basic 6, VBA, Delphi, FoxPro, and Lotus Notes on the older side. The databases and cloud estates underneath come with them — SQL Server, PostgreSQL, and MySQL, on AWS, Azure, or Google Cloud.
Ian Compton has worked firsthand across that range, from VB6 and VBA through to .NET and the current server-side stacks, so old code is read directly rather than described second-hand by whoever inherited it.
- Current runtimes: Go, Node.js, Python, PHP, .NET
- Desktop and 4GL era: Delphi, FoxPro, Visual Basic 6
- Office-embedded logic: VBA macros, Lotus Notes applications
- Relational databases: SQL Server, PostgreSQL, MySQL
- Cloud and on-premise infrastructure: AWS, Azure, Google Cloud
What if the legacy system is a spreadsheet?
Often it is. In smaller companies the business-critical system is frequently an Excel workbook with VBA behind it, or a pairing: an ageing application that never quite did enough, and the workbook someone built to cover the gap. Revenant Systems assesses the two together, because separating them hides where the working logic actually sits.
The fixed-price Excel workbook audit covers the spreadsheet half of that pairing, analysing formulas and macros mechanically rather than by reading through them.
- A workbook with VBA macros running a core process
- An ageing application plus the workbook that patches it
- Month-end reporting rebuilt by hand from both
What's included
- Risk assessment and a severity-ranked register
- Stabilisation of deployment and recovery, sequenced by risk
- Dependency and end-of-life remediation
- VB6 and VBA code read, documented, and where useful replaced
- Incremental modernisation, sequenced strangler-fig first
- Documentation and handover to your own team
Stack Visual Basic 6 · VBA · .NET · Delphi · FoxPro · PHP · SQL Server · AWS
Frequently asked questions
Do we have to start with the assessment?
In practice, yes. Quoting stabilisation work on a system nobody has examined means guessing, and on legacy systems the guess is usually wrong in the expensive direction. The assessment is fixed-price and fixed-scope precisely so that it is a small, bounded commitment before a larger one.
How long does a legacy rescue take?
The assessment is two weeks. Stabilisation is typically measured in weeks and modernisation in months, but both depend on what the assessment finds, so neither is quoted before it. Any firm quoting a modernisation timeline before reading the code is quoting a hope.
What if we no longer have the source code?
That becomes the first thing investigated rather than a reason to decline. Recovering a build from deployed artefacts is sometimes possible and sometimes not, and which of the two applies is established early and reported plainly. Where reconstruction is not viable, the assessment covers what it would take to replace the system instead.
Will you work alongside our existing developers?
Yes, and where a team already exists that is usually the better arrangement: they hold context no assessment recovers, and the goal is a system your engineers can change confidently rather than a permanent dependency on us.
Can you support the system afterwards?
Yes, as a separately scoped arrangement. The handover is written so that it is not compulsory — documentation, a working deployment path, and the access your team needs to run the system without us.
Is our system too old for you?
Almost certainly not. Revenant Systems works on platforms running from .NET back to Delphi and Lotus Notes, so age alone rarely rules a system out. What makes a rescue genuinely difficult is missing source code, no environment safe to test a change in, or a single person holding all the remaining context — and the assessment names which of those apply at the outset.
How is a rescue different from technical due diligence?
Technical due diligence answers a question for someone deciding whether to buy, invest, or commit — the audience is outside the system. A legacy rescue starts from the same independent assessment but continues into the work: stabilising the system and then modernising it. Owners take the second; acquirers and investors take the first.
Every engagement follows the same process — see how we work.
A system you can't safely change? Let's talk.
Get in touchYour message is read by the engineer who would scope the work; the reply is a short technical conversation.