The State of the Estate, 2022–2026: What Four Years Did to Mainframes, AS/400 and Modernization

This is the post we kept postponing until we could prove it. Every external number below is cited to its source; every number about our own platform comes from our test harnesses, not from marketing. Four years — 2022 through 2026 — quietly settled three arguments the industry had been having for decades: whether the legacy platforms are dying (no), whether leaving them is easy (emphatically no), and what actually separates the migrations that survive from the ones that make the newspapers (verification, not code).

Modern data center aisle with a mainframe-class cabinet on one side and cloud-style server racks on the other

The estate of 2026: not either/or. The mainframe and the cloud racks share the same floor — the open question is whether they agree byte for byte.

The mainframe didn't decline. It re-armed.

Start with the hardware, because hardware is where a vendor shows whether it believes in a platform. In April 2022 IBM shipped the z16 with the Telum processor — an on-chip AI accelerator built to score transactions for fraud while they execute.[1] In June 2025 the z17 followed with Telum II, rated for over 450 billion inference operations a day at millisecond latency, plus a new z/OS release tuned for it.[2] Nobody designs custom silicon for a platform they expect to sunset.

The people numbers moved the same direction. BMC's 20th annual mainframe survey — its largest ever, over 1,100 respondents — recorded 97% holding a positive view of the platform, 93% saying their enterprise will keep investing, and 72% forecasting capacity growth.[3] The most under-reported statistic of the decade is in the same survey: 66% of mainframe professionals are now millennial or Gen Z, up from 37% in 2018.[3] The workforce didn't die out — it turned over. What the new generation lacks is not talent but mileage: hours on a system where their mistakes have consequences. Hold that thought; it's where training environments enter the story.

Underneath it all, an estimated ~220 billion lines of COBOL remain in production[4] — a number so large that even aggressive migration decades from now leaves a working estate that must be staffed, tested and changed safely in the meantime.

The AS/400 lineage got a full-stack refresh too

The platform people still call the AS/400 — IBM i on Power — had its own four-year re-arming. In July 2025 IBM launched Power11 with, for the first time, high-end, mid-range and entry servers (plus the cloud virtual server) all generally available on day one.[5] IBM i 7.6 shipped in April 2025 with a public roadmap that sketches successor releases into the 2030s and hardware into the 2040s.[6] Roughly three quarters of IBM i shops run half or more of their core applications on the platform.[7]

But the same surveys carry the warning label: in the 2026 marketplace survey, IBM i shops ranked skills as their #1 concern at 69% — displacing security for the first time since 2017.[8] And the clock has hard dates on it: standard support for IBM i 7.4 ends 30 September 2026.[9] A permanent platform with a staffing problem is still a problem — it's just a different problem than the one the "legacy is dying" narrative spent twenty years preparing everyone for.

The modernization scoreboard, 2022–2026

Now the uncomfortable half of the ledger. Gartner forecast that by 2026 more than 70% of mainframe exit projects — full replacement or shutdown — would fail,[10] and that 80% of IT modernization efforts would miss their savings targets because they addressed the wrong complexity.[11] Practitioner analyses in the same window put average mainframe-to-cloud timelines at 40 months against 28 planned, with failed projects running roughly 2.5× over budget[12] — and the most commonly reported root cause is underestimating application complexity before starting.[13]

Here's the nuance that headline hides: modernization done on and around the platform is working. Kyndryl's 2025 state-of-modernization research reports projects returning 2–3× their investment — but the strategy mix tells the real story: 43% of organizations are modernizing directly on the mainframe and 50% run a hybrid strategy; only a small minority are accelerating full exits. Seven in ten report they struggle to hire the skills to do any of it.[14] The market voted the same way: AWS closed its Mainframe Modernization managed runtime to new customers on 7 November 2025, with the self-managed experience following on 30 June 2026[15] — the hyperscaler that promised to run your migrated mainframe workloads is steering new demand to partners and to AI-assisted transformation tooling instead. "Modernize" stopped meaning "leave." It now mostly means "keep the core, integrate around it, and replace pieces only when you can prove the replacement."

Meanwhile the calendar kept forcing decisions whether shops were ready or not:

Forcing event	Date	What it forced
TSB fines land	Dec 2022	UK regulators fined TSB £48.65M for its 2018 core-banking migration failure — the enduring case study in cutover risk[16]
SWIFT MT retirement	22 Nov 2025	MT/ISO 20022 coexistence ended for cross-border payments; every payments estate had to touch its message layer[17]
Sybase ASE 16.0 EoMM	31 Dec 2025	mainstream maintenance ended — estates on ASE now run on extended support or must move
AWS managed runtime closes	7 Nov 2025	one of the two hyperscaler "run it for you" paths closed to new entrants[15]
IBM i 7.4 EoS	30 Sep 2026	midrange shops on 7.4 must upgrade or buy extended support[9]

