Skip to content
Arcwright
PLT

Platform modernisation

We replace load-bearing legacy systems one capability at a time, while they stay in production.

  • Strangler fig
  • Mainframe offload
  • Domain modelling
  • Incremental cutover
  • COBOL
Start a projectAll capabilities
Code
PLT
Class
A · 12 months and over
Engagement
TYPICAL 9-18 MONTHS · FIXED-PRICE DISCOVERY
Stages
05
Deliverables
06
Sections
06

Overview

Most legacy platforms are not badly built. They are fifteen years past the assumptions they were built on. A rewrite that goes dark for two years is how these programmes fail, so we do not run them that way. We wrap the existing system, move one bounded capability at a time behind a routing layer, and run old and new side by side until the traffic and the numbers agree. Nordvik Bank’s core ledger came off a 1.4M-line COBOL estate this way over fourteen months, with no customer-visible downtime and a rollback available at every step.

Benefits

05 points

  • Every increment ships to production. The first capability moves in weeks 6–10, not at the end of the programme.

  • Rollback stays available throughout. The legacy path is kept warm and traffic-switchable until the replacement has run clean for two full reporting cycles.

  • Change gets cheaper as scope shrinks: Nordvik Bank’s median change lead time fell from 34 days to 4 once the first six capabilities had moved.

  • Domain boundaries come out of the code and the data, not a whiteboard. We derive them from measured call and table-access patterns in the running system.

  • The team that maintains it afterwards writes it with us. We pair from week one and hand over with no exclusive knowledge left in our heads.

Workflow

05 stages

  1. Estate survey

    Two to four weeks. We inventory every module, batch job, integration and scheduled task, then instrument the running system to find what is actually invoked. On the Vanta Logistics estate, 31% of modules had not executed in eighteen months and were retired rather than rewritten.

  2. Seams and sequence

    We identify where the system can be cut and order the capabilities by risk-adjusted value. The output is a dated sequence with an explicit rollback for each step, not a phase diagram.

  3. Routing layer

    A facade in front of the legacy entry points so traffic can be moved per capability, per tenant or by percentage. Nothing else can be delivered incrementally until this exists, so it is built first.

  4. Capability migration

    One bounded capability at a time: rebuild, run in shadow against live traffic, diff the outputs, then cut over. Discrepancies are reconciled before the switch, never after it.

  5. Decommission

    Legacy code paths are deleted, not left dormant. Each retirement is recorded with the licence, infrastructure and support cost it removes, so the programme’s savings are evidenced rather than projected.

Deliverables

06 items
  • Estate inventory: every module, batch job, integration and data store with last-execution date and named owner.
  • Sequenced migration plan with a rollback procedure per increment.
  • Routing and facade layer in your repositories, splitting traffic by tenant and percentage.
  • Shadow-comparison harness that diffs legacy and replacement outputs on live traffic.
  • Decommissioning record: what was switched off, when, and the annual cost it removed.
  • Architecture decision records for every irreversible choice, in-repo and in plain English.

Questions

04 entries

  • Yes, and we plan for it. A freeze is what makes these programmes politically unsurvivable. Product work continues against the legacy system, and the routing layer means each migrated capability picks up interim changes during its shadow-run phase. On the Nordvik Bank ledger programme the product team shipped 41 changes while migration was in flight.

  • It is the normal case, and the estate survey is built for it. We read the code and instrument the running system rather than relying on documents. Nobody remaining at Kestrel Energy had written any part of their settlement platform, and the survey still produced a complete call graph in three weeks.

  • Shadow running. The replacement processes real production traffic in parallel with its outputs discarded, and a comparison harness diffs every result. We require a clean run across two full reporting cycles — for a monthly settlement, two months — before any traffic moves.

  • Occasionally: when the system is small, well understood, and its data model is the actual problem. We will say so if that is what discovery finds, and the fixed discovery fee is the only thing you will have spent.

Start a project

02 locations

Enterprise systems consultancy

  • Manchester, United Kingdom
  • Oslo, Norway
Start a projecthello@arcwright.example