An honest answer for anyone making a career decision in 2026.
When someone is considering a career in mainframe, outsourcing risk is one of the first questions that comes up. It's a fair question and deserves an honest answer, not a reassuring one.
The short version: it depends significantly on which part of mainframe you work in. Application development and systems programming face very different outsourcing dynamics, and understanding the difference is one of the most important career decisions you can make.
I should note upfront that this reflects my experience working with shops in the Middle East, Europe, and the US over 35 years. The picture may look different in other markets and I'm sure others have seen different patterns.
COBOL application development, JCL, batch maintenance: this work has been offshored significantly. Tata, Wipro, Infosys, HCL, and Cognizant all run large mainframe application practices, primarily servicing US and European financial institutions from India. This is not a trend that is reversing.
If you are doing routine COBOL maintenance work, fixing bugs in existing programs, making incremental changes to batch jobs, running regression tests, you are competing in a global labour market. The cost difference between an onshore and offshore developer doing that kind of work is significant enough that most large organisations have already made the calculation.
This does not mean COBOL application development is a bad career choice. The offshore teams still need onshore coordination, technical leadership, and subject matter expertise that requires proximity to the business. But routine maintenance work at the junior level is under sustained cost pressure that is unlikely to ease.
Systems programming is a meaningfully different story, for reasons that are structural rather than accidental.
The work requires deep familiarity with a specific shop's environment. The way a particular organisation's JES2 is configured, their WLM service definitions, their RACF structure, their subsystem parameter libraries: this institutional knowledge is built over years and does not transfer easily to a team that has never seen the environment. Every mainframe installation is different in ways that matter when something goes wrong.
Production incidents happen in real time. A critical CICS abend at 2am in New York does not wait for a timezone-friendly handover. The person diagnosing it needs to know that environment, needs to know the history of recent changes, and needs to be reachable immediately. Outsourcing models built around shift handovers and ticket queues do not handle production crisis response well.
Regulatory and security constraints. Many financial institutions and government agencies operate under regulatory and security requirements that restrict who can access production mainframe systems. Citizenship requirements, security clearances, data sovereignty rules: these create hard constraints on offshore access regardless of cost considerations.
It is rarely a binary choice between fully onshore and fully offshore. The most common model in large financial institutions is hybrid:
Onshore senior systems programmers handle critical incidents, architecture decisions, capacity planning, and anything that requires immediate response or deep environmental knowledge. Offshore teams handle routine tasks: monitoring, lower-priority PTF application, documentation, and non-critical configuration work.
This model has been reasonably stable because it reflects the actual nature of the work. The routine parts of systems programming can be systematised and distributed. The diagnostic and crisis response parts cannot, at least not without unacceptable risk to production stability.
For someone building a career, the implication is clear: the further you move toward the deep technical skills, dump reading, WLM performance tuning, subsystem internals, security architecture, the more your work resembles the onshore-retained category rather than the offshore-eligible category.
For DB2 DBAs (and DBAs of other mainframe DBMSs like IMS), the picture mirrors application development but with important nuances.
Routine DB2 DBA work (performance monitoring, runstats, reorganisations, space management, standard tuning) has followed the same offshore trend. The large outsourcing firms all have DB2 mainframe DBA practices and this work has moved significantly.
More protected from offshoring:
Hybrid models are common here too. Offshore teams handle routine monitoring and maintenance, onshore senior DBAs handle capacity planning, subsystem upgrades, and anything touching production data in a sensitive context.
The managed services question deserves its own honest treatment. Providers like Ensono and Kyndryl have already taken over the infrastructure and routine maintenance layer for many organisations. If data sovereignty compliance mandates tighten, which seems increasingly likely, that could actually create a floor for dedicated infrastructure rather than eroding it further.
On modernisation replacing the need for mainframe skills entirely: be cautious about this assumption. Moving from a well-understood enterprise mainframe environment to a modern distributed architecture does not simplify the problem, it often multiplies it. You start with one hippopotamus you know well. You end up with a zoo full of animals nobody has seen before. Kubernetes clusters, microservices, cloud databases, API gateways: each needs its own specialist. The institutional knowledge problem does not go away. It spreads across more systems.
The real forcing function is whether modernisation completes before the 50+ cohort retires. In most large financial institutions, the honest answer is that it won't. That leaves managed services providers as the likely inheritors of a significant portion of that knowledge base, which is probably the direction things are heading for many mid-size shops, regardless of what the modernisation roadmaps say.
AI doesn't simplify this picture, it reshapes it from multiple directions at once.
Routine monitoring and anomaly detection is increasingly automated, adding pressure on top of offshoring for lower-skill work. But AI tools still need experienced people to interpret results and make the final call: a tool can flag that a buffer pool is undersized, but deciding how to rebalance it without impacting production requires context the tool doesn't have.
There's also a growing category of new work: organisations building AI and ML pipelines that need to consume mainframe data in real time. That requires someone who understands both the mainframe data layer and modern data engineering. That combination is rare and in demand, and it didn't exist five years ago.
So AI is simultaneously automating some mainframe roles, protecting others, and creating entirely new ones. The net effect is not "AI replaces mainframe professionals." It's "AI changes which mainframe skills matter most."
The people who have built durable mainframe careers over the last twenty years have generally done one of three things:
What each of these paths has in common: they require depth, not just familiarity. The outsourcing pressure is strongest at the surface of the work, the routine, the repeatable, the well-defined. The deeper you go, the more protected you are.
Mainframe is not uniformly outsourcing-resistant. The application development layer has moved offshore to a significant degree and that trend is not reversing.
Systems programming, particularly at the senior diagnostic level, has remained primarily onshore because the nature of the work makes it structurally difficult to offshore effectively.
Managed services providers are consolidating the routine operational layer. Modernisation is happening but slower and more complex than most roadmaps assume. AI is changing which skills matter, not eliminating the need for expertise.
The most outsourcing-resistant path in mainframe is not the most obvious one. It is the one that requires the deepest technical knowledge of the platform, which is also, not coincidentally, the most interesting and best compensated.
A final note: this is one perspective based on experience across specific markets. Outsourcing dynamics vary by country, industry, company size, and the specific regulatory environment. If your experience has been different, I'd genuinely like to hear it.
Also worth reading: Starting Mainframe Work at a Bank: First 90 Days · Shifting to Systems Programmer, Is It Worth It? · Is Mainframe a Good Career Choice in 2026?