Mainframe modernization in 2026: approaches, costs, and what actually works

Enterprises spend $330 billion a year maintaining mainframe systems. Seventy-one percent of Fortune 500 companies still run their most critical workloads on them, per IBM's Institute for Business Value (2024). TSB Bank's 2018 migration failure, which locked 1.9 million customers out and cost over £200 million in remediation, illustrates why most CTOs haven't started.

At Techstack, we run 2-week diagnostics that identify what to keep, rebuild, or remove before any migration commitment begins. This article is the decision-making resource we wish existed when clients first call us.

What you'll find here:

• The four main mainframe modernization approaches and when each one makes sense
• A practical Keep / Rebuild / Retire framework for deciding what to do with each workload
• Realistic cost benchmarks by approach, measured per function point instead of vendor estimates
• The AI-readiness criterion reshaping modernization priorities in board conversations
• What successful mainframe modernization case studies have in common

What is mainframe modernization (and what it isn't)

Mainframe application modernization is the process of restructuring how business logic runs, where data lives, and how systems connect to the rest of the enterprise. It can mean moving workloads off IBM hardware, rewriting COBOL into modern languages, wrapping existing systems with API layers, or retiring applications that no longer serve anyone.

The most common mistake is treating this as a simple infrastructure move. Lift-and-shift is technical debt relocation, not modernization. Moving COBOL from z/OS to a cloud VM doesn't reduce your dependency on COBOL developers or make your data accessible to modern applications.

Effective mainframe modernization must address three things. First, licensing cost: IBM z16 MIPS pricing has risen an estimated 15–20% in new enterprise agreements since 2022 (Gartner IT Cost Benchmarking, 2024). Second, talent dependency: 67% of CIOs name mainframe skills shortage as their top infrastructure risk for 2025–2026 (IDC IT Executive Survey, 2024). Most COBOL engineer in production environments is averaging in their late 50s, and their knowledge often isn't documented. Third, integration capability: can mainframe-resident systems exchange data with modern applications, analytics platforms, or AI pipelines in real time?

An estimated 220 billion lines of COBOL remain in active production globally (OpenText, 2023). Most contains business logic never formally documented. Batch jobs written decades ago encode rules nobody remembers. Validation subroutines have downstream dependencies but no specification exists for them. This undocumented logic problem is the root cause of most failed modernization projects.

The four mainframe modernization approaches (with honest trade-offs)

Every legacy mainframe modernization strategy falls into one of four categories. The right choice depends on your constraints: timeline pressure, budget ceiling, risk tolerance, and what you need the system to do in 18 months.

Rehosting (lift-and-shift)

Rehosting moves mainframe workloads to cloud infrastructure without changing application code. Your COBOL still runs. Your batch schedules still execute. Compute happens on AWS, Azure, or GCP instead of IBM iron.

This is the fastest approach to execute. Organizations with hard deadlines driven by data center lease expirations or IBM contract renewals often start here. Cost typically ranges from $800–$1,500 per function point.

The risk: you haven't reduced technical debt. MSU licensing costs get replaced by equivalent cloud compute costs. Your COBOL talent dependency stays identical.

Rehosting fits when timeline is the binding constraint and the risk of touching business logic is too high.

Replatforming

Replatforming replaces the runtime environment while preserving application code structure. Think z/OS to Linux on cloud. Your COBOL may still run, but no longer on proprietary IBM hardware.

This is the middle ground. You get meaningful licensing cost reduction without rewriting application logic. Cost ranges from $1,000 to $2,200 per function point. Migration effort is moderate, and correctness risk is lower than a full rewrite.

The risk: you still have COBOL. You still need people who can read it. You haven't made the system API-accessible or AI-ready.

Replatforming fits when licensing cost is the primary pain and a full rewrite isn't justified.

Refactoring and re-architecting

Refactoring decomposes monolithic mainframe applications into separate services. The strangler fig pattern, first described by Martin Fowler, dominates: you build new services alongside the existing system, redirect traffic incrementally, and retire legacy components one at a time.

This is the highest-effort approach. Cost per function point ranges from $1,200 to $3,500 (Capers Jones Software Benchmarks, 2022–2023). But it has the lowest failure rate when done incrementally. McKinsey's "Rewired" technology report (2023) found that companies modernizing incrementally recover their investment 3× faster than those attempting full rewrites, achieving equivalent technical debt reduction within 24 months.

The risk: scope creep. What starts as "refactor the payments module" can expand once teams discover how deeply that module connects to everything else.

Refactoring fits when AI-readiness, API integration, or long-term system flexibility are the goals.

Retiring and replacing

Some workloads shouldn't be migrated. They should be turned off.

Most mainframe estates carry 20–30% of workloads that could be decommissioned: batch jobs producing reports nobody reads, duplicate processes from unintegrated mergers, business rules superseded by regulatory changes.

Retiring is the most underused approach. It costs almost nothing compared to migration but requires discovery to map which processes have active downstream consumers.

The trigger question: "When did a human last invoke this process for a non-automated reason?" If nobody can answer that, you've likely found a retirement candidate.

What to keep, rebuild, or retire: a decision framework

Every CTO asks this first. The logic for categorizing workloads follows a consistent pattern. We call it the Keep / Rebuild / Retire framework.

Keep applies to workloads that handle high transaction volume reliably, have proven correctness over years of production, and don't need changes to downstream dependencies. Wrap them with an API façade layer. This makes the workload accessible to modern systems without touching core logic.

Trigger question: "If we changed this workload's behavior by one decimal point, how many systems would break?"

Rebuild applies to workloads where business logic is documented or capturable, modern equivalents exist, and integration or AI-readiness demands a new architecture. Always use the strangler fig pattern. Never attempt a big-bang rewrite.

Trigger question: "Can we capture what this system does in a specification that a new team could implement without talking to the original developer?"

Retire applies to workloads with no active users, duplicate functionality, or business rules made obsolete by regulation. This is where discovery produces its biggest surprises. Organizations pay six figures annually in MIPS costs for processes serving no business function.

Trigger question: "When did a human last invoke this process for a non-automated reason?" Always validate with business owners before decommissioning.

Mainframe modernization costs in 2026: what the numbers actually mean

The $330 billion annual global spend on legacy maintenance flows out in licensing renewals, specialized contractor rates, and emergency fixes—all increasing year over year.

Cost benchmarks by approach (Capers Jones Software Benchmarks, 2022–2023):

• Rehosting: $800–$1,500 per function point
• Replatforming: $1,000–$2,200 per function point
• Refactoring: $1,200–$3,500 per function point
• Retiring: near-zero migration cost, 2–6 weeks discovery per workload cluster

Four cost drivers blow up budgets. Undocumented logic discovery requires reverse-engineering what COBOL programs actually do. COBOL skill scarcity means contractors charge $175–$250/hour and are booked months out. Testing at parity requires proving the new system produces identical outputs across millions of transaction scenarios. Data migration is always more complex than initial estimates suggest.

IBM z16 MIPS pricing has climbed 15–20% since 2022. Every year you delay, the licensing bill grows.

Automated COBOL conversion tools (COBOL-to-Java, COBOL-to-C#) require 40–60% manual remediation before production readiness (IEEE Software, SEI/Carnegie Mellon, 2022). Converted code often preserves COBOL's procedural structure in an object-oriented language, creating something technically Java but reading like COBOL with different syntax. These mainframe modernization tools have a role in specific scenarios but aren't a replacement for architecture assessment.

Failed projects run an average of 2.5× over budget and 1.8× over timeline. The primary cause: incomplete business logic mapping before work begins.

Mainframe Modernization Approaches: Cost & Trade-off Comparison

The AI-readiness problem: why 2026 is different

Until 2024, mainframe modernization centered on cost reduction and risk mitigation. A third driver has entered board conversations: can our systems feed AI?

According to Gartner's 2026 mainframe report, the primary obstacle to mainframe exit isn't technology, it's the sheer volume and interconnected complexity of mainframe-resident data. That same complexity makes mainframe data inaccessible to AI and ML pipelines, which is now the forcing function driving modernization decisions at the board level.

"AI-ready" requires clean API endpoints that external systems can call without custom integration work. It requires structured data contracts so consuming systems know the shape and freshness of the data. And it requires low-latency event streams for real-time access. Batch files dumped to FTP at 2 AM don't qualify.

Most mainframe estates fail on all three. The minimum viable path to AI-readiness starts with API wrappers on high-value data sources, achievable within 3–6 months using the Keep category above. Wrap it, expose it, and leave the underlying logic alone.

This is why the modernization conversation has shifted. Two years ago, a CTO could justify delay by pointing to system stability. Today, the board asks why competitors are building AI-powered products with their data while you're running batch cycles from 1994.

Mainframe modernization challenges: what kills projects

The core problem in mainframe modernization isn't infrastructure. It's business logic. Most organizations don't have a complete picture of what their systems actually do.

Undocumented business logic is the #1 failure cause. The engineers who wrote the code average 61 years old. Many have already retired. Knowledge of what the system actually does, including edge cases and regulatory workarounds, lives in their heads. Once they leave, it's gone.

Vendor lock-in during assessment creates a conflict of interest. When the mainframe vendor is also the migration consultant, the recommendation favors approaches maintaining vendor dependency. Get an independent assessment from a team that doesn't sell you hardware or platform licenses.

Scope expansion after discovery is the third killer. Projects that start as replatforming become re-architecture once teams map actual logic and discover tangled dependencies. This destroys budgets built on original scope.

Correctness risk sits in a category by itself. COBOL processes an estimated $3 trillion in daily commerce across banking, insurance, and retail (Reuters/Micro Focus, 2017). A logic error during migration isn't a performance regression you can patch next sprint. It's a financial misstatement, regulatory violation, or customer-facing outage.

Mainframe modernization case studies: what success actually looked like

ING Bank: incremental offloading that worked

ING used the strangler fig approach to build microservices alongside their mainframe. Over three years, they reduced MIPS consumption by approximately 30% without production outages. Method: identify workloads, build modern replacements, run both in parallel, redirect traffic, verify correctness, retire mainframe components.

TSB Bank: the cautionary case everyone should study

In 2018, TSB migrated from IBM mainframe to Proteo4UK. Pre-migration business logic mapping was inadequate. When live, 1.9 million customers were locked out of accounts. The bank spent £330 million on remediation. TSB didn't fail because they chose wrong technology. They failed because they didn't know what their existing system actually did before replacing it.

Commonwealth Bank of Australia: winning can still be expensive

CBA replaced its core banking mainframe over five years using SAP. Cost exceeded AUD $1 billion. By technical measures, it was a success. But it consumed a decade of executive attention and locked the organization out of other large technology initiatives.

Techstack: legacy sales system to AI-ready architecture

We worked with an enterprise whose legacy sales system bottlenecked every growth initiative. Using our diagnostic-first approach, we identified which components to keep, rebuild, and remove. The result was a modular, API-accessible architecture supporting AI-driven functionality.

The common thread: successful cases started with thorough discovery. Failed cases skipped it.

Mainframe modernization trends for 2026

Hybrid architectures are becoming the default. According to Advanced's 2024 Mainframe Modernization Barometer, 92% of enterprises are retaining mainframes as part of hybrid strategies rather than pursuing full cloud migration: organizations aren't fully leaving mainframes. They're building modern systems around them.

AI-readiness has replaced "cloud migration" as the primary modernization justification in board conversations. CFOs who wouldn't approve infrastructure spend are approving AI-readiness spend.

Diagnostic-first engagements are replacing multi-year program commitments as the entry point CTOs will accept. After blown budgets, decision-makers want proof of scope before committing.

MIPS pricing pressure is accelerating decisions that would otherwise take two to three years. The cost of inaction now has a specific, rising number.

Automated conversion tools are maturing but still require substantial expert remediation. They're part of the toolkit, not the whole solution.

How to start without committing to a multi-year program

Every CTO has the same concern: "We've been burned before." They watched an 18-month vendor engagement end with a bloated scope document and no working code, or a competitor's migration blow up publicly.

Our 2-week diagnostic isn't sales disguised as assessment. It produces three deliverables: a prioritized inventory of what to keep, rebuild, or retire; a cost model by workload based on actual complexity; and identification of institutional knowledge gaps, specifically which business logic lives only in engineers who may not be there in 18 months.

You don't commit to migrate. You commit to understand what you have. Then you decide.

Say you're a mid-market financial services company running 4,000 MIPS on an IBM z15 with renewal in 14 months. Your COBOL team is three people, with the most senior planning to retire next year. Your CEO wants AI-powered fraud detection, but transaction data is trapped in batch files. The diagnostic tells you which workloads to wrap with APIs now, which to rebuild as microservices over the next year, and which to turn off tomorrow.

What to remember

• Mainframe modernization is a business logic problem, not an infrastructure problem. The 220 billion lines of undocumented COBOL are the real obstacle.
• Four approaches exist: rehost, replatform, refactor, retire. Most successful programs use a mix, applied workload by workload.
• Cost per function point ranges from $800 to $3,500 depending on approach and complexity. The cost of standing still rises 15–20% annually with MIPS pricing increases.
• AI-readiness, not cost reduction, is reshaping board priorities in 2026. Most mainframe estates can't feed AI pipelines without at least API wrapping.
• Projects that succeed invest in discovery first. Projects that fail skip it.
• Start with a 2-week diagnostic. Map what you have, identify what to keep, rebuild, or retire, and build your business case from evidence instead of estimates.