What IT Buyers Need to Know Before a Mainframe Refresh

Most mainframe storage refreshes begin with a notice. 

A support statement gets revised, a lifecycle date is published, a lease comes due, or a capacity report shows the estate crossing a threshold two years earlier than anyone planned for. A purchase that had been sitting comfortably in a future budget cycle now has to close in this one.

Under deadline pressure, the instinct is to buy the current generation of the platform you already run. It’s the fastest defensible option, requires the least internal justification, and preserves the existing operating model. But it can also preserve the same cost, capacity, and complexity constraints—so the same decision returns in five years against a larger data estate and a shorter planning runway.

A mandated refresh date, however, also creates a rare point of leverage: the budget is approved, the change window is being negotiated, and application owners know that the underlying infrastructure will change. Before the contract is signed, IT teams can use that moment to require vendors to document the assumptions, dependencies, and commitments behind their claims.

Future-casting During a Mainframe Refresh

For decades, people outside mainframe operations have described the platform as legacy. Yet mainframe applications remain embedded in transaction-intensive sectors. 

Reuters reported in July 2026 that IBM Z systems process millions of daily transactions across industries including banking and airlines, and separately described COBOL as widely used on IBM mainframes in banking, insurance, and government. When the mainframe is the designated system of record, its data is important to AI solutions that support or automate those business processes. But AI models and applications are only as reliable as the data used to ground their outputs. 

NIST’s AI Risk Management Framework identifies validity, reliability, accountability, transparency, security, and resilience as core characteristics of trustworthy AI, reinforcing the need to understand and govern the data used by AI systems. Mainframe applications remain important in transaction-intensive industries, but the share and value of data held on z/OS varies by organization and should be established from the customer’s own application and data inventory. While the conventional approach is to extract, transform, and store a copy on another platform, that approach creates greater risk when an AI application must answer a customer question in real time or initiate an automated action — because a copied dataset is a point-in-time representation whose age may not be visible to the application using it.

This is why a mainframe refresh deserves scrutiny beyond a conventional infrastructure replacement: the decision will affect not only current workloads, but also how the organization governs and uses authoritative data in the years ahead.

Read the Fine Print on Performance and Availability

Every published performance or availability figure reflects a specific workload, configuration, and test method. The Storage Performance Council publishes vendor-neutral benchmark specifications and independently reviews submitted results before acceptance. SPC-1 models predominantly random, mixed query-and-update activity, while SPC-2 addresses sequential workloads. Even standardized results apply only to the tested configuration and benchmark version, and vendor comparison materials may use different conditions. Mainframe buyers should treat any headline as a starting point, then ask for the workload profile, system configuration, measurement method, benchmark version, result status, and features enabled during testing.

For example, a headline IOPS figure may reflect a workload that differs materially from the system being proposed. Rather than assume one test pattern is common across all vendors, evaluate what the result actually represents. The Storage Performance Council separates workloads in SPC-1 from sequential workloads in SPC-2, illustrating why workload shape matters. SNIA likewise cautions that realistic flash-array testing should include relevant data patterns, read/write mixes, preconditioning, and enabled data-reduction functions; otherwise, results can overstate real-world performance. Without the block size, read/write mix, tested configuration, benchmark version, and data-reduction settings, the number is difficult to apply to the target workload.

When it comes to performance, vendors publish a figure which is an improvement over their previous generation rather than as an absolute figure. That can communicate generational progress, but it does not support direct comparison between suppliers. If the underlying measurement cannot be verified, the evaluation team must model performance using workload-specific evidence. Availability claims also require the same scrutiny because configuration differences can introduce significant cost and operational dependencies.

For availability, high-end platforms often publish in a series of nines. On a slide, the figures may look similar, but each additional nine reduces the allowable annual downtime by a factor of ten. Six nines corresponds to roughly 31.5 seconds of downtime per year; eight nines corresponds to roughly 0.32 seconds. The practical significance depends on what the figure measures, which events are excluded, and the configuration required to achieve it. Uptime Intelligence’s 2026 analysis illustrates the broader financial stakes of infrastructure outages: 57% of respondents said their most recent major outage cost more than $100,000, while one in five said their most recent impactful outage cost more than $1 million. 

