MIPS to MSU has no fixed rate, and that is the point.

MIPS, millions of instructions per second, is a capacity and performance measure. It answers how much work the machine can do and is the language of capacity planning, sizing, and hardware refresh. MSU, Millions of Service Units, is a software pricing unit. It answers what you pay, and it is the basis on which IBM bills Monthly License Charge (MLC) products and on which much of the third party stack is priced too.

The two are related but not interchangeable. IBM assigns an MSU rating to each machine model and capacity setting, and that rating is set to reflect software pricing policy, not to track MIPS at a constant rate. Newer machines deliver more MIPS for each MSU through what is commonly called the technology dividend, which is why the conversion drifts every generation rather than holding at a single ratio.

The rule of thumb people reach for is roughly 6 to 7 MIPS per MSU, but using a fixed ratio hides the one effect that matters most to the bill: the same workload can rate at fewer MSUs on a newer machine. The table below takes an identical workload of about 3,000 MIPS across two hardware generations to show how the MSU figure, and therefore the software charge, can fall even as raw capacity holds.

Same work, same MIPS, yet the newer machine rates the workload at 441 MSU instead of 500, a difference that flows straight into the MLC bill for every sub-capacity product. The exact MSU rating comes from IBM's published figure for the specific model and capacity setting, never from a generic ratio. The lesson: size the box in MIPS, but cost it in MSUs, and confirm the rating before you sign.

The trap is doing cost work in MIPS. A capacity team sizes the refresh in MIPS, the procurement conversation happens in MIPS, and the MSU effect, the part that actually moves the software bill, never surfaces. Vendors are under no obligation to point out that the new machine entitles you to a lower MSU rating, so the saving can quietly stay on the table.