(Legacy modernisation & mainframe)

Legacy modernisation without the weekend everything goes dark

Legacy modernisation moves a system that still earns its keep onto something you can hire for and change safely. The work starts by reading code nobody has opened in years, and ends with the old system switched off deliberately.

Talk to an engineer What we deliver
Data mesh abstract
Legacy modernisation & mainframe

(Why these systems are still running)

A thirty-year-old system usually survives for a good reason: it works, it encodes rules the business forgot it had, and nobody can afford to be the person who breaks payroll. The risk is not the age of the code. It is that the people who understood it have retired and the documentation never existed.

Modernisation therefore begins as an archaeology exercise rather than an engineering one. Until the behaviour is written down and covered by tests, every migration option you are offered is a guess with a budget attached.

(What we deliver)

What legacy modernisation covers

Most engagements begin with an assessment and then take one route per subsystem rather than one route for everything.

  1. Static analysis of the codebase, a call and data-flow map, batch schedule and job dependencies, integration points, and interviews with whoever is left. The output is the documentation that should have existed: what the system does, and which parts are genuinely load-bearing.

  2. COBOL, JCL, CICS and VSAM or DB2 estates on z/OS and AS/400. Work covers re-hosting onto managed mainframe alternatives, refactoring COBOL into Java or C#, and unpicking the batch windows that quietly dictate the shape of the business day.

  3. Three routes with very different costs. Re-hosting moves the workload and buys time; re-platforming swaps the database or runtime while keeping the logic; rewriting replaces behaviour and is the only route that fixes the design. Each subsystem gets the route it deserves.

  4. A façade in front of the old system routes traffic per capability. New services take over one function at a time, with the old path still live behind a feature flag. The system is replaced gradually and there is never a single irreversible night.

  5. Mapping, cleansing and reconciliation between the old model and the new — including the fields that were repurposed in 2009 and the dates stored as text. Migrations are rehearsed on copies until two independent reconciliation runs agree.

  6. Support for the existing system while the move happens: regulatory changes, defects and the month-end run still need to work. Freeze windows are agreed so the old and new versions never drift apart unnoticed.

(What we work with)

(How we work)

How a modernisation programme runs

Six stages. The first two are worth buying on their own, because they tell you what the rest should cost.

  1. 01

    Discovery and archaeology

    Inventory the code, jobs, data stores and integrations. Static analysis plus interviews produce a behaviour document and a dependency map, including the batch schedule and the reports people quietly depend on.

  2. 02

    Characterisation tests

    Before changing anything, capture what the system currently does as executable tests — golden files from real inputs, batch outputs compared byte for byte. These become the definition of correct, since no specification exists.

  3. 03

    Route decision

    Per subsystem: re-host, re-platform, rewrite or leave alone. Each option is costed with its risk and its runway, and leaving a stable subsystem untouched for another five years is a legitimate answer.

  4. 04

    Façade and first slice

    An API façade in front of the legacy system, then the first capability moved behind it. The slice is chosen to be useful but survivable — something that proves the pattern without threatening the month-end run.

  5. 05

    Migration in slices

    Capabilities move one at a time, each with its data migration rehearsed, a parallel run where numbers must reconcile, and a flag that routes traffic back to the old path within minutes if needed.

  6. 06

    Retirement

    The old system is switched off deliberately, in stages, with archives retained for whatever your regulator requires. Licences and hosting are cancelled, and the saving is counted rather than assumed.

(Why Team of Keys)

How we de-risk a migration nobody can afford to get wrong

Big-bang replacements of legacy systems have a poor record, and the reasons repeat. These are the practices that avoid them.

  1. 01

    Tests before changes

    Characterisation tests capture current behaviour before a line moves. They turn "it should do the same thing" from an intention into something a pipeline can check on every commit.

  2. 02

    A way back at every step

    Traffic routing sits behind a flag, data migrations are rehearsed on copies, and the old path stays warm through the parallel period. No slice goes live without a tested rollback.

  3. 03

    Documentation as a deliverable

    The behaviour document, data dictionary and dependency map are written during assessment and kept current. Even if you pause the programme, you no longer own a system only one retired person understood.

  4. 04

    Honest about what not to move

    Some subsystems are stable, cheap to run and better left alone. Recommending that costs us work and saves you money, and it keeps the programme focused on the parts that actually hurt.

  5. 05

    The business day is protected

    Batch windows, month-end, regulatory filing and peak trading are mapped early and treated as constraints. Cutovers are planned around them rather than discovered by them.

(Related)

More in consulting

All consulting services

(FAQ)

Questions, answered

It depends on the subsystem, and the answer is usually a mixture. Re-hosting is quickest and buys runway without fixing anything. Re-platforming swaps the runtime or database while keeping the logic. Rewriting is the most expensive and the only route that changes behaviour or design. The assessment prices all three per subsystem so the choice is made with numbers.

Yes — COBOL, JCL, CICS, DB2 and VSAM on z/OS, plus RPG on IBM i. The work includes reading and documenting existing programs, building characterisation tests around batch output, re-hosting workloads, and refactoring COBOL into Java or C# where a rewrite is justified. Scarce skills are involved, so these engagements are planned with longer lead times.

With the code and the data. Static analysis produces a call graph, dependency map and batch schedule; the database shows what is actually used and what has been dead for a decade. Interviews fill the gaps. Within a few weeks you have a behaviour document, which is valuable on its own even if the migration is postponed.

By moving one capability at a time behind a façade rather than replacing the system in one night. Data migrations are rehearsed on copies until two independent reconciliation runs agree, parallel running proves the numbers match, and traffic can be routed back to the old path within minutes. Cutovers are scheduled away from month-end and peak trading.

Assessment and characterisation usually take a few weeks to a couple of months depending on the size of the estate. The migration itself runs in slices over quarters, and the sequence is chosen so the highest-risk or highest-cost subsystems move first. Anyone promising a full mainframe replacement on a fixed short timeline is guessing.

(Global presence)

Nine countries, one studio behind them.

Every project is designed, built and shipped from one studio.
Turn the globe, or pick a country to see what we deliver there.

NoidaDrag to turn

Studio · Noida, India · --:--

(Next step)

Start by finding out what the old system really does

Tell us the platform, the languages and what is forcing the change. You get a scope and price for the assessment, and documentation you keep either way.

START

Or write to info@teamofkeys.com · Noida, India