Mainframe FinOps guide
What is Mainframe FinOps?
The discipline of applying FinOps principles to IBM z/OS — real-time cost visibility, automated optimization, and budget governance for Monthly License Charges.
Download the FinOps ebookMainframe FinOps is the practice of bringing financial operations (FinOps) discipline to IBM z/OS mainframe environments: real-time cost visibility, proactive budget control, and automated capacity optimization for one of enterprise IT’s largest and most opaque cost lines, Monthly License Charges (MLC).
For organizations running mission-critical workloads on IBM mainframe, software costs can reach tens of millions of dollars a year. Yet most teams only see those costs at month-end, after the billing peaks have already formed and the chance to optimize has passed.
Mainframe by the Numbers
68%
of global production IT workloads run on mainframe
Broadcom
90%
of global credit card transactions processed on mainframe
IBM
30–50%
of total mainframe budget is MLC software
BMC
5–20%
MLC reduction achievable through active FinOps
Zetaly customer data, 30+ enterprise deployments
What is Mainframe FinOps?
The FinOps Foundation’s 2025 framework update formally extended FinOps scope beyond public cloud to data centers and licensing, recognizing that the same principles of visibility, accountability, and optimization that reshaped cloud cost management apply just as well to IBM z/OS (FinOps Foundation — 2025 Framework Update; Scopes). Mainframe FinOps uses these principles to address the unique billing rules of IBM software contracts.
The core problem is structural: IBM mainframe software is billed on peak processing consumption, not average usage. A single workload spike during month-end batch can set your software bill for the entire month. Without real-time visibility and active management, organizations often pay more than they should.
Why mainframe needs its own FinOps practice
Cloud FinOps tools like AWS Cost Explorer and Cloudability do not work for mainframe environments. The cost structure, the billing model, and the optimization levers are all different.
| Dimension | Cloud FinOps | Mainframe FinOps |
|---|---|---|
| Cost unit | vCPU hours, GB-months, API calls | MSU (Millions of Service Units) |
| Billing model | Pay-per-use, on-demand or committed | Subscription contracts (AWLC, TFP) |
| Key billing metric | Resource utilization, spend rate | R4HA (Rolling 4-Hour Average) |
| Visibility | Near-instant via cloud console | Typically day+1 or month-end via SCRT |
| Primary optimization lever | Eliminate waste — turn off unused resources | Manage billing peaks, optimize LPAR defined capacity |
| Primary risk | Runaway spend on unused resources | Billing peak overruns, contract non-compliance |
| Tool ecosystem | Mature — 100+ vendors | Specialized — few purpose-built solutions |
The key difference: cloud FinOps is mostly about eliminating waste while mainframe FinOps is mostly about managing billing peaks and optimizing capacity allocation whitin IBM’s contractual pricing rules.
IBM MLC pricing models: AWLC and TFP
To practice mainframe FinOps, you need to understand how IBM mainframe software is priced. Two MLC pricing models are available to new customers today, and each calls for a different optimization strategy.
AWLC — Advanced Workload License Charges
This is IBM’s standard sub-capacity pricing model. Your bill is calculated from the Rolling 4-Hour Average (R4HA), which is the highest average MSU consumption across any four-hour window in the month, measured for each LPAR. A single workload spike can set your R4HA for the entire month (IBM Z Pricing & Licensing).
TFP — Tailored Fit Pricing
IBM’s newer enterprise pricing model, offers either consumption-based or fixed-capacity pricing based on a contracted MSU baseline. Under TFP, the focus shifts from peak prevention to controling total consumption. this approach is predictable, but only if it is actively managed (IBM — Tailored Fit Pricing for IBM Z).
Organizations moving from Country Multiplex Pricing (CMP), a legacy AWLC option for multi-data-center environments, to TFP often find MLC reductions of up to 20%.
A note on SCRT and SMF: every IBM mainframe billing calculation uses SMF (System Management Facilities) data, which SCRT (Sub-Capacity Reporting Tool) processes into the monthly sub-capacity report that determines your charges. Any mainframe FinOps tool must use the same SMF data as SCRT (IBM — About the Sub-Capacity Reporting Tool).
Free playbook
Going deeper on Tailored Fit Pricing?
Our independent 35-page TFP playbook covers the considerations before you sign and the strategies to optimize once you’re in, including how to lower your baseline before the transition.
Where the mainframe budget goes
For most enterprises, the mainframe is one of IT’s highest single-vendor cost lines, with most costs for software, not hardware. Monthly software license fees make up 30–50% of the total mainframe budget, making it the largest line in the operating budget (BMC; HCLTech). That is why FinOps efforts start with software costs.
The three pillars: Visibility, Optimization, Governance
A mature mainframe FinOps practice rests on three pillars, which match the FinOps Foundation’s Inform, Optimize, and Operate lifecycle.
Pillar 1
Visibility
Know where every MLC dollar comes from, by LPAR, application, and business unit, in near real time rather than at month-end. Without visibility, optimization is guesswork. This is what Zetaly Service Intelligence (ZSI) delivers: cost attribution built on your own SMF data.
Pillar 2
Optimization
Actively reduce cost by dynamically managing LPAR defined capacity against live workload demand and WLM (z/OS Workload Manager) service-class priorities, without sacrificing performance. Static soft capping sets a fixed limit, while dynamic soft capping continuously redistributes capacity across LPARs in real time. That difference can mean the difference between a 2% saving and a 15% one.
Pillar 3
Governance
Stay compliant with IBM contracts, track budget against actuals, allocate costs to business units, and prevent overruns before they happen rather than after the invoice arrives.
Maturity model: 4 stages
Most mainframe FinOps programs progress through four stages. Your current stage shows both your risk and your optimization opportunity.
Stage 1
Reactive
Costs reviewed monthly at invoice time with no real-time visibility. This is where most organizations start, and where budget is quietly lost.
Stage 2
Aware
Near-real-time MSU monitoring in place, budget alerts configured, finance teams receiving cost data. Billing surprises become less frequent.
Stage 3
Active
LPAR capacity managed dynamically and automatically. This is where the 5–20% MLC reduction typically appears.
Stage 4
Strategic
Mainframe FinOps informs IBM contract negotiations, modernization roadmaps, and migration prioritization. Cost forecasting is model-driven, not reactive.
What savings look like in practice
Across 30+ enterprise deployments, Zetaly customers typically see a 5–20% reduction in Monthly License Charges through dynamic LPAR capacity optimization, with no impact on service quality. For a large company running $50M a year in MLC, that means $2.5M–$10M in annual savings.
“With Zetaly Automated Capacity, Orange has found a game-changing solution. We can now navigate the price increases of our software portfolio for the next two years without any impact on performance.”
— Stéphane Rousset, Mainframe Manager, Orange
FinOps during cloud migration
If your organization is planning to move some or all mainframe workloads to cloud, mainframe FinOps matters even more during that transition. Complex mainframe migrations commonly take three to seven years, with both environments running in parallel throughout, and mainframe costs often reach their peak. FinOps helps in three ways during this period:
Fund the migration
MLC savings from optimization free up budget to invest in the cloud build-out.
Inform sequencing
Per-workload cost visibility answers "which applications are worth migrating first?" A workload costing $50K a month on the mainframe is a different priority from one costing $5K.
Prevent dual-paying
Without active monitoring, residual mainframe dependencies keep costs high even after workloads have nominally moved to the cloud.
For the full migration decision, see our Mainframe to Cloud Migration guide: Pros, Cons, and What Actually Happens.
Mainframe to Cloud MigrationKey roles in a mainframe FinOps practice
Mainframe FinOps is cross-functional. The main challenge to progress is not technology, it is the organizational gap between mainframe operations and IT finance.
Mainframe Systems Programmer
Manages z/OS configuration, LPAR settings, and defined capacity parameters.
Capacity Planner
Forecasts future workload growth and models the cost impact of changes.
z/OS Performance Analyst
Monitors WLM service class goals and identifies optimization opportunities.
IT Finance / Cost Manager
Owns the mainframe budget and translates MSU consumption into business costs.
Application Owners / Business Unit Leaders
Accountable for the cost of the workloads they run.
FinOps Practitioner
Orchestrates the practice across all stakeholders and drives cultural adoption.
Key terms
New to the terminology? Our glossary covers every term in detail. Quick reference: AWLC, CMP, CPC, Defined Capacity, Dynamic Soft Capping, IPLA, LPAR, MLC, MSU, R4HA, SCRT, SMF, Soft Capping, TFP, WLM, zNALC, Parallel Sysplex.
Mainframe FinOps GlossaryFrequently Asked Questions
What does FinOps for mainframes entail?
Mainframe FinOps involves applying financial operations (FinOps) principles to IBM z/OS mainframe environments, and it achieves this by combining real-time cost visibility, automated capacity optimization, and budget governance in order to introduce financial accountability for spending on the Monthly License Charge (MLC), which is one of the largest and most complex cost areas in enterprise IT.
How is mainframe FinOps different from cloud FinOps?
A cloud FinOps approach deals with the variable computing costs associated with public cloud services, since resources can be switched off instantly and the costs are visible almost in real time. Mainframe FinOps, on the other hand, involves IBM-specific contracts ( AWLC and TFP), the use of rolling-average billing, and the management of LPAR-defined capacity, which is based on a different cost model and therefore requires specialized tools. Tools designed for cloud FinOps are not suitable for use in mainframe environments.
What are Monthly License Charges (MLC) on IBM mainframe?
The monthly license charges (MLC) are the recurring fees that IBM charges for mainframe software and are calculated based on the amount of MSU (Millions of Service Units) used. The way in which the charges are determined varies according to the contract; under AWLC the Rolling 4-Hour Average (R4HA) per LPAR is used, while TFP uses the total MSU consumption against a contracted baseline. Typically, the MLC accounts for 30 to 50 per cent of an enterprise's total mainframe budget.
What does MSU stand for?
An MSU (Millions of Service Units) is the unit that IBM uses for measuring the processing capacity of mainframes; it refers to the quantity of useful work that a processor is capable of carrying out, and actual MSU consumption forms the basis of most mainframe software billing.
What constitutes an LPAR and why is it important for FinOps?
A logical partition (LPAR) is a virtualized version of an IBM mainframe, each having its own allocated capacity in units of MSUs. Billing is generally based on the LPAR level, and therefore the way capacity is distributed among the LPARs has a direct impact on your software costs. For the purpose of effective FinOps it is necessary to actively manage the defined capacity of the LPARs in order to avoid unnecessary spikes in billing while at the same time ensuring that the performance of critical workloads is maintained.
What is the difference between AWLC and TFP?
The AWLC system is based on the highest 4-hour rolling average of MSU usage per LPAR over the course of the month, with the main aim being the prevention of peaks; in contrast, the TFP system provides either consumption-based or fixed-capacity pricing relative to a contracted MSU baseline, thereby making total consumption control the main objective. Since each model requires a different optimization strategy and different tooling.
What is SCRT and why is it important?
The SCRT (Sub-Capacity Reporting Tool) is the tool that IBM uses to process SMF utilization data to generate the sub-capacity report on which your MLC charges are based; the SCRT reports are sent to IBM monthly. For someone engaged in mainframe FinOps, it is essential to understand the data that is fed into the SCRT since any cost optimization tool must rely on the same SMF data.
What does soft capping on a mainframe entail?
A soft capping method restricts the capacity allocated to an LPAR (in terms of MSUs) as a means of managing software billing. With traditional soft capping, a fixed upper limit is set for each LPAR; dynamic soft capping, on the other hand, constantly modifies these ceiling values for all LPARs in response to the current level of workload demand, allowing it to absorb sudden increases in load on important LPARs while still remaining within the overall billing targets, thus eliminating the compromise between performance and cost that is associated with static methods.
How much can mainframe FinOps reduce software costs?
In more than 30 enterprise deployments, Zetaly customers generally see a reduction in their monthly license charges by between 5 and 20 per cent as a result of dynamic LPAR capacity optimisation, without any effect on service quality. The figures are based on data from Zetaly customers; results will differ according to the environment, and we advise checking the estimated savings against your own SMF data before deciding to adopt the platform.
How long does it take to implement mainframe FinOps tooling?
Contemporary mainframe FinOps tools are designed for rapid deployment; ZAC can be deployed in one week and produces tangible results from the first day. Full organizational maturity, such as cost allocation by business unit and proactive governance, generally takes between one and three months to achieve.
What is the difference between MLC and IPLA?
The monthly license charges (MLC) are regular monthly fees charged for the core mainframe software (z/OS, Db2, CICS, IMS, IBM MQ). The International Program License Agreement (IPLA) involves a one-off charge together with an annual subscription and support, usually applying to tools and utilities. Both of these factors make up the total cost of mainframe software, and a full FinOps practice takes both into account.
Is mainframe FinOps relevant if we are modernizing or moving to cloud?
Yes, in fact, and for the majority of organizations this is even more true. Migrations from mainframes to cloud take a long time, and during that period the mainframe costs continue to be incurred, frequently reaching their peak levels since parallel environments are kept up. Mainframe FinOps finances migration by producing cost savings from the current environment, determines the order of migration using accurate per-workload cost data, and avoids the problem of paying twice by identifying any remaining mainframe costs after the workloads have supposedly been migrated.
Start Your Mainframe FinOps Journey
Know what your mainframe costs.
Then reduce it.
Whether you’re looking to understand your costs for the first time or ready to actively reduce MLC spend, Zetaly covers both — with tools that deploy in a week and deliver results from day one.