For decades, the mainframe skills shortage has been discussed as if it were a temporary problem.
Experienced engineers would retire. COBOL programmers would become difficult to find. Organisations would eventually move their applications elsewhere, and the problem would largely solve itself.
That has not happened.
Mainframes continue to support critical workloads across banking, insurance, government, healthcare, retail and other industries. At the same time, the skills required to develop, operate and modernise those systems are becoming broader.
The result is a skills problem that has changed rather than disappeared.
Kyndryl’s 2025 State of Mainframe Modernization research found that 70% of organisations reported difficulty finding the talent required to modernise their mainframe environments. Three quarters were using external providers to support modernisation projects.
That suggests the problem is no longer simply about replacing people who know COBOL.
It is about maintaining enough institutional and technical knowledge to operate critical systems while simultaneously changing the way those systems interact with the rest of the enterprise.
The mainframe didn’t disappear
Many predictions about the mainframe skills shortage assumed that organisations would steadily reduce their dependence on the platform.
In practice, many have modernised around the mainframe rather than eliminating it.
Applications have gained APIs. Development workflows have adopted Git and modern IDEs. Mainframe data is increasingly connected to cloud services, analytics platforms and AI systems.
Kyndryl reported in 2025 that 89% of respondents regarded their mainframes as extremely or very important to business strategy and operations, while an estimated 56% of mission-critical applications in the organisations surveyed remained on the platform.
That creates an awkward workforce equation.
Enterprises cannot simply stop investing in mainframe skills because the systems remain important. But they also cannot train a new generation of engineers to work exactly as the previous generation did.
The environment around the mainframe has changed.
The skills gap is broader than COBOL
COBOL remains an important part of the discussion, but describing the problem as a “COBOL shortage” now misses much of what enterprises actually need.
A modern mainframe team might require knowledge of z/OS and CICS alongside Java, APIs, Git-based development, cybersecurity, cloud integration, observability and automation.
Kyndryl’s research illustrates the shift. In its 2025 survey, organisations identified AI, cloud and systems integration as some of the most significant skills gaps affecting mainframe modernisation. Some 42% cited shortages around AI, 37% cloud and 33% systems integration, while 23% cited legacy programming-language skills.
That does not mean COBOL expertise has stopped mattering.
It means the valuable engineer of the future may be someone capable of understanding an established COBOL application and how it fits into a hybrid technology environment.
That is a harder profile to recruit.
It is also why moving an application from one programming language or platform to another does not necessarily remove the knowledge problem.
A forty-year-old application may contain decades of accumulated business rules, operational assumptions, integrations and exceptions. Those are not automatically understood simply because its source code has been translated.
IBM made a similar argument in 2026 when discussing AI-assisted code translation: translating legacy code and modernising the underlying platform or application are different problems.
The real risk is losing institutional knowledge
Some of the most valuable information about a long-running enterprise application never made it into a manual.
It exists in the experience of the people who have spent years supporting it.
They may know why a particular batch process behaves unusually at the end of the financial year, why one interface cannot be changed without affecting another system, or why a piece of apparently redundant code is still required by a business process created decades ago.
When those people retire or leave, an organisation can lose far more than programming expertise.
It can lose part of its operational memory.
That makes the skills shortage a business-continuity issue as much as a recruitment problem.
Organisations therefore need to identify areas where knowledge is concentrated in a very small number of people.
A critical application understood by twenty engineers represents a different risk from one understood by two engineers who both expect to retire within three years.
The code may be equally reliable.
The organisational risk is not.
A younger mainframe workforce is emerging
There are reasons for optimism.
The mainframe workforce is not simply ageing without replacement.
Research associated with IBM’s Mainframe Skills Council found significant demand for both experienced and new talent. Among surveyed employers, 79% were recruiting for mid-career mainframe positions and 51% for entry-level roles, while 91% expected to recruit for new mainframe positions over the following one to two years.
More recent industry reporting also points to a generational handover rather than the complete disappearance of mainframe expertise, with younger professionals increasingly entering the ecosystem.
The challenge is therefore not simply attracting younger workers.
It is giving them sufficient opportunity to learn systems whose complexity has often accumulated over decades.
A developer can learn COBOL syntax relatively quickly.
Understanding a large banking application containing millions of lines of code, hundreds of interfaces and decades of business logic is something very different.
That requires mentoring and experience.
Modern tooling can make mainframe work more accessible
One of the most promising changes is that working with mainframes increasingly does not require developers to abandon the tools and workflows they use elsewhere.
Modern IDEs, source-control systems, automated testing, CI/CD pipelines and APIs can reduce the divide between mainframe development and other software engineering.
That matters for recruitment.
Telling a graduate developer that working on a mainframe means abandoning everything familiar about modern software development is unlikely to make the platform attractive.
Allowing that developer to work with familiar tooling while gradually acquiring specialist platform knowledge is a very different proposition.
It also means organisations should be cautious about defining “mainframe skills” too narrowly.
The future mainframe engineer may arrive from Java development, cloud engineering, DevOps, cybersecurity or another discipline and progressively acquire platform expertise.
That may be more sustainable than waiting to recruit someone who already knows every technology in an organisation’s legacy estate.
Can AI solve the skills shortage?
AI will certainly become part of the answer.
Generative AI tools can help developers understand unfamiliar code, document applications, explain dependencies, generate tests and surface knowledge that might otherwise require assistance from an experienced colleague.
IBM, among others, is exploring AI as a way to make mainframe expertise more accessible and help less-experienced professionals work productively with complex environments.
That could be particularly valuable for knowledge transfer.
Imagine an organisation combining application documentation, source-code analysis, operational procedures and decades of internal technical knowledge into systems that engineers can query conversationally.
Instead of asking the one remaining expert why a particular process exists, a developer could begin investigating independently.
But that does not make the expert unnecessary.
AI can explain source code without necessarily understanding why a business made a particular decision fifteen years ago.
It can suggest a modern implementation without knowing that a seemingly minor behaviour is required by a regulator or relied upon by an obscure downstream application.
The risk is believing that easier code comprehension means the underlying system has become simple.
It hasn’t.
Modernisation does not automatically remove the skills problem
There is another misconception worth addressing.
Organisations sometimes frame mainframe modernisation as a way of eliminating their dependence on scarce skills.
That can happen, but it is not guaranteed.
Moving a complex application from COBOL to Java may replace one skills requirement with another while leaving the underlying business complexity intact.
Moving workloads to cloud infrastructure may similarly require expertise in distributed systems, cloud architecture, security, observability and FinOps.
Modernisation can therefore change the skills problem rather than eliminate it.
The better question is not:
How do we get rid of the technology that requires these people?
It is:
How do we reduce the organisational risk created by knowledge that is difficult to replace?
That opens up more options.
Some applications should be replaced.
Some should be rewritten.
Some should be integrated with modern systems.
And some may be best left substantially where they are while improving tooling, documentation and workforce resilience around them.
What organisations should do now
The strongest response to the skills shortage is unlikely to be a single recruitment programme or technology purchase.
It requires several things happening simultaneously.
Identify concentrated knowledge.
Find the applications and operational processes where expertise sits with only one or two people.
Capture knowledge before it leaves.
Documentation, mentoring, recorded walkthroughs, architectural mapping and AI-assisted knowledge systems can all help.
Create genuine succession plans.
Junior engineers need sustained exposure to experienced practitioners rather than a short handover immediately before somebody retires.
Modernise the developer experience.
Where possible, allow mainframe engineers to use modern source control, testing, automation and development workflows.
Recruit from adjacent disciplines.
Cloud, Java, DevOps, security and platform engineers can acquire mainframe expertise. Organisations do not always need to find candidates who already know the entire environment.
Use automation and AI selectively.
They can reduce repetitive work and make complex systems easier to understand, but should support rather than replace knowledge transfer.
Modernise applications for business reasons.
Do not embark on high-risk rewrites solely because experienced employees are approaching retirement.
Kyndryl’s 2025 research suggests enterprises are already using a mixture of these approaches: 44% reported upskilling employees, 40% were automating processes, 36% were hiring and 35% were using AI as part of their talent strategy.
The shortage hasn’t gone away. It has evolved.
The mainframe skills shortage is real, but the simplistic version of the story is increasingly outdated.
It isn’t merely a queue of COBOL programmers heading towards retirement while enterprises wait to replace their systems.
The mainframe itself is changing. The surrounding technology estate is changing. And a new generation of engineers is entering an environment where mainframe development increasingly overlaps with cloud, DevOps, security, APIs and AI.
The organisations best positioned for that transition will not necessarily be those that remove their mainframes fastest.
They will be the ones that understand where critical knowledge resides, transfer it before it disappears, modernise the way their teams work and give younger engineers a credible route into managing the systems on which the business still depends.
The skills shortage hasn’t gone away.
But organisations have far more tools for dealing with it than they did a decade ago.
