Skip to main content
Agentic Online

Illustrative solution pattern

Incremental legacy modernisation

Replacing a system that cannot be switched off, one capability at a time, with every step independently reversible.

Illustrative solution pattern. This describes a solution we design and build, not a completed engagement. The expected outcomes below are design intent, not measured results, and we have not yet delivered this pattern for a client.
Cloud and infrastructureGovernment & public sectorEnterpriseHealthcare

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

  1. Map capabilities, dependencies and data ownership in the current system
  2. Write characterisation tests so current behaviour — including its quirks — is documented and protected
  3. Introduce a facade so traffic can be routed per capability without callers changing
  4. Replace the highest-value, lowest-risk capability first, running both paths in parallel and comparing output
  5. Cut over one capability at a time, keeping the rollback path available at each step
  6. 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

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.

We have not yet delivered this pattern for a client. If that matters for your procurement, we would rather you knew now.
  • 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

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.