Application modernisation
A legacy application is not replaced in one go. It is mapped, cut into batches, and rebuilt one batch at a time, with proof at every step that nothing changed for the people using it.
A rebuild rarely fails on the technology.
Seven to eight modernisation programmes out of ten miss their target, and almost never for technical reasons: scope that widens, business arbitrations never made, and a tunnel effect where nothing ships for eighteen months.
We take the problem from the other end. The estate is mapped before anything is touched, the first batch goes to production before the second is decided, and every cutover can be replayed backwards the moment a gap appears. What makes a rebuild survivable is not the target you pick, it is the size of the step.
What we do
Four workstreams so a rebuild is decided on facts and delivered in pieces.
Mapping and diagnosis
Look at what runs before touching it: dependencies, technologies, obsolescence and coupling, then a score per batch crossing business value with technical complexity.
analysis speeds up reading the code, it does not sign the diagnosis
- Dependencies, obsolescence and coupling
- A score per batch, value and complexity
- No finding published without engineer review
Rebuilding in batches
The new component takes traffic in fractions while the old one stays up. Nothing is switched off until the replacement has proven itself on real traffic.
one batch in production before the next is decided, never the other way round
- One batch shipped, the old one still up
- Cutover by fractions of traffic
- Immediate fallback, with no redeploy
Migration and replatforming
Moving, rehosting or rewriting is decided batch by batch, not for the whole estate. An application moved unchanged often costs more in its new home.
public, private or qualified cloud, according to what the data requires
- The move arbitrated per batch
- Sovereign cloud where the data demands it
- Infrastructure described as code, not configured
Proven non-regression
Every rule is specified in executable form, and tests are produced at the same pace as the code. The absence of regression is demonstrated by replaying traffic, not asserted.
both engines compute in parallel, only one answers
- One executable specification per rule
- Tests produced at the pace of the code
- The gap is shown, not declared
What you get
One project runs through the four deliverables below: the pricing engine of a legacy back office, twenty-one years old, three hundred and twelve rules. Each line states what is actually handed over, in the order it is handed over.
The map of the estate
The file the first batch is decided on: calls per day, number of rules, coupling, obsolescence and business value. A batch with low traffic and low value comes out as a candidate for retirement rather than a rebuild.
Intent rewritten before code
Each rule becomes an executable specification with its acceptance criteria and its origin line in the legacy code. Those whose intent cannot be recovered go to business arbitration rather than identical rewriting.
Cutover in fractions
One per cent, ten, fifty, then all of it, each tier conditional on the previous one. Both engines compute in parallel, the gap is logged on every call, and fallback fires without a redeploy.
Proof by replay
Thirty days of real traffic are replayed on both engines and compared call by call. What the replay finds is not always a defect of the rebuild, and that is exactly what makes it useful.
How we deliver
Map
depending on the number of applications, languages and couplings to untangle
- Application map and dependencies
- Modernisation score per batch
- A costed, negotiable trajectory
Rebuild one batch
depending on the rules to recover and the systems to reconnect
- Executable specification for the batch
- Non-regression coverage produced with the code
- Progressive cutover with immediate fallback
Roll out
depending on the batches left and how coupled they are
- Following batches on the same template
- The old system switched off, batch by batch
- Team upskilling
Hold
service commitment defined with you
- Debt tracked as an indicator
- Version upgrades handled, not endured
- Documentation regenerated with the code
What waiting costs
Rebuilds that held
Business rules made readable and testable again
483 rules reimplemented · 53 SAP flows integrated
Rebuild the time-management rules engine behind the schedules, planning and payroll of 12,000 employees, with hundreds of inherited rules and dozens of SAP flows whose errors propagate downstream.
Every rule specified in executable form rather than written in prose, the implementation generated under engineer review, non-regression coverage produced at the same pace, and SAP flows validated one by one before production.
Interbank flows modernised, treasury brought together
−45% closing cycle · −60% reconciliation time
Interbank flows spread across fourteen counterparty banks, a closing cycle that lengthened with volume, and a migration to SAP S/4HANA to carry out without interrupting the treasury.
Flows modernised and centralised, reconciliation automated, and the ERP migration secured step by step rather than in one cutover. Volumes tripled without the closing cycle following.
A rebuilt editorial site, and the maintenance that holds it
−45% load time · 5 of 6 Core Web Vitals green
An editorial site whose performance was eroding release after release, on a title where reading comfort is the product, with maintenance that had to outlive the rebuild.
A rebuild driven by measurement rather than by taste, then a maintenance setup that keeps the measurement running: what degrades is seen on the next release, not in the next audit.
Insights & Perspectives
Microservices anti-patterns: the traps that sink migrations
Splitting too early, splitting too finely, or reproducing the monolith across a mesh of services: the costliest mistakes are made at the moment of the split.
Hexagonal architecture: principles, ports and adapters
Isolating the business from what surrounds it makes an application testable and movable. That is what lets you change database or host without reopening the logic.
Automating framework upgrades: AI and traditional tooling
What migration tools handle on their own, what AI adds, and where human review remains the only guarantee on a framework version upgrade.
Start by looking at what you have
A map of the estate, a score per batch, and a trajectory that can be discussed before it is committed to.
Frequently asked questions
Because the obstacle is rarely technical. Seven to eight out of ten fail on organisation: scope that widens, business arbitrations never made, and a tunnel effect where nothing reaches production for months. Shipping one batch early is the best known antidote.
Neither, for the estate as a whole. The choice is made batch by batch: move what is healthy, rewrite what blocks, retire what no longer serves. An application moved unchanged keeps costing what it cost, in a place that is often more expensive.
The new component takes a fraction of the traffic while the old one keeps running. You climb in tiers, one per cent, ten, fifty, each conditional on the last, and the old one is only switched off after a period with no gap. At no point is there a single cutover to undo.
By replaying real traffic on both versions and comparing call by call. A test campaign written afterwards covers what someone thought to test; a replay covers what users actually do, including the cases nobody had documented.
They go to business arbitration, not to identical rewriting. Reproducing a rule you do not understand carries the debt into the new system. This is often the moment you discover that two departments were applying the same rule differently.
No, but it changes the scale of the work. Automated conversion has moved from roughly 40% reliability in 2020 to 70-85% today: it absorbs the volume, recovers intent from the code and generates the tests. Decision and review stay human, on a system whose errors reach a customer.
Mapping takes 2 to 6 weeks depending on the number of applications, languages and couplings to untangle, and produces a costed, negotiable trajectory. The first batch follows in 4 to 10 weeks, with its executable specification, its non-regression coverage and its progressive cutover.