The AWLC vs TFP decision is now front of mind for most mainframe leaders. When IBM introduced Tailored Fit Pricing in May 2019, the headline message was simple: predictable costs, aligned with how modern workloads actually behave. No more managing peaks. No more invoice surprises. Choose your container, sign a multi-year contract, and stop optimizing the rolling 4-hour average.
That’s all true. And for many organisations, TFP is the right move.
But IBM’s documentation tends to understate one side of this transition: what you give up when you stop managing peaks. Before you walk into that negotiation, or before IBM walks into yours, you need to understand both sides of the equation.
What actually changes when you move from AWLC to TFP
Under AWLC (Advanced Workload License Charges), IBM calculates your software bill based on the highest Rolling 4-Hour Average (R4HA) of MSU consumption during each billing period. The R4HA is the number that matters — and the entire discipline of mainframe cost management under AWLC revolves around controlling it. Soft capping, workload scheduling, WLM tuning, dynamic capacity allocation — all of these reduce your R4HA and, by extension, your bill.
Under TFP’s Software Consumption Solution, the billing model shifts fundamentally. Instead of charging based on peak consumption, IBM charges based on cumulative MSU consumption over the year. You agree to an annual MSU commitment at the start of the contract and pay 1/12 of that commitment each month — regardless of what you actually consume in any given month.
This sounds simpler, and in many ways, it is. But it changes the economics of every decision your mainframe team makes.
The honest trade-offs
Most content about TFP reads like IBM’s own marketing. Here is a more balanced view.
| ✓ Advantages | ✗ Trade-offs |
| Predictable fixed monthly cost, same bill every month for the contract term | No cost-reduction lever post-signature, soft capping no longer reduces your bill |
| No peak-period pressure, batch workloads run when the business needs them | 3–5 year commitment with a baseline that tends to rise, not fall |
| Growth at 50% of base price, incremental MSUs are significantly cheaper | IBM negotiation is complex and time-pressured, preparation is critical |
| Development environment expansion without proportional cost increaseBetter fit for spiky, API-driven, or hybrid cloud workloads | Baseline locked to your last 12 SCRT reports, optimize before IBM calls |
| Consumption overruns billed at year-end, monitoring becomes essential |
The trade-off that matters most: losing your cost-reduction lever
Under AWLC, you can actively influence your IBM bill. Deploy dynamic soft capping, optimize your WLM policies, shift batch workloads, and reduce your R4HA; your SCRT reports reflect it, and your bill follows. Year after year, disciplined teams can drive MLC costs down.
Under TFP, that lever no longer exists. Your monthly payment is fixed from day one of the contract. You can’t reduce it by managing consumption during the contract term. The Software Consumption Solution bills on cumulative MSUs; whether you run those workloads at 3 am or 3 pm doesn’t affect your annual total.
This isn’t a reason to avoid TFP. It’s a reason to be clear-eyed about the shift: cost management under TFP happens before you sign, not after. The organization that enters TFP negotiations with an already optimized environment gets a lower baseline and pays less over the full term. The one that transitions without that preparation locks in whatever it was consuming.
Key insight: Under AWLC, you manage costs in real time. Under TFP, you negotiate costs once and live with that number for 3 to 5 years. The pre-signature window is when your cost management work actually matters.
Is TFP right for your organisation?
The answer depends on your workload profile, your engineering capacity, and how much preparation you’ve done or have time to do before IBM starts the baseline conversation.
| TFP is a good fit if… | AWLC may still make sense if… |
| Workloads are increasingly spiky and unpredictable, real-time, API-driven, digital services | Strong workload management discipline with consistently low R4HA peaks |
| Investing in new mainframe applications with predictable growth budgeting | Stable, predictable, batch-dominated workload profileWithin 12–18 months of significant infrastructure changes |
| Peak management is consuming engineering time with diminishing returns | Pre-transition optimization work has not yet been done; sign after, not before |
| Planning significant expansion of your development and test environment | Contract flexibility is more important than billing predictability |
| Moving toward hybrid cloud with more variable workload patterns |
One signal worth watching: if your workload profile is getting harder to manage under AWLC (more real-time transactions, more API integrations, more unpredictable demand) TFP’s consumption model will likely reduce operational friction even if the absolute cost is similar. Conversely, if your team has invested heavily in AWLC optimization and is still seeing results, the case for switching is weaker.
The single most important factor: your pre-transition window
IBM uses your last 12 Sub-Capacity Reporting Tool (SCRT) records to establish your Software Consumption Solution baseline. Your cumulative annual MSU production consumption becomes the starting number for your contract, and your monthly payment is based on it.
That means the 12 months before your IBM negotiation are the highest-leverage period in the entire TFP journey. Every reduction in MLC consumption you achieve during that window directly lowers the price you will pay for the next 3 to 5 years. Every month you delay that optimization work is a month of higher baseline locked into a long-term contract.
The fastest method with the lowest operational risk is dynamic soft capping: deploying automated capacity management to allocate LPAR resources based on actual business activity rather than statically defined capacity limits. Unlike manual scheduling approaches, this requires no change to batch job timing and has no impact on service levels. Results appear within the first monthly SCRT cycle.
For organizations on CMP, the same principles apply, with one additional advantage: because CMP pools capacity across multiple systems in a country multiplex, automated resource sharing has more LPARs to work with, which typically produces a larger percentage reduction in the MLC baseline before transition.
If you take one thing from this article, before you speak to IBM about TFP, give yourself at least 12 months of optimized SCRT data. The baseline IBM calculates from those records is the number you will negotiate around and live with for the entirety of your contract.
Download our TFP ebook (IBM Tailored Fit Pricing, considerations & strategies) in which we cover the full optimization approach including a worked example of what an optimized vs. unoptimized transition looks like in practice
Frequently Asked Questions
AWLC vs TFP: what is the difference between them?
AWLC (Advanced Workload License Charges) bills based on the highest rolling 4-hour average (R4HA) of MSU consumption in each billing period, so cost management centers on controlling peaks. TFP (Tailored Fit Pricing), introduced by IBM in May 2019, bills based on cumulative MSU consumption over the year, divided into fixed monthly payments. Under AWLC, you can actively reduce costs by soft-capping and workload management; under TFP, your monthly bill is fixed at the start of the contract, and every MSU consumed counts toward your annual commitment regardless of when it runs.
Is TFP cheaper than AWLC?
Not automatically. TFP’s cost predictability is a genuine benefit, but the actual price depends on your negotiated baseline and the state of your environment when IBM calculates it from your SCRT records. Organizations that optimize their MLC costs before the IBM negotiation consistently enter TFP at a lower baseline, resulting in a lower contract price. Organizations that transition without this preparation lock in their current consumption level, which may be higher than necessary, for 3 to 5 years.
How does IBM calculate my TFP baseline?
IBM requests your last 12 Sub-Capacity Reporting Tool (SCRT) records at the start of TFP negotiations. Your cumulative annual MSU production consumption becomes the Software Consumption Solution baseline, and your average R4HA peak for development and test environments becomes the Dev/Test Solution baseline. We use both baselines to price your contract and project your committed growth volumes. This is why the 12 months before you sign are the most financially critical period of any TFP transition.
Can I still use soft capping to reduce costs after moving to TFP?
No, not in the same way. Under sub-capacity models like AWLC, soft capping reduces your R4HA peak and therefore your bill. Under TFP’s Software Consumption Solution, billing is based on cumulative MSU consumption, not peaks. Soft capping no longer reduces your annual cost once you are on TFP. It can help prevent Dev/Test container overruns, but it cannot reduce your core Software Consumption Solution cost after you sign. This is one of the most significant trade-offs to understand before committing.
What happens if I exceed my MSU commitment under TFP?
If your cumulative MSU consumption exceeds your annual commitment, IBM invoices the overage at year-end at growth pricing, typically 50% of your base price per MSU. Overruns are therefore more expensive than staying within your contracted volume and, unlike AWLC, cannot be managed away by adjusting peak consumption mid-year. Consumption projection tools that forecast your full-year MSU trajectory from year-to-date actuals are essential for catching overrun risk early.
How long is a TFP contract?
TFP contracts typically span 3 to 5 years, though IBM has shown more flexibility on shorter terms in recent negotiations. Length matters because your baseline, set at signing based on your last 12 SCRT reports, becomes the starting point for every subsequent contract renewal. A higher baseline locked in for 5 years costs significantly more than a lower baseline negotiated after a thorough pre-transition optimization effort. The contract duration makes the quality of your pre-signature preparation even more financially consequential.