Mainframe Modernisation

Definition

Modernising a mainframe or equivalent core system: a platform that is typically extremely reliable, extremely expensive, deeply embedded, and understood by a shrinking number of people.

Why it is uniquely difficult

• The requirements exist only in the code, accumulated over decades, including behaviour nobody intended and some customer now depends on.
• The skills are retiring. This is the driver behind most such programmes, and it worsens regardless of what you do.
• It usually works. Reliability is frequently excellent, which means the replacement must be at least as good and there is no reliability argument to make.
• It is central. Failure affects the whole business, so risk tolerance is near zero.
• Batch cycles structure everything downstream, and the batch window is a hard operational constraint.

The strategies

• Encapsulate. Put an API in front and leave it. Cheapest, delivers immediate value by enabling modern services, and does nothing about the skills or cost problem. Frequently the right first step.
• Rehost. Move the workload to emulation on commodity infrastructure. Removes the hardware cost; keeps the code and the skills problem.
• Automated code conversion. Translate COBOL to a modern language mechanically. Produces code with the structure of COBOL in a different syntax, which is maintainable by nobody. Rarely a good outcome alone.
• Strangle by capability. Reimplement capabilities one at a time behind a routing facade, decommissioning as you go. Slowest, most expensive, and the only one that genuinely resolves the problem.

Most successful programmes combine them: encapsulate immediately for value, then strangle selectively where the business case justifies it, and accept that some parts may remain indefinitely.

What makes strangling viable here

• An anti-corruption layer, enforced. If mainframe semantics — packed decimals, fixed-width fields, peculiar status codes — leak into new services, replacement eventually means touching everything.
• Reads served from a projection, populated by change capture or batch extract, so new services are not constrained by the core's availability or performance.
• Writes queued and applied on the core's terms, with a visible pending state.
• Run-and-compare for every reimplemented capability, over a long period. The old system is the specification.

Failure scenarios

• A full rewrite attempted, which is the historical pattern of failure for these programmes.
• Automated conversion accepted as the end state.
• The last 20% never funded, so both systems run indefinitely.
• Mainframe semantics leaking into new services.
• The batch window ignored in the new architecture's design.

Interview question

"A core system is reliable, undocumented and staffed by people close to retirement. What do you do first?"