There is a number buried in every mainframe shop's monthly invoice that tells you more about the organization's future than any strategy deck: the MIPS bill. It goes up. It has gone up every year for decades. And the people paying it have learned to treat the increase the way you treat gravity — not as a decision, but as a condition of existence.
That learned helplessness is the most expensive assumption in enterprise IT.
What you are actually paying for
MIPS — millions of instructions per second — started as a rough performance measure and became a billing unit. IBM and compatible vendors license mainframe capacity by MIPS (or its successors: MSUs, LPARs, various sub-capacity metrics that all reduce to the same thing). You pay for how much processing you consume, measured in units the vendor defines, at prices the vendor sets, on hardware only the vendor manufactures.
This is not a market. It is a metered monopoly with a captive customer base, and the meter is designed by the party that reads it.
The bill has three layers that compound against you. First, the hardware capacity charge — the sticker price for the iron. Second, the software licenses tied to that capacity: databases, transaction monitors, middleware, each billed per-MIPS or per-MSU on a curve that punishes growth. Third, the specialized labor to operate and tune a platform whose scarcity premium rises every year as the workforce ages out.
When an enterprise says "our mainframe costs $X million a year," that number is usually just the first layer. The fully loaded cost — software, labor, facilities, the compliance overhead of running a platform fewer and fewer auditors understand — is routinely multiples higher. And every layer has its own escalation clause.
The standing-still trap
Here is the part that doesn't make it into vendor presentations: doing nothing is not free. Keeping the mainframe exactly as it is, no new features, no new integrations, just the same batch jobs and the same CICS transactions, still gets more expensive every year. Hardware refreshes come with new pricing. Software license renewals come with new terms. The COBOL programmers who understand your system retire, and their replacements — if you can find them — charge a scarcity premium that tracks the shrinking labor pool.
This is the standing-still trap. The cost of inaction rises on a curve, and the curve is set by parties who profit from your inability to leave. Every year you delay modernization, the economics of leaving get compared against a baseline that has quietly moved upward. The modernization business case that "didn't pencil out" three years ago may have been overtaken by cumulative cost increases that nobody recalculated because the invoice just rolls forward.
Why the economics encourage bad modernization decisions
A rising cost baseline creates urgency, and urgency is where procurement mistakes happen. The MIPS bill doesn't care about your evaluation timeline. It arrives monthly, it trends upward, and it creates pressure to act — which modernization vendors understand and price against.
This is how organizations end up signing modernization contracts that trade a known, escalating cost for an unknown, poorly bounded one. The pitch is always "reduce your mainframe spend." The mechanism is usually: move the workload to our platform, pay us instead. The part that gets negotiated least carefully is what happens when the new platform's costs escalate too — because the buyer was fleeing a burning building and didn't read the lease on the new one.
Lift-and-shift deals are the clearest example. The MIPS bill goes away. A cloud or hosted-capacity bill replaces it. The new bill may start lower. But the workload hasn't changed, the processing demand hasn't changed, and the metering has just moved to a different vendor's terms. You've refinanced the debt. You haven't paid it down.
What an honest cost comparison looks like
If the MIPS bill is the reason to move, then the comparison has to be total cost of ownership on both sides, projected forward, with escalation modeled on both curves. That means:
- The fully loaded current cost, not just the hardware line, including software licenses, labor, facilities, and the compliance premium for maintaining a platform with a shrinking talent pool.
- The projected current cost over five and ten years, using the actual escalation rates from your last three renewal cycles — not the vendor's generic inflation assumption.
- The fully loaded target cost, including the conversion itself, the new platform's licensing and compute charges, the labor to operate the new stack, and the re-skilling or hiring cost for a different technology.
- The projected target cost over the same horizon, with the new vendor's escalation terms modeled honestly — not the introductory rate held constant.
- The transition cost, including the parallel-run period where you are paying both bills simultaneously, the productivity loss during cutover, and the contingency for the conversion taking longer than planned (which it will).
Most modernization business cases skip at least two of these. The most commonly skipped: the dual-bill period during parallel run, and the new vendor's escalation curve. Both omissions flatter the case for moving.
The actual question
The MIPS bill is real, it is expensive, and it is going up. None of that is in dispute. The question is not whether to modernize — it is whether the specific modernization being proposed actually solves the economic problem, or just moves the meter to a different wall.
A conversion that produces genuine, portable, maintainable code in a commodity language — code your team can operate, modify, and deploy without a proprietary runtime — actually retires the MIPS dependency. A conversion that moves the workload into a vendor-specific execution environment just changes which invoice you dread opening.
The difference between those two outcomes is not visible in a demo or a slide deck. It is visible in the contract terms, in the portability of the output, and in whether the vendor can demonstrate — with proof, not promises — that the converted system produces identical results to the one it replaces.
The MIPS bill is a real problem. It deserves a real solution, not a refinancing marketed as an escape.