Review this plan. A bank will move 80% of balance-enquiry reads off the mainframe onto a new store fed by change data capture. The nightly batch that posts interest and produces statements stays where it is for three more years. The business case is built on the licence saving. One reviewer says the headline saving will not appear. Which objection is correct?

What is actually being bought

Mainframe monthly licence charges under sub-capacity pricing are billed on the highest rolling four-hour average of capacity consumption in the month, not on average consumption and not on the instantaneous peak. The measurement rolls continuously, and the single worst four-hour window in the month prices the whole month for that product. This has been the standard sub-capacity model for many years and remains so as of 2025.

That makes the batch, not the online traffic, the thing that sets the bill. Interest posting and statement generation are the densest four hours the machine sees. Removing 80% of the online reads lowers the daytime curve, which is real engineering and a genuine improvement in headroom and response time, and it leaves the billable window untouched. A business case built on the licence line will miss, and it will miss by most of its value.

What I would change

Keep the offload. Change what it is sold on and what follows it.

• Justify the offload on the outcomes it actually delivers: online capacity headroom, response time, and the ability to build new services without queueing behind the core. Those are worth funding and they are defensible.
• Attack the peak window separately. The licence lever is batch: move jobs out of the peak window, flatten the profile, or move the batch workload itself. Capping is the crude version and it trades cost for elapsed time, which on a statement run means a missed delivery deadline.
• Instrument before promising. Pull twelve months of consumption reports and find which product and which four-hour window prices each month. A saving claimed without that data is a guess.

What I would leave alone

Leaving the batch in place for three years is the right call, even though it is what breaks the business case. Batch is where the undocumented business rules live, it is the workload with the hardest deadline, and a rewrite of it is the most expensive treatment available. The plan's error is in the finance, not in the sequencing.

Why the other options fail

• Capture adds more load than it removes. Log-based capture reads the journal rather than the data, and its overhead is a small fraction of the query load it displaces. It is a real consideration on a machine with no headroom at all, and here it is not the reason the saving vanishes.
• Balance enquiries are cheap. They are individually cheap and collectively the largest online workload, which makes them the right offload target. The objection confuses unit cost with total cost.
• Disaster recovery cancels the saving. The read store does need a recovery tier and it is a real line item, and it is an order of magnitude below the mainframe charge it was supposed to offset. It reduces a saving that was never going to appear.

When not to make this objection

If the estate sits on a fixed-capacity or flat-rate agreement rather than sub-capacity pricing, the four-hour peak is not the lever and the objection is wrong. Under those terms the charge does not move with consumption at all, the offload's business case has to rest on deferred hardware upgrades and on online headroom, and arguing about the batch window wastes the review's attention. Establish the contract type before the metric.

How I would argue this in the review

Lead with the measurement, not the opinion: show the four-hour window that priced last month and which workload was in it. An architecture argument that lands in a finance conversation is one that names the billing metric.