The figures describe a set configuration, and very different configurations arrive formatted identically. Sometimes it is a single array reaching the number with nothing else required. Sometimes it is a replicated pair, which means buying, powering, cooling, and floor-spacing a second system to get the number being sold to you on the page. And sometimes it is a replicated pair plus orchestration software managing failover between them, which on the mainframe usually means IBM GDPS, a capable product carrying a real license cost, a real skills requirement, and a failover event that has to execute correctly under pressure.

A Design Target Is Not a Guarantee

Read a specification sheet rather than a comparison chart and you will find availability figures introduced by the phrase "designed for." That phrase describes engineering intent: how the system was built and what it should achieve in service, but no obligation whatsoever. 

A guarantee typically commits the vendor to a defined figure and states a remedy if applicable terms are not met. Its practical value also depends on eligibility requirements, exclusions, governing terms, and applicable law. Because enforceability turns on the actual contract and jurisdiction, no general industry statistic can substitute for legal review of the proposed terms. A headline guarantee without clearly documented coverage and remedies may offer little more practical protection than a design target. The number used in the evaluation and business case may therefore carry less obligation than it appears to.

Guarantee coverage can also vary by workload, protocol, configuration, and enrollment conditions. The only reliable way to determine whether protection applies to a mainframe workload is to read the governing terms and obtain written confirmation for the proposed configuration. A ratio or availability figure in a comparison table is not evidence of coverage unless the associated eligibility criteria, exclusions, and remedy are included.

That test applies to every vendor in this category, including the one publishing this. Check Hitachi Vantara’s the same way.

Predicting Effective-capacity Risk

Performance figures and availability commitments can be examined during an evaluation if the underlying conditions are disclosed. Effective-capacity risk is harder to detect because the shortfall may not become visible until years after deployment.

Effective capacity is raw capacity multiplied by an assumed data reduction ratio, and data reduction works by finding redundancy. How much it finds depends entirely on what your data looks like and the reduction methods applied. 

SNIA identifies data characteristics, access patterns, operational policies, and the specific reduction technology as factors that influence space savings; it also notes that predicting deduplication is materially harder than predicting compression. That evidence does not support one universal mainframe-to-open-systems ratio. The practical conclusion is to size from a representative sample of the customer’s DB2, VSAM, system, and virtualized data—with the proposed compression and deduplication settings enabled—rather than importing a generic ratio from another workload. An open-systems assumption may otherwise overstate what a specific mainframe estate will hold.

Supported capacity is a product- and protocol-specific limit, not an industry-wide constant. No credible independent cross-vendor dataset was found that establishes a general mainframe penalty on otherwise identical hardware. The defensible approach is therefore to compare each vendor’s current interoperability matrix, supported-configuration documentation, and written proposal for the exact mainframe and open-systems configuration under consideration. If the published ceilings differ, the business case should use the lower workload-specific limit rather than the platform headline.

The hardware may look identical, but the supported workload ceiling can still differ. That distinction must be verified in the vendor’s current documentation for the proposed configuration.

If a five-year mainframe refresh plan is sized against a platform headline rather than the supported limit and measured reduction behavior of the proposed workload, the shortfall may not appear during evaluation. It can surface later, when growth consumes the remaining headroom and the team must add capacity, deploy another system, or refresh earlier than planned. 

The exact timing is organization-specific; the controllable risk is the use of an untested assumption in the original business case.

A Better Way to Evaluate Vendors

The solution to this problem is not a more elaborate comparison chart, but a more disciplined evidence standard: start grading whether each vendor will document the conditions, dependencies, exclusions, and remedies behind the headlines.

That will address the recurring weaknesses described above without requiring the evaluation team to independently validate every vendor claim. Instead, ask:

