Document and stabilise
Extract the business rules, write the runbook, add monitoring and backups, and make the current system safe to keep running for another five years. The cheapest option, and sometimes the correct one.
Legacy modernisation
The system that runs your business should not be a black box
Old software is not a moral failing. It is often the most accurate record of how a business actually works. We make it readable, connected and safe to change — without betting the company on a rewrite.
Most modernisation projects fail for the same reason: they start with the technology. A platform is chosen, a migration is planned, and eighteen months later the business is running two systems and trusting neither. The rules that made the old system valuable were never written down, so nobody can safely switch it off.
We start the other way round. The system is read, its behaviour is documented in plain English, and each rule is traced back to where it lives. Only then is a path chosen — which may be an API layer in front of the old system, a staged replacement, or simply better documentation and monitoring. The right answer is often less dramatic than a rewrite.
Three routes
What modernisation can mean
The route follows the risk, not the fashion.
Wrap and connect
Put an API or integration layer in front of the old system so new tools — a website, a CRM, an AI assistant — can read and write data without touching the core. No migration, immediate value.
Replace in stages
Move one function at a time behind the same interface, with both systems running in parallel until the numbers match. Slower than a big-bang cutover, and far less likely to take the business down.
What you get
Artifacts, not assurances
The output of a modernisation review should be usable by someone who was not in the room.
- A business-rule catalogueWhat the system does, in English, with each rule traced to its source.
- A data mapWhere the important data lives, how it moves, and which copies are authoritative.
- A risk registerWhat is fragile, what is undocumented, and what would happen if it stopped tomorrow.
- A staged planSequence, cost and exit criteria for each stage — including the option to stop.
- A documented interfaceIf we build an API layer, it is documented and owned by you, not rented from us.
A note on risk
A note on risk
- How we scope a projectSmall increments, reviewable progress, and a stopping point that does not waste the work.
- AI governanceIf AI is part of the new system, the data boundaries and approvals matter more, not less.
- Talk to us firstA short review is usually enough to tell you whether you need a rewrite or a runbook.
Questions
The things people ask first
Is a rewrite ever the right answer?
Sometimes. If the platform is unsupported, the supplier has gone, or the cost of keeping it running exceeds a replacement, a rewrite is justified. Even then, staged replacement is safer than a single cutover.
Do we need to know what the old system does?
No. That is what the review produces. You will know the business; we will read the code, the database and the people who use it, and write down what we find.
Will this disrupt the team?
The review is designed to be light-touch — interviews, read-only access and observation. Any build work happens behind the existing system, so the day job carries on.
What about AI?
Old systems are often the biggest obstacle to useful AI, because the data is trapped and poorly labelled. An access layer is frequently the enabling step. It is also a good place to start because it delivers value without a migration.
Related
Let’s find out whether technology is the answer
Tell us what you are trying to achieve. We will tell you honestly whether we can help, what it would take, and roughly what it would cost — before anyone signs anything.