An organisation must modernise a mainframe system running critical batch processes. What makes this harder than typical modernisation, and what approaches exist?

What makes it harder

1. The business rules are the asset, and they are undocumented. Decades of accumulated logic encoding regulatory requirements, product variations and edge cases, most of which exists only in the code. Recovering them is the project, and the technology conversion is the easy part.

2. Batch processing with hard windows. Overnight jobs with strict completion deadlines and complex inter-job dependencies. The replacement must not merely be correct but must finish in time, and the dependency graph is frequently undocumented.

3. Correctness requirements are absolute. These systems typically handle money, entitlements or regulated records. An error is not a degraded experience; it is a financial or regulatory event.

4. Scarce expertise, and it is retiring. This is a schedule risk that no technical approach removes and it is the reason many of these programmes have a deadline that is not technical.

5. Exceptional operational characteristics. Mainframe transaction throughput and reliability are genuinely high, and a distributed replacement must demonstrate it can match them rather than assuming it will.

The approaches

Rehost or emulate. Move the workload to an emulated environment. Preserves behaviour exactly, addresses hardware and licence cost, changes nothing about maintainability. A legitimate step when the objective is exiting the hardware.

Automated code conversion. Translate to a modern language mechanically. Preserves behaviour and produces code that is structurally mainframe-shaped and frequently unmaintainable — trading one maintenance problem for another with more available staff.

Incremental extraction with a façade. Route requests through a layer, replace capability by capability, each verified with parallel run or shadowing. Slowest, safest, and the only approach with a defined end state that improves maintainability.

Replace with a package where the capability is commodity. Frequently the right answer for standard functions, and it moves the problem to configuration and data migration.

The technique that matters most

Parallel run with automated comparison. Both systems process the same real inputs and the outputs are compared automatically, with every discrepancy triaged as a new-system defect, an undocumented old-system behaviour to reproduce, or an intended change.

The second category is the deliverable. It is how decades of undocumented business rules are recovered, and no amount of code reading substitutes for it.

The sequencing that reduces risk

Extract the read paths and reporting first — lower risk, immediate value, and they build the comparison machinery. Then peripheral batch processes. Then the core transactional path last, with the longest parallel run.