Software architecture
Legacy application modernisation
I evolve legacy applications through controlled stages while production stays live. The goal is not to rewrite everything, but to take back control of a system you no longer dare to change.
What it covers
Legacy systems hold the company's business value and a body of knowledge nobody documented. Rewriting them in one go means betting several years of budget on an imperfect understanding of the rules. I prefer incremental modernisation: secure first, isolate next, replace last.
The first stage is to freeze current behaviour with acceptance tests, then create a technical seam in the code — a boundary through which a business capability can be extracted without touching the rest. Every extracted increment ships to production behind a reversible switch.
Three possible paths
Depending on system state, the target may be an in-place upgrade, progressive service extraction, or strangler-pattern replacement. The choice is made on measurable criteria: achievable test coverage, operating cost, in-house skills and the expected lifespan of the system.
- Non-regression tests on critical business rules.
- A technical seam to extract capabilities one at a time.
- Temporary parallel operation with output comparison.
- Versioned, reversible schema migrations.
- A log of the obscure points discovered along the way.
Problems addressed
Nobody dares to change the application for fear of side effects. Documentation is outdated or missing for business rules. Technical components are no longer supported by their vendor. Hiring is hard for the technologies in use. Processing times no longer handle current business volumes.
Expected benefits
Production stays live throughout the programme. Risk is reduced continuously instead of a single bet. Business rules documented by tests rather than memory. A team that regains confidence in the existing code. Better controlled operating costs at every delivered increment. You can stop at any point without unfinished work in progress.
Method and steps
- 1
Diagnosis and priorities
Analysis of the system, its dependencies and business rules to select the most valuable and least risky first increment.
- 2
Hardening
Acceptance tests over observed behaviour, a faithful staging environment and instrumentation of key processing steps.
- 3
Incremental extraction
Isolating a business capability behind an interface, building the new component and running both in parallel with output comparison.
- 4
Switch and cleanup
Activating the new component, reinforced monitoring during the switchover, then removing the code that became redundant.
Deliverables
System map with identified breaking points.
Non-regression test suite covering critical rules.
Work breakdown with effort and risk estimates.
Modernised components delivered and documented.
Decommissioning plan for the legacy scope.
Log of undocumented business discoveries.
Technologies used
- Java
- Spring Boot
- PostgreSQL
- Flyway
- Docker
- Kubernetes
- OpenTelemetry
Frequently asked questions
Does the whole application have to be rewritten?
In most cases, no. Incremental extraction modernises 70 to 80 percent of the useful system while keeping the rest, often a stable and cheap-to-maintain layer of business rules.
How do you guarantee there are no regressions?
We start by freezing existing behaviour with acceptance tests, then run the old and new components in parallel on anonymised production data before switching over.
What if the project stops halfway?
Each delivered increment is self-contained and operable. If the programme stops, the system stays coherent: part modernised, part legacy, joined by documented interfaces.
Related case studies
Incremental overhaul of a contract management monolith
Modernisation through domain extraction, with no service interruption
Demonstration sample - not a real client reference.
Discuss my modernisation
Let us discuss your technical context and schedule constraints. We will identify a first increment with low risk and immediate impact.