① Guide · Renewal advisory
A generation refresh resets nearly every capacity number your software is billed on. Handled as a hardware project, it quietly lifts the recurring license bill. This is the buyer side method for locking price protection into the move, before the first higher invoice lands.
The refresh is a hardware event. The bill it moves is software.
When an estate moves to a new generation, say from the IBM z16 to the z17, the conversation is dominated by the hardware: more capacity per MSU, faster engines, lower energy draw. What gets missed is that the same refresh resets nearly every number the software is billed on. Consumption patterns shift as workloads land on faster engines, installed capacity is commonly increased at the same time, and software charges that follow capacity and the rolling four hour average move with all of it. A refresh run as a pure infrastructure project routinely lets the recurring license bill drift upward in the background.
The buyer side discipline is to treat the refresh as a licensing negotiation in its own right and to write the price protection down before the box is ordered. The refresh, the renewal, and the price hold are strongest negotiated together, while the vendor still wants the hardware and the software deal as one. Read this with our capacity planning with software cost guide and our renewal advisory service.
Protection mechanism and what it locks · negotiate before the refresh, not after
| Mechanism | What it locks | Best for |
|---|---|---|
| Technology transition terms | A vendor offering that softens the charge across a generation move | IBM MLC estates refreshing to a new generation |
| Negotiated charge cap | A ceiling on the post refresh recurring charge | Estates where a capacity jump is planned |
| Fixed conversion ratio | The MIPS to MSU or capacity ratio held constant | ISV products billed on a converted capacity metric |
| Consumption based baseline | Charge reset to real R4HA, not installed capacity | Estates where installed capacity overstates usage |
| Multi year price hold | Unit pricing fixed across the term that spans the refresh | Refreshes that fall mid contract |
| Uplift cap on growth | A bounded escalator on capacity added later | Estates expecting workload growth after the move |
Availability and exact terms vary by publisher and contract; vendor transition offerings change over time and should be confirmed at the point of negotiation. The principle holds regardless: the protection is written before the refresh, not requested after it.
Fold the price hold into the same negotiation as the hardware and the renewal. The vendor wanting all three together is your leverage; splitting them lets the hardware close first and the software protection arrive too late. One event, one negotiation.
The hardware deal is leverage on the software.
Use the refresh as the moment to reset the charge basis to your real rolling four hour average rather than installed capacity. A refresh that lands on a consumption baseline rather than an inflated installed one can lower the recurring bill even as capacity rises.
Anchor the new bill to real usage.
Where a capacity increase is planned, negotiate a ceiling on the post refresh recurring charge and a bounded escalator on any capacity added afterward. The cap turns an open ended capacity jump into a known, contracted cost.
Turn the capacity jump into a known number.
ISV products billed on a converted capacity metric can drift when the generation changes the conversion. Fix the MIPS to MSU or capacity ratio in writing so a faster engine does not quietly reprice tools that did nothing but move boxes.
A faster engine should not reprice your ISV tools.
④ The timing that decides it
Before the box is ordered, the price hold is a term. After, it is a favor. Negotiate the refresh and the renewal as one event.
Typical reduction negotiated on renewal spend
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
It resets nearly every number the software is billed on. A new generation like the z17 gives more capacity per MSU, shifts consumption as workloads land on faster engines, and is when installed capacity is often raised. Charges that follow capacity and the rolling four hour average move with all of it.
Contractual protection that fixes the basis of your software charge across the refresh. It can be a vendor technology transition offering, a negotiated cap, a fixed conversion ratio, or a baseline reset to real consumption. The common thread is that it is written before the refresh, not requested after.
Before the hardware decision is final, folded into the same negotiation as the renewal. Once the box is ordered the leverage from the vendor wanting the hardware and software deal together is gone, and you are negotiating against an invoice that has already moved.
Yes. ISV tools billed on a converted capacity metric can reprice when the generation changes the conversion. Fix the ratio in writing. The same refresh that protects the IBM stack should protect the Broadcom and BMC tools that ride the same boxes. See our renewal advisory.
Related: capacity planning with software cost · sub-capacity vs full capacity · contract clauses that cost millions · renewal advisory service
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →