Talent, Not Technology: A Field Guide to the 2026–2030 COBOL Estate

A Vice President at Citi recently laid out the decade ahead in one line: the COBOL problem was never a technology problem — it's a talent, modernization and business-continuity problem. We think that's right. And it happens to describe, service by service, exactly what we built this shop to do. So this post takes the argument seriously enough to test it against numbers, extend it where it stops short, and map it onto a concrete 2026–2030 plan.

The argument is worth restating plainly, because it inverts twenty years of received wisdom. COBOL is not disappearing. It sits under banking, insurance, government, retail and every other estate where reliability and regulatory stability are non-negotiable — an estimated ~220 billion lines in production, underpinning roughly 43% of banking systems and 95% of ATM card-swipes.[1] Nothing that size gets migrated away on any realistic 2030 horizon. So the question stops being when does COBOL die and becomes how do you carry the business value trapped in these systems across a decade while the people who understand them retire. Kyndryl's 2025 research put a number on the pain: roughly seven in ten organizations can't find the skills to modernize.[2] On the midrange side, IBM i shops ranked skills their #1 concern in 2026 — at 69%, displacing security for the first time since 2017.[3] The binding constraint of the next four years is not the code. It's who can read it, change it, and — this is the part the talent narrative usually forgets — prove the change was safe.

That last clause is where a talent-first reading gets sharper than the LinkedIn version. Losing the engineer who remembers why a COMP-3 field truncates the way it does isn't a staffing inconvenience. It's the moment an undocumented business rule becomes a production incident, because there was no safe place to relearn it and no way to prove the replacement behaves identically. Talent risk and verification risk are the same risk wearing two hats. Keep that in mind through everything below — it's the through-line.

The talent math, in numbers a board can read

Before the plan, the evidence. Every row is externally published; none of it is ours.

Number	What it measures	Source
~220B lines	COBOL still in production — 43% of banking systems, 95% of ATM swipes, ~$3T of daily commerce	Reuters analysis, 2017[1]
~70%	organizations that struggle to find the skills to modernize the mainframe estate	Kyndryl, 2025[2]
69%	IBM i shops ranking skills their #1 concern — above security for the first time since 2017	IBM i Marketplace Survey via IT Jungle, 2026[3]
66%	mainframe professionals now millennial or Gen Z, up from 37% in 2018 — the workforce turned over; what it lacks is mileage	BMC 20th Annual Mainframe Survey, 2025[4]
70%+	mainframe exit projects (full replacement/shutdown) forecast to fail by 2026 — why "just rewrite it" is not the answer to a staffing gap	Gartner, via trade press[5]

What a talent cliff looks like when it arrives April 2020: unemployment claims spiked and the governor of New Jersey stood at a podium asking, on live television, for volunteer COBOL programmers to help the state's 40-year-old claims systems keep up.[6] Read that story carefully — the systems worked. What the state had run out of was people who could safely change them under load. That is the failure mode the 2026–2030 window is built to avoid, and it is a staffing failure, not a technology failure.

The VP's timeline, read as a build plan

The Citi post sketches a phased strategy: preserve knowledge, then build API/DevOps capability, then accelerate selective and AI-assisted modernization, then operate a hybrid workforce. We agree with the sequencing — it front-loads the perishable asset (knowledge) and back-loads the reversible ones. Here is the same timeline with the work named. Each row is a section of this post, and each is a service you can engage today.

Window	The market's move	The work that closes it
2026–27	preserve knowledge, strengthen fundamentals	business-rule extraction · tribal-knowledge capture · behavioral test-suite generation
2027–28	build API, DevOps and automation capability	hybrid-engineer training on live emulators · DevOps enablement · corporate reskilling
2028–29	accelerate selective + AI-assisted modernization	wrap-first modernization · AI comprehension and transformation with verification gates
2029–30	operate a hybrid workforce	certification and readiness assessment · staff augmentation · proof capacity on demand

Preserve the knowledge before it walks out the door (2026–27)