1. What block size, read/write mix, workload profile, and system configuration produced the IOPS figure? Was data reduction enabled?
2. What configuration does the availability figure describe, and what additional hardware, software, licensing, or operational capability does it assume?
3. Is the availability figure a design target or a contractual commitment? What remedy applies if it is missed, and what eligibility assessment is required?
4. Which workloads and configurations does each guarantee cover, and where are the exclusions documented?
5. What are the maximum supported capacities for mainframe and open-systems workloads on the same hardware?
6. What is the usable raw capacity before any assumed data-reduction ratio is applied?
7. Can approved analytics and AI services access authoritative data in place, or does each use case require another extracted copy?
8. Will the next controller generation require a full data migration, and is the answer a written commitment or only a current design description?
9. Where are the governing terms, eligibility requirements, exclusions, and remedies documented?

None of those questions require you to be right about anything. They only require the vendor to be specific, in writing, in front of you, during the one period when they have every reason to be.

What Evaluation Looks Like for Mainframe IT Teams, in Practice

Put those questions into the day-to-day work of a mainframe team and they stop sounding like procurement hygiene. They become operational risk controls:

• Month-end banking close. A retail bank runs a Customer Information Control System (CICS) transaction processing all day and DB2 batch reconciliation overnight. The storage proposal leads with a high IOPS figure, but the workload that matters is a mixed read/write profile followed by long sequential batch jobs. If the vendor cannot state the tested block size, read/write mix, and configuration, the team cannot know whether the array protects the batch window or merely performs well in a cache-friendly benchmark.
• Claims processing after a regional event. An insurer sees a claims surge after a storm, with policy administration, adjudication, and payment systems all leaning on the mainframe at once. A few seconds of storage interruption may not look material in an annual availability percentage, but it can strand customer-facing workflows and create exception queues that take days to unwind. In that setting, the team needs to know whether the availability number applies to one array, a replicated pair, or a replicated pair plus orchestration, and what operational runbook is required when failover happens under pressure.
• Regulatory reporting and audit response. A government team may need to demonstrate where authoritative records originated, who accessed them, and whether reports used current data. If each analytics request creates an extracted copy, the team must govern another synchronization point, access-control surface, and audit trail. Where supported by the application architecture and security model, controlled in-place access to z/OS data can reduce the number of copies the compliance team must manage and defend.
• AI-assisted operations. A CICS team may want to use AI to summarize region health, flag risky transaction changes, analyze response-time patterns, and help newer staff find the right runbook faster. Those use cases depend on current, governed operational context from CICS, DB2, VSAM, logs, and configuration data rather than unverified extracts. NIST recommends that organizations govern, map, measure, and manage AI risks across the lifecycle, including validity, reliability, accountability, transparency, security, and resilience. Whether a proposed storage and application architecture can provide controlled access to data in place without compromising production expectations is deployment-specific and should be demonstrated with the customer’s security controls, workload isolation, latency targets, and recovery procedures.
• Capacity planning for the healthcare industry. A healthcare payer may size a refresh around an effective-capacity assumption that looks reasonable in the quote, then discover that its DB2 tablespaces, VSAM clusters, and compressed claims history reduce differently from the sample workload used to create that assumption. The business risk is not a universal mainframe ratio; it is committing the capital plan before measuring representative customer data and confirming the supported workload ceiling in writing.

These scenarios should be surfaced before the purchase order is signed. The objective is not to predict every future workload change; it is to bring technical assumptions, commercial commitments, and operational dependencies into the same conversation while the organization still has leverage to make a better choice.

Treat the Refresh as a Negotiation

The strongest evaluation strategy is not to treat the refresh as a like-for-like replacement exercise. Treat it as a negotiation over the operating model your mainframe estate will use for the next five to seven years. Performance claims, availability figures, capacity assumptions, AI access, migration paths, and guarantee language should move out of the slide deck and into the written record. Before the next vendor meeting, select one workload, one availability claim, one capacity assumption, and one guarantee term from the proposal. Ask the vendor to document the conditions behind each. If an answer cannot be stated clearly in writing, it is not ready to support the business case.

Run these questions against the incumbent you’re refreshing, whose answers may have changed since the last procurement cycle. Run them against every vendor bidding to replace that incumbent. Even run them against Hitachi Vantara, on the same terms.

The vendor that can document the conditions, commitments, limits, remedies, and lifecycle implications is giving you something you can govern. The vendor that cannot is asking you to accept the risk on their behalf.

Explore how Hitachi Vantara solutions can turn your mainframe storage data into operational insight.