Cover image for The surprising longevity of mainframes

The surprising longevity of mainframes

adambrandizzi profile image Adam Brandizzi ・3 min read

Days ago, I read a post that said something like this:

There's a lot of mainframe developers that are currently out of a job because they refused to look ahead. [...] now, many of them are scrambling to catch up on 30 years of technology.

Well, I never worked with mainframes myself but that sounded dubious. I had contact with mainframe developers, they did not seem in low demand at all. What happens is, the dynamics of the mainframe environment is surprising for most of us new developers.

Sectors such as government, banking and telecommunications still have a large infrastructure based on these machines. Those systems are decades old and work quite well until today. Sunsetting them is really expensive and, in general, they do not cause problems. For this reason, many organizations have no plans to migrate them to other platforms. As a consequence, there is always someone hiring programmers for these platforms.

85% of our typical daily transactions such as ATM withdrawals and credit card payments still go through mainframe systems. (Source)

In fact, these positions tend to compensate well. There are few mainframe developers for a steady demand. With many of them retiring, the demand can even get higher. In fact, the labor costs used to be one of the reasons to move out of mainframes.

Experienced COBOL programmers can earn more than $100 an hour when they get called in to patch up glitches, rewrite coding manuals or make new systems work with old. (Source)

Anyway, these platforms did not stagnate. IBM just released a new machine some time ago. Neither are they an exclusive choice: most often than not, these systems pair with newer technologies. My bank Android app, for example, consumes data that come from mainframes through many gateways. Or see this amazing story of integrating some old systems with new tech.

Because a mainframe offers reliable performance and strict security, it is often the on-premise component of a hybrid cloud environment that processes and stores an organization’s most sensitive data. (Source)

What make mainframes less common is, I believe, their price. Their cost has a good reason: A mainframe can be as powerful as a cloud data center — indeed, some are cloud data centers. However, most companies do not start with enough money, or even the need, for such power. For many of us, it is more cost-effective to start with inexpensive platforms and grow them into distributed systems.

Of course, there are concerns in this ecosystem. The best developers are retiring. Also, much of that code is hard to maintain, made before we even knew much about software engineering.

The mainframe boxes themselves are not aging. In fact they outcompete Microsoft and Linux on features like performance, scalability, security, and reliability. It’s not the machines but applications and programmers that are aging. (Source)

The most experienced ones, however, agree: the solution is not merely rewrite it all. There are communities that bring new blood to this market. It is also possible to bring agility and good quality to old applications — given a organizational culture shift. Indeed, refactoring these applications is necessary even if you want to move off the mainframes.

It sounds weird for us because we do not follow this career path. Yet, the mainframe market is very much alive.

Posted on by:

adambrandizzi profile

Adam Brandizzi


Software developer/Time Lord/Old Man of Restelo working for Liferay.


markdown guide

It's a interesting topic. Currently i work in a big automobile brand, mainly in a .NET website, but most of the data that i manage comes out from a old IBM AS400 mainframe. Somethimes i think, "why just dont migrate all to Oracle / SQL Server?", but the fact is that the AS400 and the plain and old DB2 database works just fine, and the cost to migrate all the batch process to PL/SQL jobs is too big.
The fact is that the people who develop with that platform are above 50 years, and there is too few documentation about how it works. Sometimes i need to modify some program on the AS400 (or even some COBOL), and its really a pain. The syntax and the IDE has nothing to do with the nice C#, Visual Studio and ReSharper.
Despite that, i take that as a challenge and use the experience to enhance my habilities as a programmer. I think that nobody has to cling to any technology, because eventually C# will become old too.
That's why I think it's better to be a generalist programmer rather than a specialist.


Thank you, Dario, for sharing your experience!

This is a point I hear a lot, indeed: dealing with COBOL (or RPG) tend to be painful. As one author puts it:

The second step to refactoring is updating the development environments. Many mainframers still use green-screen editors even though powerful IDEs have been available for at least two decades. These modern IDE are bundled with refactoring tools.

This must be a cultural thing that should be superseded.

Anyway, I agree completely: it is valuable to be generalist. Your experience corroborates that amazingly.


only problem with this IS getting access to training AND systems to develop the skills. its easier to get cloud skills as there are free levels of access for that on amazon. ive yet to see similar for mainframe.


thanks, but i dont qualify as im not a student. trust me, ive looked all over.

Yes, that's a problem. I mean, it is trivial to get started with open source tools and cloud platforms, while mainframes lack public documentation and provides no affordable access channel. That's a pity: I would like to know a bit more about them, at least to prepare to integrate our product better.

oh, they DOCUMENTED out the wazoo! its getting access to the environments and/or affordable (by humans) training.

IBM had a bootcamp package, but its been gutted and i could not get it to work.


Getting out of a mainframe is not easy software wise. Most of the business rules embeded in the code
are often not well documented and the code is closely coupled with app servers that don’t run elsewhere
(CICS is a good example). Given that this code has been fine tuned over decades combined with
the slopiness of today’s coding, you need a lot of horse power to replace them. 😬

Been there decades ago but choose not stay around. Not sure that I would like to spend
my last work days struggling digging for artifacts 🤣


Been there decades ago but choose not stay around. Not sure that I would like to spend
my last work days struggling digging for artifacts 🤣

Yes, that seems to be a common career path: I bet this code is not the most amazing to work with!


I love reading takes like this. Really puts things in perspective.


I'm glad you liked it, thanks :) It is always good to know a bit more about communities we do not take part into.


Sounds legit, I wouldn't host a super duty expensive data to an 3rd party, especially when a country's stability depends upon.


I have the same feeling. The third party providers of today are very inexpensive and amazingly flexible but I'd feel more comfortable to put the crucial data in powerful machines I could control.

(It is interesting to note that many, maybe most mainframes are not owned by their users, though: they are rented, if I recall well. Nonetheless, the user organization has much more control over them than, for example, over AWS servers. In practice, it is as if they had bought some really powerful box.)


ASM 370 still has concepts not implemented in x86 & ARM yet.