Illustrative solution pattern
Incremental legacy modernisation
Replacing a system that cannot be switched off, one capability at a time, with every step independently reversible.
The challenge
The problem this solves
A system is business-critical, poorly understood and risky to change. The knowledge that built it has moved on, there are no tests, and a full rewrite is both expensive and dangerous.
Existing process
The limitation being removed
Change requests are deferred because nobody can predict the consequences. Workarounds accumulate around the system, and the cost of the eventual replacement grows with every year of deferral.
The solution
What was built
Modernisation by increment rather than replacement. We characterise current behaviour with tests and instrumentation first, then route one capability at a time to a new implementation behind a facade, running both in parallel and comparing outputs until the new path is trusted. Each step delivers a working system and can be reversed on its own.
Implementation approach
- Map capabilities, dependencies and data ownership in the current system
- Write characterisation tests so current behaviour — including its quirks — is documented and protected
- Introduce a facade so traffic can be routed per capability without callers changing
- Replace the highest-value, lowest-risk capability first, running both paths in parallel and comparing output
- Cut over one capability at a time, keeping the rollback path available at each step
- Retire the legacy component only once the new path has been verified in production
Technologies used
- Characterisation tests capturing current behaviour before any change
- Facade or proxy routing between old and new implementations
- Parallel-run comparison of legacy and replacement outputs
- Infrastructure as code for reproducible environments
- Observability across both paths during transition
Services provided
Applicable sectors
- Government & public sector
- Enterprise
- Healthcare
- Professional services
Security and governance
Controls designed into the solution
Decided before implementation. Every one of these is an architectural choice, which is why they cannot be added afterwards without a rebuild.
- Characterisation tests written before any change, so regressions are detectable
- Parallel running with output comparison before any cutover
- Rollback defined and tested per increment, not only for the programme
- Data migration validated by reconciliation, not assumed from a successful run
- Access and audit controls at least equivalent to the legacy system, never weaker
- Every architecture decision recorded, so the reasoning survives the programme
Outcome
Expected outcome (design intent, not a measured result)
These are design expectations for this pattern, not measurements from a delivered engagement. We would agree how to measure them with you before building.
- Risk falls progressively rather than concentrating in a single cutover event
- The system becomes changeable again, so deferred improvements can proceed
- Behaviour is documented in tests instead of held in individual memory
- Each increment can be justified, funded and reversed on its own merits
Related
Other solution patterns
Grounded knowledge assistant
An assistant that answers staff questions from your approved documents, cites its sources, and declines when the corpus does not cover the question.
Read the full write-upDocument intake and extraction
Structured data extracted from inbound documents, with confidence surfaced and a person confirming before anything is committed.
Read the full write-upAutomated compliance checking
Submissions checked against a written rule set, with every finding citing its clause and a competent person confirming the outcome.
Read the full write-upCloud & Infrastructure
Cloud architecture, migration and system integration — designed for the cost, resilience and compliance position you actually need.
Application Development
Secure, maintainable web and mobile applications — new builds, AI-enabled products, and the modernisation of systems that have become risky to change.
Could this work for you?
Tell us how your situation differs from this example. Where a material uncertainty remains, a bounded proof of concept with a pass threshold agreed in advance is usually the cheapest way to find out.
We reply to every enquiry within one business day.