This is the most urgent and least glamorous layer, and it's where the clock is loudest. When a senior engineer leaves, decades of accumulated business logic leave with them unless it was captured first — the "IT cowboys riding into the sunset" problem the financial press has been documenting since 2017.[1] We run:

Business-rule extraction — mining the embedded logic out of undocumented COBOL and RPG into specifications a hybrid team can actually read.
Automated documentation generation across COBOL, JCL, CICS, DB2 and the IBM i side, so the estate stops being a black box.
Dependency and impact-analysis mapping — the Seam analyzer tracing programs, copybooks, jobs and data stores so no change ships blind.
Tribal-knowledge capture — structured sessions with your senior engineers paired with code archaeology, run before the retirement, not after.
Behavioral test-suite generation for systems that never had one — locking today's behavior into golden runs so any future change can be measured against it.

That last item is the hinge, and it's why we'd amend the Citi framing in one place: documentation preserves what a system was believed to do; a golden run preserves what it does. Capturing current behavior as an executable, re-runnable fixture is knowledge preservation and verification setup in a single motion — the only form of tribal knowledge that can't drift from reality, because you can re-run it.

Train the hybrid engineers nobody can hire (2027–28)

The Citi post's central claim is that 2030 demand shifts from pure COBOL programmers to engineers who hold COBOL, JCL, CICS and DB2 and Git, CI/CD, cloud, APIs and security in the same head. That engineer is not on the market. They have to be made — and made somewhere their mistakes have no blast radius. This is SteelFrame's home turf:

Hybrid-engineer bootcamps spanning the legacy and modern stacks in one curriculum — the course catalog runs both tracks.
Live-emulator training — browser-based environments with real JCL, COBOL, VSAM, DB2-style SQL and CICS-style transactions, spun up per person, broken, reset and re-run at will. Not slideware.
A dedicated RPG / IBM i track, separate from z/OS, because — see below — it is a genuinely different market with a steeper cliff.
Corporate reskilling for existing staff crossing from pure-legacy to hybrid roles, customizable to your shop standards.
Readiness assessment and certification — proving a workforce is modernization-ready, not assuming it. Every lab is machine-checked against expected outputs, so "ready" is a measurement.
Staff augmentation — placing the hybrid engineers the pipeline produces.

The unlimited-mileage point is the whole game. The workforce already turned over — the mainframe profession is now two-thirds millennial and Gen Z[4] — so the 2030 problem is not recruiting young engineers, it's giving them hours on a system where consequences are real, without the consequences. A shared LPAR window can't do that; a five-figure per-seat licence won't scale to it. A private, resettable environment is how you buy those hours without buying an outage.

Modernize by wrapping, not rewriting (2028–29)

Note what the market actually asked for. "Modernization will increase — but not necessarily mean rewriting everything." The demand is API enablement, refactoring, integration and documentation — understand and wrap — with full replacement as the least-wanted quadrant. The strategy data confirms it: in Kyndryl's research most organizations modernize on and around the platform, with only a small minority accelerating full exits[2] — and Gartner's forecast that more than 70% of mainframe exit projects fail is the reason why.[5] So we lead with the wrap:

API enablement — exposing legacy transactions as REST/gRPC without touching the core logic.
Selective refactoring of the high-value modules that justify the risk.
Cloud and hybrid integration for both mainframe and IBM i.
DevOps enablement — bringing Git, CI/CD and automated testing to shops that have none.
Selective component replacement, scoped tightly and proven before cutover.
Full migration, including COBOL→Java — offered, but positioned honestly as the last resort the market wants least, and never shipped without byte-level equivalence behind it.

Point AI at the estate — and prove what it emits

AI is the accelerant the Citi post names, and the caveat it attaches — critical business logic still requires strong validation and engineering governance — is the entire reason we exist. Adoption is already the norm; the honest summary is that AI collapsed the cost of producing candidate code and left the cost of proving it untouched. So our AI services come welded to a verification layer:

AI code-comprehension for analyzing undocumented systems at estate scale.
AI-generated documentation and tests, as tooling rather than a one-off engagement.
AI-assisted code transformation with human validation gates, not blind acceptance.
Modernization-governance tooling — the golden runs, fixtures and differential harnesses that turn "the AI converted it" into "and here is the byte-level proof."

