AWLC vs TFP: Should You Switch to IBM Tailored Fit Pricing?

By Jacky Hofbauer, Published May 2026, Last update May 2026

The AWLC (Advanced Workload License Charges) vs TFP (Tailored Fit Pricing) 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 optimising the Rolling 4-Hour Average.

That's all true. And for many organisations, TFP is the right move.

But there's a side of this transition that IBM's documentation tends to understate: 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, your IBM software bill is calculated from 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 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. 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.

The trade-off that matters most: losing your cost-reduction lever

Under AWLC, your IBM bill is a variable you can actively influence. Deploy dynamic soft capping, optimise your WLM policies, shift batch workloads and your R4HA drops, 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. There is no mechanism to reduce it by managing consumption during the contract term. The Software Consumption Solution bills on cumulative MSUs whether you ran those workloads at 3am or 3pm makes no difference to 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 organisation that enters TFP negotiations with an already-optimised environment gets a lower baseline and pays less for 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.

One signal worth paying attention to: if your workload profile is becoming 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 optimisation 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 derived directly from 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 static 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. Learn how Zetaly Automated Capacity (ZAC), a FinOps-focused solftware solution can help you toptimizes your mainfram capcity utilization. 

If you take one thing from this article: before you speak to IBM about TFP, give yourself at least 12 months of optimised 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.

We cover the full optimisation approach — including a worked example of what an optimised vs. unoptimised transition looks like in practice:

Frequently Asked Questions

What is the difference between AWLC and IBM Tailored Fit Pricing?

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 centres 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. Organisations that optimise their MLC costs before the IBM negotiation consistently enter TFP at a lower baseline, resulting in a lower contract price. Organisations 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. Both baselines are used 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. What it can do is help prevent Dev/Test container overruns — but it cannot reduce your core Software Consumption Solution cost post-signature. 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 the end of the year 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. The length matters because your baseline — established at signing from 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 optimisation effort. The contract duration makes the quality of your pre-signature preparation even more financially consequential.

About Zetaly

Zetaly builds mainframe FinOps software used by 60+ enterprises to control IBM Z costs. Our products serve customers across both IBM pricing models: Zetaly Automated Capacity (ZAC) reduces Monthly License Charges by 5–20% under AWLC by managing the Rolling 4-Hour Average billing peak in real time. Zetaly Data Platform (ZDP) and Zetaly Smart Insights (ZSI) give TFP customers near-real-time observability into mainframe consumption — at under 0.2% mainframe resource overhead — with dashboards organized for finance and line-of-business audiences.