Service
Re-engineering
Thirty years of this work has taught us that the risk in legacy modernisation is never the new code, it is the undocumented behaviour in the old system. We move systems incrementally, keeping them in production throughout.
What you get
Outcomes, not activity
Running costs cut, often by an order of magnitude
No big-bang cutover and no feature freeze
Behaviour preserved, verified against the legacy system
A codebase new engineers can join without a six-month ramp
Scope
What the work actually involves
The pieces we bring to a typical engagement. Not every project needs all of them.
01
Technical audit
A dependency, risk and cost map of the existing system, with the modernisation options priced against each other.
02
Incremental migration
Strangler-pattern rollout: new services take traffic slice by slice while the legacy system keeps serving everything else.
03
Behavioural test harness
Characterisation tests and shadow traffic that prove the replacement matches the original before it takes over.
04
Platform move
On-premises or ageing frameworks moved to modern runtimes and cloud infrastructure, with the licence bill reduced accordingly.
Toolkit
What we tend to work with
Chosen per project rather than per preference. If your team already runs something else and runs it well, we work in your stack.
- Java
- C/C++
- C#
- .NET
- Oracle
- SQL Server
- Postgres
- AWS
- Azure
Questions
Re-engineering in practice
Our system has no documentation and nobody who built it. Now what?
That is the normal case. We recover behaviour from the running system and its data rather than from documents. Instrumentation, traffic capture and characterisation tests give us a specification that is accurate by construction.
Related
Often combined with
Talk to someone who has shipped this
A short call with the engineer who would run the work, not a salesperson with a calendar link. We will tell you if it is not a fit.
Typical reply within one business day · Initial consultation is free