When a conversion engine can emit a million lines of Java in a week, developer capacity stops being the constraint and verification capacity becomes it. We sell the scarce one.

Sell the diagnosis, not just the cure (start here)

The highest-margin, lowest-build entry point is the one almost nobody offers — and it's lifted straight from the VP's thesis that workforce strategy now matters as much as technology strategy:

Modernization roadmap and estate assessment — capability mapping before anyone writes code.
Workforce-strategy consulting — the talent plan the whole argument turns on.
Talent-retention program design — because the greatest risk is the engineer who leaves, not the language that stays.
Build-vs-buy-vs-migrate portfolio analysis, application by application.

Selling the diagnosis and the tooling, training and verification that resolve it is a tighter loop than any competitor wrapping COBOL in APIs is positioned to close.

Is anyone doing "full AI" modernization? No — and the reason is our whole business

It's worth answering the question directly, because it's the one every board is now asking: is there a fully autonomous, human-out-of-the-loop mainframe modernization happening anywhere today? As of this writing, no — and the industry spent early 2026 loudly explaining why.

The catalyst was Anthropic's 23 February 2026 post arguing that Claude Code can automate the exploration and analysis phases that consume most of the effort in COBOL modernization — mapping dependencies across thousands of lines of code, documenting workflows nobody remembers, and surfacing risks that would take human analysts months to find.[7] The market took it as an existential threat: IBM shares fell 13.2% that day — roughly $31 billion of market value, the steepest one-day drop since October 2000.[8] But read the actual claim. Even its author scoped it to discovery and analysis, not end-to-end conversion — the same post says human judgment remains essential for regulatory requirements, business priorities and risk tolerance. The AI does the legwork; humans still do the modernization.

That distinction is not marketing hedging — it's the settled consensus, and it came from every corner at once:

IBM's Rob Thomas, the same day: "Translating code is one thing. Modernizing a platform is something else entirely" — the challenge "is not a COBOL language problem," it's everything the application runs on and integrates with.[9]
BMC's John McKenny, flatly: "Translating code itself isn't modernization."[10]
Thoughtworks called treating this as "deploying the tool and letting it run with a prompt" a "deeply naive view of execution" — and pointed out that COBOL was deliberately designed to be readable, so the constraint was never impenetrability but scale and cognitive load.[11]
Phase Change Software drew the line precisely: there is "a profound difference between a language model that has read COBOL and a purpose-built system that truly understands it" — and business rules must be provably correct, not "likely correct."[12]
Futurum's assessment is the one to keep: AI tools "accelerate the code analysis and transformation phases of modernization, but do not yet address the full program scope that determines whether migrations succeed or fail" — and regulated industries face requirements around audit trails, behavioral equivalence and compliance "that neither Claude Code nor Project Bob fully resolves today."[13]

Even where AI is furthest into the stack, a human sits in the loop. Project Bob — IBM's AI-first IDE that replaces watsonx Code Assistant for i across RPG, CL, SQL, COBOL, Java and Python — embeds Claude as one model among several inside a developer's IDE.[13] The recurring production workflow across every credible vendor is the same five steps: AI conversion, AI-generated tests, idiomatic refactoring with human expertise, human review of business logic, then integration. Steps three and four are explicitly human, and they are human for exactly one reason — nobody has a cheap, trustworthy way to prove the converted system behaves identically to the original. Futurum names behavioral equivalence "the gap neither vendor has closed" and calls provable equivalence the differentiator for whoever closes it.[13] We agree, obviously. It's the product.

So the honest state of the art is this: AI collapsed the cost of producing candidate code and left the cost of proving it untouched. "Full AI modernization" isn't blocked by conversion capacity. It's blocked by verification. Behavioral equivalence is the unsolved part — and it is the part CobolStack was built to solve.

How SteelFrame closes the verification gap

Verification fails in practice for a mundane reason: most estates have nowhere to run the proof. You cannot diff old against new if you can't safely execute the old, at production shape, as many times as it takes. SteelFrame is that place, and its correctness is measured rather than asserted — the measurement is the product.

A rehearsal estate, per engineer, resettable at will. Browser-based environments run the whole estate — JCL, COBOL, VSAM, DB2-style SQL, CICS-style transactions, schedulers, security, plus the IBM i side — spun up per person, snapshotted, broken and reset between runs. No shared-LPAR window, no five-figure per-seat licence between an engineer and their sandbox. That is the precondition every parallel-run strategy assumes and most estates lack.
Golden runs that turn AI output into evidence. Before a single line is converted, we capture what the current system does as executable, re-runnable fixtures. When the AI emits its million lines of Java, the question stops being "does it look right" and becomes "does it produce the same bytes as the golden run, for every record." That is how "the AI converted it" becomes "and here is the proof."
Byte-level equivalence, not screen-looks-right. The Seam analyzer diffs old and new outputs at the level that actually matters downstream: 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. Row-counts-match is not equivalence. Screen-looks-right is not equivalence. Consuming systems read bytes, not intentions.
The verification gate the whole industry says is mandatory — as capacity on demand. Differential harnesses, fixtures and golden runs are exactly the audit-trail and behavioral-equivalence evidence that regulated modernization requires and that AI tools do not provide.[13] We supply the scarce resource of the AI era: not developer capacity, but proof capacity.
Governance you can show a regulator. Where our environments intentionally deviate from the real platforms, we publish it on the capability page rather than hoping nobody notices — because the point of a proof is that it survives inspection.

Put plainly: the industry agrees AI can now write the new system faster than anyone can check it. SteelFrame is the checker. It doesn't compete with Claude Code, Project Bob, or any conversion engine — it makes their output trustworthy, which is the one thing standing between "candidate code" and "cutover." Let the AI be as autonomous as it likes on the producing side; the proving side is where we live.

The succession test Ask one question of any workforce plan: "When the engineer who understands the nightly batch retires, where does their replacement re-run last month's cycle, break it, and learn why it broke — without anyone noticing?" If the answer is "production, carefully," the plan is running on hope. The same environment that answers it is the one that later proves the modernization — which is exactly why talent risk and verification risk are one budget line, not two.

One honest distinction: z/OS is not IBM i

The Citi post is really about the mainframe. The AS/400 lineage — IBM i on Power — is a separate market with its own aging-workforce crisis, and on that platform the language in question is RPG, not COBOL. The cliff there is arguably steeper: skills displaced security as the #1 concern in the 2026 marketplace survey,[3] the platform never grew the same modernization-tooling ecosystem, and the calendar has hard dates on it — standard support for IBM i 7.4 ends 30 September 2026.[14] We cover both sides through SteelFrame (z/OS-style: JCL, COBOL, CICS, DB2-style SQL) and SteelFrame X (AS/400-style: RPG, CL, DDS, the 5250 world) — but we keep the tracks, the content and the tooling distinct, because "compatible with both" too easily becomes "optimized for neither." If you run both estates, that separation is the point.

The through-line

Read the Citi post as a talent argument and every service above is a talent service in disguise. Knowledge preservation is capturing what a leaving engineer knew. Training is manufacturing the engineer the market can't hire. Wrap-first modernization is respecting the business logic those engineers encoded. AI governance is refusing to let a machine discard that logic silently. And the thing that ties all of it together — the reason a preserved rule, a trained engineer, a wrapped API and an AI conversion can all be trusted — is the same discipline this shop was built for: run the old and the new on the same inputs and diff the outputs byte for byte, before anything is cut over.

The Vice President at Citi is right that the next decade is a people problem. We'd add one sentence: a people problem you cannot solve without a place to prove that what the people build still does exactly what the old system did. That place is what we sell. The services, environments and courses on this site are the whole catalog — and the contact page is where the 2026 conversation starts.

On LinkedIn

This field guide began with a LinkedIn post: "COBOL Market Outlook to 2030: The Real Challenge Is Talent, Not Technology" by Vidyut Saha — the argument this article takes up, tests against the numbers, and extends. Join the discussion there.

From the LinkedIn post — read and comment on LinkedIn.

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