Legacy Modernisation

When a legacy system slows the business but a complete replacement looks too expensive and too risky, a viable path in between is missing. The assessment works it out: a step-by-step replacement path following the strangler-fig pattern, named after the strangler fig that gradually replaces a host tree. Instead of replacing the core system in one go, the estate is analysed: new functions grow around the outside, the legacy system is replaced piece by piece, operations keep running throughout.

Typical starting points

  • a legacy system (ERP, line-of-business application, CMS, core platform) slows the business: the estate, interfaces and business processes are mapped
  • a complete replacement appears too expensive or too risky: a strangler-fig cut plan shows which modules can be replaced step by step via an API facade
  • a controlled, step-by-step path is sought: the replacement steps are ordered by risk, business value, fallback path and data migration

Outcomes

A migration roadmap on two levels emerges:

  • the fundamental decision: whether, in which order and with which investment and risk profile to replace
  • the technical cut plan: module boundaries, API facade, data migration per step

The legacy system stays in production throughout the entire replacement.

Scope of work

An API facade encapsulates the legacy system; new functions dock on from the outside and take over piece by piece, while operations keep running throughout.

flowchart TD
    accTitle: Strangler-fig replacement of the legacy system
    accDescr: An API facade encapsulates the live legacy system; new functions dock on from the outside and piece by piece form the target system that replaces the legacy system.
    A["Legacy system<br/>stays in production"] --> F["API facade<br/>anti-corruption layer"]
    F --> N["New functions<br/>dock on from outside"]
    N --> Z["Target system<br/>piece by piece"]
    A -.is replaced.-> Z

Estate and dependency analysis The legacy system, its interfaces and the business processes are mapped (dependency mapping):

  • which parts are coupled
  • where data flows in and out
  • which modules can be isolated

Strangler-fig cut plans For the modules that can be replaced, a cut plan emerges: an API facade (anti-corruption layer) encapsulates the legacy system, new functions dock on from the outside, the data flow stays controlled.

Risk and sequence plan The replacement steps are ordered by risk and business value:

  • which cut first
  • which fallback path
  • which data migration per step

Scope boundaries

This assessment delivers the analysis and the replacement plan, not the migration itself; its implementation follows as a subsequent mandate. The pure delivery capability of an existing team is assessed by the Delivery Assessment; when off-the-shelf software procurement is due, Make-or-Buy Consulting frames the build-versus-buy question.

Key data

The effort depends on the size and entanglement of the legacy system:

  • how many dependencies exist
  • how deep the code audit reaches
  • how fine-grained the cut and sequence plan should be

A self-contained system is examined in a short time, a landscape grown over years calls for more depth. What the replacement plan costs in a concrete case depends on exactly these factors. The price range gives the frame for your own system.

Request pricing

Further information