What actually kills these projects

Read the post-mortems from the last decade and a pattern emerges that has nothing to do with programming languages. TSB is the canonical case because it was independently investigated: five million customers cut over in a single weekend, more than 230 days to fully recover, £330M+ in total costs, and — the finding that matters — test environments that materially differed from production.[16] The rehearsal was not the performance.

The quieter failures rhyme with it. Undocumented business logic surfaces mid-flight because nobody could exercise the old system safely enough to map it. Data conversion defects appear only under production-shaped volume. And in COBOL conversions specifically, one migration-services analysis attributes 67% of failures to incorrect decimal precision handling[12] — the packed-decimal sign nibble, truncation order, rounding mode: bytes, not architecture diagrams. These are not coding failures. They are verification failures — every one of them is a fact about the old system that the project needed to know, and had no safe place to learn.

AI made the code cheap. It made nothing else cheap.

The newest force in the room is generative AI, and it cuts both ways. Adoption is real: 65% of mainframe shops already use generative AI in BMC's survey,[3] and nearly 90% of Kyndryl's respondents have implemented or plan generative AI on the mainframe.[14] IBM's watsonx Code Assistant for Z has been generating and explaining mainframe code since 2023,[18] and AWS Transform now points agentic AI at whole z/OS application portfolios.[19]

We think the honest summary is this: AI collapsed the cost of producing candidate code, and left the cost of proving it untouched. When a conversion engine can emit a million lines of Java from COBOL in a week, the binding constraint on the whole program becomes the question it cannot answer about itself: does the new code do exactly what the old code did — for every record, every edge case, every cent? The industry is converging on the same conclusion — practitioners now describe mainframe modernization bluntly as a verification problem.[20] Whatever you think of AI code conversion, it has made verification capacity, not developer capacity, the scarce resource of the next decade.

Equivalence, or it didn't happen

Which brings us to the discipline this site exists for. The gold standard for de-risking a migration has been known for fifty years: run the old and new systems side by side on the same inputs and compare the outputs — a parallel run. What changed recently is that the biggest names in the migration business now build their offerings around it: Google Cloud's Dual Run productized parallel production execution precisely because "test it and hope" kept failing,[21] and AWS added automated testing to Transform for the same reason.[19]

But a parallel run is only as good as the comparison it makes, and this is where projects quietly lower the bar. Screen-looks-right is not equivalence. Row-counts-match is not equivalence. Equivalence is byte-level: the same packed-decimal sign nibble, the same COMP-3 truncation, the same collating order under an EBCDIC sort, the same abend at the same record when the data is bad — because downstream systems consume bytes, not intentions. And you cannot bolt that discipline on at cutover. You need it from day one, which means you need something most estates simply do not have: a test environment where the whole estate — batch chains, online transactions, files, databases, schedulers, security — can be run, broken, reset and re-run at will, without touching production, without fighting for a shared LPAR window, and without a five-figure per-seat licence standing between every engineer and their own sandbox.

The test-environment test Ask one question of any modernization plan: "Where do we re-run last month's production batch, twice, and diff the outputs byte for byte?" If the answer involves borrowing a shared region on someone's schedule, the plan is running on hope.

Where SteelFrame stands

This is the problem our SteelFrame platform was built against, and we hold it to the same evidentiary standard we've applied to every number above. SteelFrame provides mainframe- and IBM i-compatible environments that run in a browser — JCL, COBOL, VSAM, DB2-style SQL, CICS-style transactions, schedulers, security, plus the midrange side — spun up per person, snapshotted, and reset between runs. Its correctness is not asserted; it is measured, and the measurement is the product: 2,197 automated test suites with 53,937 assertion sites across 770K lines of test code run against it, including 15 simulated application estates exercised end-to-end — batch cycles and online flows, with general-ledger debits proven equal to credits; one ten-estate build alone accounts for 250 programs and 6,268 estate-level checks. Where behavior intentionally deviates from the real platforms, we publish it on the capability page instead of hoping you won't notice.

That yields three things the last four years proved everyone needs. For training: unlimited safe mileage for the new, young workforce — every exercise machine-checked, every environment private and resettable, customizable to your shop standards. For modernization: a rehearsal estate where you can replay production-shaped batch and online work and diff the seams byte-for-byte before anything is cut over — the equivalence discipline TSB's post-mortem begged for, available before the project, not after the fine. For the AI era: verification capacity on demand — golden runs, fixtures and differential harnesses that turn "the AI converted it" into "and here is the byte-level proof."

The platforms re-armed. The failure statistics did not improve on their own. The code got cheap and the proof did not. If those three sentences describe your next four years, the environments, services and courses on this site are what we built for them — and if you want to argue with any number in this post, the sources are right below, which is exactly how we like it.

Sources

External figures are as published by their sources at the dates shown; SteelFrame numbers are derived from our own test harnesses and re-derivable on demand.

All posts