① Explainer · Licensing concept
You turned the product off. The bill did not move. That is the default, not a billing error. Retiring software and capturing the credit are two separate jobs, and only one happens on its own. Here is how to make the saving actually land.
Switching software off stops you using it. It does not, by itself, stop you paying for it.
A decommissioning credit is the reduction in software cost you negotiate or claim when you permanently retire a product or capacity. The mechanic buyers miss is that the credit is rarely automatic. The bill is tied to the contract term and the committed capacity, not to whether the software is running, so turning a product off in production usually leaves the charge exactly where it was. License retirement is a separate, deliberate act: removing the product from the contract, from the billed portfolio, and from the SCRT report.
The credit can take several forms depending on the contract and metric: a lower committed baseline at renewal, removal of a product from the portfolio, a reduced MSU commitment, or a credit against other products. What they share is that they have to be timed and asked for. Retire mid term and the cost often strands until the next contract event. Retire into a renewal, where the baseline is being reset anyway, and the lower number locks into the new term. The worked recovery below shows the difference between a decommission that lands and one that does not.
Four products retired from production in the same year. Whether each one turns into a credit depends entirely on the contract event it was timed to and the trap that did or did not block it. Cost figures are an illustrative index.
| Product retired | Annual cost (index) | Timed to | Credit captured |
|---|---|---|---|
| ISV utility | 90 | Renewal, removed from portfolio | 90 |
| Reporting tool | 60 | Renewal, baseline reset | 60 |
| Bundled component | 45 | Mid term, inside a bundle | 0 |
| Legacy database | 75 | Mid term, minimum floor held | 0 |
Two retirements timed to the renewal captured the full cost, an index of 150. Two identical retirements taken mid term captured nothing: one was trapped inside a bundle whose price did not move, the other hit a minimum commitment floor. Same operational action, opposite financial result, decided entirely by timing and contract structure. The figures are illustrative; the pattern is what holds.
Converting a decommission into a credit is a sequence, and each step has a trap that silently zeroes the saving. The table pairs the step with the trap that defeats it. None of these is technical. They are contract and process failures, which is exactly why a retirement that looks clean to the systems team can land as no change on the invoice.
| Step | What it does | The trap |
|---|---|---|
| Time to a contract event | Aligns the retirement to a renewal or break | Mid term retirements strand the cost |
| Remove from SCRT | Stops the product billing on the report | Stale registration keeps it on the bill |
| Unbundle if needed | Separates the product from a fixed bundle price | Bundle price holds when one part is dropped |
| Reset the baseline | Locks the lower commitment into the new term | Minimum floors keep the baseline up |
| Reclaim stranded capacity | Adjusts the committed MSU after a downsize | Co term clauses freeze all products to one date |
Decommissioning credit behavior depends on the contract, the vendor, and the metric. These are patterns we commonly observe; the specific levers and traps vary by agreement and should be checked against yours.
License retirement runs through the SCRT report a product must be removed from, and it is the reverse of the MIPS creep that quietly grows the bill. It is also a direct lever on your cost per MSU, and it interacts with the subscription and support terms that a renewal carries. Timing retirements to capture the credit is the work on mainframe cost optimization and license negotiation.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Retiring products and want the credit to actually land? Time it to the renewal. Start here.
Usually not. Turning a product off in production stops you using it, but the license charge often continues, because the bill is tied to the contract term and the committed capacity, not to whether the software is running. Without an explicit step to retire the license, remove it from the SCRT report, and adjust the contract, you keep paying for software nobody uses. The decommission and the credit are two separate pieces of work, and only the first happens by default.
It is the reduction in your software cost that you negotiate or claim when you permanently retire a product or capacity. Depending on the contract and metric, it can take the form of a lower committed baseline at renewal, removal of a product from the billed portfolio, a reduced MSU commitment, or a credit against other products. The credit is rarely automatic. It is the result of timing the retirement to the contract and asking for it explicitly, with the evidence to back it.
At or before a renewal, when the baseline is being reset anyway and the vendor expects to negotiate. Retiring mid term, between renewals, often strands the cost until the next contract event, because committed terms do not flex downward on request. The retirement should be planned backward from the renewal date so the lower baseline is locked into the new term rather than left as a saving you keep paying for and never capture.
Several traps: minimum commitment floors that hold the baseline regardless of usage, bundle pricing where retiring one product leaves the bundle price intact, co term clauses that lock all products to one date, stranded capacity on a downsized machine, and a stale SCRT registration that keeps billing the retired product. Each is a contract or process issue, not a technical one, and each is why a retirement that looks clean operationally can land as zero saving on the invoice.