Every organisation past a certain age has a core — the systems that handle the money, the inventory, the customer records, the regulatory reporting. Replacing them outright is rarely an option; leaving them untouched eventually is not either. Core modernisation is the discipline of moving forward without breaking what works.
We approach core modernisation as an operating-model change with a technology consequence. Most of the cost and most of the risk lives in the operating model — change control, run-the-bank capacity, integration ownership, regulatory reporting. The technical reroute is the easier half.
What modernisation actually looks like
Strangle, do not replace
We route around legacy systems with API facades, event streams and new front-end surfaces, then migrate functionality piece by piece behind the same external contract. The business sees one consistent system; the engineering team is quietly rebuilding it underneath.
This is the default pattern for any core system that the business depends on day-to-day. The big-bang replacement is the wrong default; we use it only when the constraints make incrementalism impossible.
Data first
Most core systems are valuable because of the data they hold. We separate the data layer from the application layer early, so the data becomes accessible to the rest of the business without waiting for the application rewrite.
Often the data-layer separation is the highest-ROI piece of the whole modernisation programme. It unlocks analytics, ML and customer-experience work that was blocked by the legacy schema, sometimes for years.
Migration without downtime
Dual-running, shadow writes, reconciliation and explicit cut-over criteria. We default to incremental migration patterns and avoid big-bang cut-overs unless the constraints actually demand them.
We have done plant-floor cutovers and end-of-year-close cutovers. The art is in the reconciliation — knowing the two systems agree on every record before traffic moves.
What we keep
Not every legacy system needs replacing. We are happy to recommend keeping a working core in place for another decade if the cost of replacing it would not earn back. Modernisation is a portfolio decision, not a religion.
The mainframes that handle US insurance claims and EU payment rails are not going anywhere soon, and that is fine. The right answer for those systems is usually to modernise their integration surface and the operating model around them, not to migrate the core engine.
What we have done
Insurance policy admin, banking core ledgers, manufacturing MES, retail merchandising, public-sector case management. The pattern repeats: separate the data, decouple the integrations, replace the front end, then chip away at the back end on a schedule the business can absorb.