The MSU Baseline, and How to Reset It, Explained.

An MSU baseline is the committed MSU figure that governs a consumption or capacity based mainframe contract. It sets the volume you pay for and the level above which growth charges or uplifts apply. Because it anchors the entire term, the baseline is usually the single most important number in the agreement, more important than the headline rate that buyers instinctively fight.

The pattern across vendors is consistent. The baseline is drawn from a reference period of recent consumption, and the reference period commonly leans on peak influenced months, which anchors the number high. This is true whether the contract is the IBM Software Consumption Solution, a Broadcom consumption model, or a capacity commitment with another publisher. Whoever chooses the reference period effectively chooses the baseline. So the reference period is a negotiation, not a given.

The same estate produces very different baselines depending on which months the vendor uses to set it. Here is one estate, three reference periods, three baselines, all defensible to the vendor and all costing the buyer differently.

Reference period	Baseline it yields	Who it favors
Peak influenced quarter	900 MSU	The vendor
Full year including peaks	760 MSU	Split
Validated steady state	640 MSU	The buyer
Spread across reference choice	260 MSU	The entire negotiation

Illustrative MSU figures. The same consumption data supports all three baselines depending only on the window chosen.

That 260 MSU spread is not a rounding difference. It is the whole economic gap, and it is decided by a choice of months before anyone discusses price. The vendor proposes the period that yields 900 and presents it as simply reading your data. It is reading a selected slice of your data. The buyer's job is to insist the reference period reflects validated steady state consumption, not the busiest quarter of a year you may never repeat.

Resetting a baseline is a sequence, and each step only works if the one before it is done. Walk it in order.

• Step 1 · Is the estate optimized? If not, optimize first. Remove avoidable MSU through capping, workload placement, and offload before anyone fixes a baseline, so the commitment lands on a lean estate, not an inflated one.
• Step 2 · Is the consumption validated? Reconcile the vendor's reference figure against your own hourly data. If they disagree, your validated number is the negotiating position, not theirs.
• Step 3 · Is the reference period fair? If it leans on peak influenced months, challenge it. Propose a window that reflects steady state, and make the vendor justify the one they chose.
• Step 4 · Is the timing right? Tie the reset to a renewal, a workload move, or a modernization that justifies a lower commitment. A baseline reset has the most leverage when there is a contractual reason to revisit it.
• Step 5 · Is there a future reset built in? Negotiate a true up or checkpoint so a later drop in consumption can lower the baseline again, rather than locking the high number for the full term.

Skip step 1 and every later step negotiates an inflated number. The order is the method.

The discipline is refusing to discuss the baseline until the estate is optimized and the consumption is validated. A buyer who arrives at step 3 having skipped steps 1 and 2 is arguing about the reference period for a number that was too high to begin with. Done in order, the reset moves the baseline toward validated steady state, and that is where the term's cost is decided.

Across 500+ engagements and $180M+ of negotiated mainframe spend, the baseline is where consumption and capacity contracts are won or lost, and it is consistently the number buyers under negotiate. The rate gets the attention; the baseline carries the cost. Reset it on validated data, before signing, and the rest of the contract is arithmetic. For the engagement built around this, see mainframe renewal advisory.