Services
Enterprise Software Modernisation Services
Replacing or re-platforming legacy systems in stages, while the business carries on running on them.
Technology and operations leaders carrying a system nobody wants to touch and nobody can switch off
The reason legacy systems survive is rarely sentiment. They survive because nobody can state with confidence what they do, and a rewrite that cannot be proven equivalent is a business risk rather than an upgrade.
Modernisation work is therefore mostly evidence work. Establish what the system actually does, encode that as tests, then move capabilities across one at a time behind a routing layer, with the old path still available until the new one has proven itself in production.
How it runs
What the engagement includes
- 01 Comprehension first, using AI-assisted reading of undocumented code alongside people who know the business
- 02 Strangler-fig routing so new services take traffic one capability at a time
- 03 Incremental cutover with dual-running, reconciliation and a rehearsed way back
- 04 Data migration treated as its own project, with correctness checks that run on every rehearsal
Related work
What this looks like in production
Tell us how the work
runs today.
We will tell you honestly whether this service is the right shape for it, or whether something smaller would do.
Enterprise Software Modernisation — frequently asked questions
Why not rewrite the system in one go?
Because a big-bang rewrite has to reproduce years of undocumented behaviour before it can go live even once, and it usually discovers the missing behaviour on cutover weekend. Taking capabilities across one at a time means every step is reversible.
How does the strangler-fig approach actually work?
A routing layer sits in front of the legacy system and sends selected requests to new services instead. The old system keeps serving everything else, and the share of traffic it handles shrinks until it can be switched off.
What does AI genuinely help with on legacy code?
Reading it. Summarising what a large stored procedure or a class with no tests appears to do, mapping call graphs, drafting characterisation tests and flagging dead paths. Every output is verified against the running system before anyone relies on it.
What if the original developers are gone and there is no documentation?
That is the normal case. Behaviour is recovered from the code, the database, production logs and the people who use the system daily, then written down as characterisation tests so the new implementation has something to be judged against.