IBM's January 1, 2026 withdrawal of perpetual IBM i P20 and P30 licenses proved that a hardware refresh can retire entitlements you already paid for, unless a survival clause and a signed acknowledgement schedule say otherwise
Perpetual rights do not disappear by decree, they disappear by silence: an unlisted PID, a rebranded successor on a different metric, a divested product line, a 70:1 PVU-to-VPC trade-up that quietly closes out the old entitlement. IBM's own precedent (the E1080-to-E1180 serial-number upgrade that carries perpetual licenses forward) proves carry-forward is possible when a buyer asks for it. This article gives you the survival language, the acknowledgement schedule fields, and the exact moment in the deal cycle when IBM will concede them.
Prepared by Redress Compliance · September 10, 2026 · IBM advisory practice. ELA, Cloud Pak, and Power renewal engagements, 2024 to 2026.
Executive summary
The asset most buyers fail to defend is the one they already own outright: perpetual entitlements accumulated over 10 to 20 years, worth six to eight figures at replacement cost, extinguished in a single trade-up line item.
IBM presents the PVU-to-VPC conversion at a stated 70 PVUs to 1 VPC, frames it as administrative, and the paperwork that closes out the legacy entitlement rides in the same order as the new Cloud Pak subscription.
The withdrawal calendar is now the negotiation calendar: perpetual IBM i P05 and P10 went on May 7, 2024, P20 and P30 on January 1, 2026, Power10 end of marketing lands July 31, 2026, and Power9 S914/S922/S924 hit end of service January 31, 2026.
Every one of those dates is a forcing function IBM can use to argue that subscription is the only remaining path, which is precisely why the carry-forward language has to be signed before the refresh order is placed.
IBM has already conceded the principle you need, and it is on the public record.
The E1080-to-E1180 upgrade carries perpetual licenses forward via serial-number upgrade, and IBM revived serial number upgrades for Power11 on a limited basis, which means "perpetual cannot survive a hardware generation change" is a sales position, not a technical constraint.
The end-of-term position is decided entirely by what the agreement says survives, and most ELAs say nothing.
Accrued perpetual entitlements should survive termination and subscription elements will not, but where that distinction is undocumented, buyers reach the end of a three-year term holding materially less than they assumed with weeks, not quarters, to react.
A strong outcome is measurable: 100 percent of pre-conversion perpetual PIDs listed in a signed schedule, an explicit no-extinguishment covenant on trade-up, and a rebrand/successor clause that carries entitlement across any name, edition, or metric change at no incremental charge.
On a mid-sized Cloud Pak footprint of 50 to 200 VPCs listing at $1,000 to $2,800 per VPC per year, that schedule is the difference between negotiating from an installed base and negotiating from zero.
How a perpetual entitlement actually dies: the four conversion triggers
Perpetual rights rarely get taken away in a negotiation. They get closed out in an order. Four triggers do almost all the damage, and each one exploits a specific gap in the paper you already signed.
Withdrawal from marketing kills the ability to add capacity on the old metric, so growth forces you onto the new one. A hardware refresh moves the entitlement to a new serial and gives IBM a re-recording event.
A rebrand or successor product on a different metric converts the entitlement arithmetically (PVU to VPC ratios do the work no salesperson has to justify).
Divestiture moves the product out of IBM entirely, at which point your ELA survival language points at a counterparty that no longer owns the asset. The leverage point is that all four are foreseeable and dated. You can name them in the contract before they fire.
| Trigger | IBM event that fires it | Contractual gap exploited | Clause that closes it |
|---|---|---|---|
| Withdrawal from marketing | P05/P10 perpetual withdrawn May 7 2024; P20/P30 withdrawn Jan 1 2026 | No obligation to keep a perpetual PID orderable for growth | Continuity of supply: right to add on the original metric for the ELA term plus 24 months |
| Hardware refresh | Power9 S914/S922/S924 EOS Jan 31 2026; all Power10 EOM Jul 31 2026 | SWMA transfer no longer automatic on migration; entitlement re-recorded at new serial | Serial-number carry-forward on the E1080-to-E1180 precedent, written into the order |
| Rebrand or successor on a new metric | Security SOAR renamed twice inside ten months (Feb 2021, Dec 2021); Confluent close March 2026 | "Product" defined once, so the successor inherits the subscription terms | Definitional split plus a fixed conversion ratio ceiling agreed at signature |
| Divestiture | QRadar SaaS to Palo Alto Sept 5 2024, then EOL by the acquirer | Assignment clause silent on entitlement continuity post-transfer | Novation with equivalent-rights obligation, tied to your IBM assignment and divestiture protections |
The table shows the mechanics. What it cannot show is who signs. IBM's 4Q 2025 announcements added administrative feature codes specifically for IBM i conversion to subscription and for subscription transfer.
That means the conversion now travels as a line item on a hardware order, not as a contract amendment. In practice the person who approves it is a procurement operations analyst clearing a Power refresh PO, not the person who spent six months negotiating the ELA.
Treat any feature code that mentions conversion or transfer as a contract change requiring the same signature authority as the master agreement. Put that rule in writing internally before the refresh quote lands, because IBM will not flag it for you.
The survival clause: language that keeps accrued perpetual rights alive past term end
Survival language is cheap at signature and unbuyable at term end. Build it in three parts.
First, an express survival provision: "Perpetual Entitlements accrued prior to expiration or termination of this Agreement for any reason, including termination for cause, shall survive and continue in full force, and IBM shall record them without a valid_to date." Second.
A no-extinguishment covenant: "Customer's acceptance of any trade-up, upgrade, migration, replacement, conversion feature code, or successor offering shall not terminate, suspend, reduce.
Or offset any underlying Perpetual Entitlement unless Customer executes a separate written Relinquishment Acknowledgement identifying the affected PIDs and quantities." Third.
A definitional split so the agreement enumerates Subscription Products and Perpetual Products separately and never collapses them into a single defined term.
That third piece does the quiet work: once "Products" is undefined as a blended noun, every price, renewal, and termination clause has to specify which pool it touches.
IBM will counter three ways. The first is that trade-up terms are standard and non-negotiable.
Answer with their own precedent: E1080-to-E1180 carries perpetual licenses forward via serial-number upgrade, and IBM revived serial-number upgrades for Power11 on a limited basis, so carry-forward is a discretionary commercial decision, not a systems constraint.
The second counter is that the IPLA already governs perpetual rights, so a survival clause is redundant. Answer that the IPLA governs the license grant, not the entitlement record, and it is the record that drives support renewal and audit position.
If it is redundant, IBM loses nothing by signing it. The third counter is that IBM cannot maintain two entitlement records for one deployment. That is a reporting preference, not a legal limit, and it is the same objection you will meet when negotiating the broader set of ELA redlines.
Concede the reporting format, never the entitlement.
In our experience across IBM ELA and Power refresh negotiations, survival language is conceded far more readily at initial signature than at renewal, because at signature IBM is pricing new revenue and at renewal it is pricing your dependency.
If you are already inside term, the moment to force it is the next capacity add or hardware order, when IBM needs your signature more than you need theirs.
Cut your IBM ELA renewal with 8 buyer side levers
Eight buyer side levers that cut an IBM ELA renewal: the baseline reset, true forward exposure, product rationalization, and the Cloud Pak shift.
Get the white paper →The acknowledgement schedule: the fields IBM's own systems use, on IBM letterhead
A survival clause with no attached inventory is a promise about a set nobody agreed on. In twenty-five years of these fights, I have never seen a dispute about whether perpetual rights survive in the abstract.
The dispute is always about scope: which PIDs, which versions, how many PVUs, whether the 2013 purchase under an ICA predecessor form counts.
IBM's negotiators know this, which is why they will happily concede clean survival language in section 12 and then resist the schedule that makes it operational. Treat the schedule as the actual concession and the clause as the wrapper.
Build it from Proof of Entitlement reconciliation first: pull every PoE, match it against IBM's own entitlement extract (ask for it in writing, and expect a two to four week turnaround), and resolve every delta before anyone signs.
Any line you cannot evidence today is a line you will lose at term end.
| Schedule field | Why IBM's systems require it | Where the fight happens |
|---|---|---|
| PID / part number | The only identifier IBM order systems reconcile against | Withdrawn PIDs with no successor mapping |
| Program name and version | Distinguishes End of Marketing from End of Support scope | Rebrands (Resilient SOAR to Security SOAR to QRadar SOAR, twice in ten months) |
| License type (IPLA / ILAN / ICA) | Determines whether perpetual rights exist at all | Legacy ICA-era purchases IBM cannot locate |
| Quantity and metric (PVU, VPC, RVU, Authorized User, Install) | Fixes the conversion ratio ceiling | PVU-to-VPC trade-up ratios applied without cap |
| Acquisition date | Establishes pre-withdrawal standing (for example, pre-January 1, 2026 IBM i) | Undated or reconstructed records |
| SWMA status and expiry | Perpetual without SWMA cannot download upgrades or firmware | Lapsed lines IBM treats as forfeited |
| valid_to, billing frequency, renewal owner | Fields IBM now mandates on subscription records | Perpetual lines silently populated with a valid_to date |
Two mechanics decide whether the schedule holds. First, signature authority: the account rep cannot bind entitlement records, so the schedule must be executed by IBM contracting on IBM letterhead and referenced by exhibit number in the base agreement, not attached to an email thread.
Second, cadence: re-execute at every amendment, every renewal, and every hardware refresh order, because an unrefreshed schedule ages into irrelevance the moment a PID is withdrawn.
The same discipline you apply in the ELA redlines that decide the next three years applies here, with one addition: require IBM to confirm in the schedule that no perpetual line carries a valid_to value.
Analysis: IBM is not taking your perpetual rights, it is repricing the option to keep them
Start from IBM's economics rather than your own. A perpetual license, once sold, produces nothing. Its entire value to IBM is as an annuity anchor: it justifies SWMA at roughly twenty percent of a list price that was frozen at the original purchase, often a decade ago.
That is a low-yield annuity on a shrinking base. Subscription replaces it with the same customer, the same workload, and a full-freight recurring charge at current list. Nobody in Armonk decided that perpetual rights are wrong.
Somebody ran the arithmetic on yield per installed core and found a better number.
That reframing changes what you ask for, and it changes the tone. You are not asking IBM to walk away from revenue. You are asking IBM to keep charging you maintenance on an asset you already own. That is a live revenue stream, priced, invoiced, and forecastable. Say it that way in the room.
The moment your position sounds like "let us stop paying," the concession dies. The moment it sounds like "we will commit to SWMA on this schedule for thirty-six months if perpetual survives," you have handed the rep a number to put in a forecast.
The E1080-to-E1180 serial-number upgrade tells you everything about how this decision gets made. Perpetual carry-forward exists on that path, on a limited basis, because the hardware attached to it is large enough to justify the exception. The concession is priced, not principled.
There is no IBM doctrine that says perpetual must die on refresh; there is a threshold above which protecting it is worth doing. Your job is to find where your deal sits relative to that threshold and, if it sits below, to add enough hardware, enough term, or enough SWMA commitment to cross it.
The Customer Value Agreement is where the distinction gets quietly dissolved.
Bundle several products under one subscription commitment and the perpetual-versus-term line stops existing at the contract level, not because anyone converted anything, but because the commitment document became the operative instrument and it has one term and one expiry. 2026 is a CVA push year.
If you sign one without carving your perpetual estate out into a named, surviving schedule, you have converted by consolidation. That is the same structural trap as an unmanaged Cloud Pak bundle, and it is why substitution and swap rights need to name what cannot be swapped, not just what can.
QRadar is the limit case, and it is the one to raise when IBM's counsel says survival language is over-lawyered. The SaaS lines were divested to Palo Alto Networks in September 2024, and the acquirer subsequently declared End of Life on what it bought.
Your counterparty changed, then your product ended. Survival language that binds only IBM protects nothing in that scenario. It must bind successors and assignees, and it must survive assignment without your consent.
The asymmetry is the whole argument. IBM's cost of granting continuity is a database field and a signature. Your cost of losing it is the replacement value of the estate, plus migration, plus the negotiating position you no longer have.
Read the E1080-to-E1180 exception as a price list, not a policy. IBM already knows how to carry perpetual entitlements forward through a machine replacement; it does so where the transaction justifies the administrative work.
Your leverage is therefore about deal size and timing, not about whether IBM believes in perpetual licensing.
Which means the question in the room is not "will IBM allow this," it is "what does this deal need to look like for IBM to allow it," and that is a question with a number attached.
Pricing the concession: what carry-forward is worth and what IBM will trade for it
Price the concession before you ask for it, because the asymmetry is the whole argument.
A 200 VPC perpetual estate replaced at current list runs roughly $200,000 to $560,000 per year in subscription equivalent (VPC list commonly lands between $1,000 and $2,800 depending on the Cloud Pak or product family).
So a three-year term with continuity language protects between $600,000 and $1.7 million of value that you have already paid for once.
The number that matters more is the negotiating floor. Every renewal you enter holding perpetual entitlements plus SWMA is a renewal where the walk-away is "keep running what I own and drop support," and IBM prices against that reality.
Convert the estate and your floor becomes zero, which is why the second renewal after conversion is where the uplift arrives. On IBM's side, the cost of granting continuity is a records entry: a PID, a version, a license type, and no valid_to date.
Nothing is manufactured, no discount is surrendered, no quota is affected.
Cheap concessions are reachable concessions, and this one sits with the contracts desk rather than with pricing approval, which is precisely why it is winnable late in a quarter when the deal desk wants signature more than it wants the clause.
Expect IBM to treat continuity as tradeable rather than free.
The standard menu is a longer term (four or five years instead of three), CVA consolidation that pulls scattered part numbers under one subscription commitment, a growth commitment on watsonx or Cloud Pak capacity, or a ramped spend curve that back-loads the increase.
Term length and a ramp are acceptable currency: they cost you flexibility you can price and cap elsewhere with termination for convenience and reduction rights.
CVA consolidation as payment for continuity is not acceptable, because it dissolves the very PID-level records the continuity language depends on. Neither is a growth commitment that funds the concession with new spend you had not planned.
A strong outcome reads in three numbers. Continuity and survival language at zero incremental fee.
Conversion ratios documented per product with a floor, rather than a blanket ratio (we routinely see 70:1 PVU-to-VPC applied across unrelated families, which silently retires capacity on the products where the true ratio is more favorable).
And a written trade-up credit that carries at least SWMA-equivalent value forward for the full agreement term, so a hardware refresh or successor product move never resets your paid-up position to zero. Ask for all three in the same redline pass; they defend each other.
Evidence base: what we see in IBM ELA and Power refresh engagements
In that share of our engagements the customer cannot produce a complete PoE set, so building the acknowledgement schedule itself recovers entitlements nobody was tracking.
IBM Resilient SOAR became IBM Security SOAR on February 18, 2021, then IBM Security QRadar SOAR on December 7, 2021.
The recurring pattern is that conversion almost never arrives as a licensing negotiation. It arrives inside a hardware order, where the reviewer is a procurement analyst validating feature codes rather than a licensing lead reading survival language.
IBM's 4Q 2025 announcements added administrative feature codes specifically for IBM i conversion to subscription and subscription transfer, which means the conversion now happens at the order line. Second pattern: the entitlement record itself is the weak point.
IBM's Power software migration policy already documents no Capacity Credits for AIX or IBM i under side-by-side migration, and parked licenses on a donor machine showing as Software Base Capacity until activated on the target.
That is a documented state in which you own something the system does not currently credit you for, and it resolves in IBM's favor by default.
Third pattern: the counterparty moves. QRadar SaaS was divested to Palo Alto Networks on September 5, 2024, and Palo Alto subsequently announced End of Life on the acquired products while IBM continued supporting on-prem.
Anyone whose continuity language named IBM rather than IBM and its successors and assigns lost the argument on jurisdiction alone, which is why this clause pairs with assignment and divestiture protection rather than standing alone. Fourth: acquisitions repackage.
Confluent closed in March 2026, existing licenses remain valid, and entitlement changes are expected at the next renewal as SKUs integrate with watsonx. That is the template for the next three years.
This piece protects assets you already hold. The pricing side sits with the ELA clause work and the uplift cap; the flexibility side sits with swap and substitution rights and with termination and reduction. Read them together, because IBM does.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Freeze the inventory before you take the meeting (target: complete by day 10). Pull every Proof of Entitlement, reconcile PID plus version plus license type (IPLA, ILAN, ICA) against your actual Power estate, and issue the reconciled list to IBM as Draft Schedule A, because once a Power11 quote is on the table IBM controls the entitlement narrative and you are arguing from their extract, not yours.
- Impose an internal standstill on trade-ups, feature codes, and migration orders (effective immediately, lifted only by signature). The 4Q 2025 administrative feature codes for IBM i subscription conversion and subscription transfer mean a single order line can close out a perpetual record, so no procurement release, no SWMA transfer request, and no side-by-side migration form goes out until the survival clause is agreed in writing.
- Table survival language and the acknowledgement schedule as one non-severable package alongside price (not after). In our experience IBM concedes continuity language when it is a condition of the hardware order clearing, and concedes almost nothing once the server is on the dock; make the three-part clause and Schedule A a signature condition, referenced in the core ELA redlines you are already running.
- Demand per-product conversion ratios in writing and cite IBM's own precedent. Get every PVU-to-VPC and perpetual-to-subscription ratio stated numerically per PID, and anchor the ask on the E1080-to-E1180 serial-number upgrade, where perpetual licenses carry forward, proof that carry-forward is an IBM capability, not a customer fantasy.
- Bind successors and assignees, then re-execute the schedule at every amendment. QRadar SaaS moving to Palo Alto in 2024 is the live proof that a divestiture can strand you, so pair this with your assignment and divestiture protections and set hard internal dates against Power9 end of service on January 31, 2026 and Power10 end of marketing on July 31, 2026.
Frequently asked questions
Does accepting an IBM trade-up from PVU to Cloud Pak VPC cancel my perpetual license?
In most cases the trade-up paperwork closes out the legacy entitlement, because IBM's framing is that PVU licenses are traded up or upgraded to Cloud Pak VPC licenses rather than run alongside them.
Nothing forces that outcome contractually if you insert a no-extinguishment covenant stating that acceptance of a trade-up does not terminate or reduce the underlying perpetual entitlement absent a separate signed relinquishment.
Get the covenant agreed before the order is placed, because reversing a closed-out entitlement after the fact is effectively a repurchase.
Are my existing IBM i perpetual licenses still valid after the January 1, 2026 withdrawal?
Yes. IBM withdrew perpetual IBM i P20 and P30 tier licenses from the price list effective January 1, 2026, following P05 and P10 on May 7, 2024, but entitlements bought before those dates remain usable.
The exposure is transfer, not validity: transfer rights on those pre-withdrawal perpetual entitlements are restricted, and IBM tightened SWMA transfer rules at the same time, so a Power migration that previously triggered automatic SWMA transfer may now require contract review.
What is the 70 PVU to 1 VPC conversion ratio and should I accept it?
IBM presents 70 PVUs to 1 VPC as the common baseline for converting legacy entitlements into Cloud Pak capacity, but IBM's own guidance is that the ratio depends on the product and the situation. A blanket 70:1 may leave you short on some products and over-entitled on others.
Negotiate the ratio per product, documented in the agreement, rather than accepting a single number applied across the estate.
Can a hardware refresh carry perpetual licenses forward to new Power servers?
IBM has done it. The E1080-to-E1180 upgrade path carries perpetual licenses forward via a serial-number upgrade, and IBM revived serial number upgrades for Power11 on a limited basis.
That precedent is the strongest argument you have: continuity across a hardware generation is a commercial decision IBM already makes for some accounts, not a technical impossibility, so ask for it explicitly and cite the precedent.
What should the entitlement acknowledgement schedule actually contain?
Mirror the fields IBM's own systems use so there is no reconciliation dispute later: PID, program name, version, license type (IPLA, ILAN, or ICA), quantity, metric, acquisition date, and SWMA status with expiry.
For anything recorded after the 2026 change, add valid_to date, billing frequency, and renewal owner, since subscription records now require them while perpetual records historically carried no expiration.
Have it signed by IBM contracting, attached to the agreement, and re-executed at every amendment and renewal.
What happens to my entitlements if IBM divests or rebrands the product?
Both have happened recently. IBM divested QRadar on Cloud SaaS to Palo Alto Networks effective September 5, 2024, and Palo Alto subsequently announced end of life for the acquired SaaS products, while IBM Resilient SOAR was renamed twice inside ten months.
Your survival and continuity language must therefore bind successors and assignees, and must carry entitlement across any change of name, edition, packaging, or metric at no incremental charge.
Is an IBM CVA a threat to perpetual entitlements?
It can be. The Customer Value Agreement bundles multiple products under a single subscription commitment, and 2026 is a push year with IBM sales actively pitching conversions.
The consolidation genuinely reduces administrative sprawl, but it also dissolves the perpetual versus term distinction at the contract level and locks in spend.
If you move to a CVA, insist that pre-existing perpetual entitlements are enumerated in an annex, expressly excluded from the subscription commitment, and stated to survive CVA expiry.
