Are Mainframe Computers Still Around?

As someone who started in that era, I admit I’m probably showing my age with this topic. But it’s also an interesting question because many people today have never even seen a mainframe. They know about PCs, servers, cloud computing, and AI, yet they may not realize that some of the world’s most critical systems are still powered by technology that has been evolving for decades.

So, are mainframe computers really a thing of the past, or have they simply become the quiet workhorses that most people never notice?

Now, I really haven’t seen much discussion about mainframes over the last several years. If they do come up, the conversation usually shifts toward supercomputers. But that’s not what I’m talking about, or even thinking about.

I’m talking about those big business computers that companies relied on for their day-to-day data processing. The systems that handled payroll, inventory, banking transactions, insurance records, and countless other business operations.

If you’re old enough, you probably remember seeing people sitting in front of terminals with nothing but green text on a black screen. There were no fancy graphics, no desktop wallpaper, and no web browsers. Just a keyboard, a monitor, and a direct connection to a computer powerful enough to serve hundreds or even thousands of users at the same time.

Then came the personal computer revolution and the rise of client-server computing. Businesses gradually began moving away from relying entirely on mainframes. One of the biggest reasons for that shift was cost.

Owning a mainframe wasn’t just about buying an expensive computer. Companies also needed trained personnel to operate it, program it, maintain it, and keep it running around the clock. For large corporations, those costs could be justified. For many smaller businesses, they simply couldn’t.

As personal computers became more powerful and servers became more capable, businesses suddenly had new options. They could buy software off the shelf instead of developing many of their own applications. They could build smaller server networks that cost a fraction of a mainframe. Today, they can even rent computing power from cloud providers and let someone else manage the hardware entirely.

Another major change was usability. Instead of text-based terminals with green characters on a black screen, graphical user interfaces made computers easier to learn and use. Employees no longer needed to memorize commands. They could point, click, and navigate their work with far less training.

For many organizations, the move away from mainframes wasn’t because the technology had failed. It was because newer technologies offered a less expensive solution that met their particular needs.

So, now you may ask. Are there still mainframe computers still around? The answer is yes, and more than you might think. Any major business that has to handle high volumes of transactions still use mainframe computers. The one thing that these computers were always good at was processing large amounts of data. The green screens are pretty much gone now because mainframes are able to interface with the servers and PCs that we are so use to seeing now days.

Client-server systems absolutely have their place. We will never go back to a world where mainframes are our only source of computing. Personal computers, servers, and cloud services have transformed how businesses operate and have made computing more accessible than ever before.

But that doesn’t mean mainframes disappeared.

Large organizations such as utility companies, banks, insurance providers, airlines, and government agencies still depend on them today. While client-server systems are excellent at providing an immediate response to a user’s request, mainframes continue to shine when it comes to processing enormous amounts of data reliably and efficiently.

One area where they excel is batch processing. Batch processing is work that doesn’t require an immediate response from a user. Instead, jobs are scheduled to run during the evening, overnight, or other off-hours when system demand is lower.

Rather than someone sitting at a keyboard entering transactions one at a time, the computer automatically runs programs that process hundreds of thousands, and sometimes millions, of records. These jobs might generate customer bills, update account balances, process payroll, create monthly statements, calculate interest, or perform other high-volume tasks that are scheduled to run daily, weekly, monthly, or yearly.

It’s not flashy work, and most people never see it happen. But every morning, businesses expect those jobs to be finished, accurate, and ready for another day. That’s one of the reasons mainframes continue to earn their place in the modern computing world.

Here’s an interesting fact that many people may not know.

A large number of these mainframes were, and still are, programmed using a language called COBOL. COBOL isn’t a flashy programming language that creates modern graphics or the latest mobile apps. It was designed for one primary purpose: processing large amounts of business data accurately and efficiently.

Because COBOL isn’t the newest or trendiest programming language, finding experienced programmers who still know it is becoming more difficult. (Yes, I can still program in COBOL.)

That creates a very real concern for many businesses. While newer programming languages continue to grab the spotlight, countless critical business systems still depend on COBOL every single day.

Perhaps the most surprising part is just how much COBOL is still in use. Depending on the study, experts estimate that between 200 billion and 800 billion lines of COBOL code remain in active production worldwide. The higher estimates, often cited by companies that support enterprise software, place the number at around 800 billion lines of code. Regardless of which estimate you use, the message is the same: an enormous amount of the world’s business infrastructure still relies on software that was first introduced more than 60 years ago.

That’s one of the reasons discussions about mainframes and COBOL continue today. They aren’t simply relics from computing history. They remain part of the foundation that quietly powers many of the services we use every day.

This enormous amount of existing COBOL code is another reason organizations continue to rely on mainframes today.Over the years, I was involved in several projects that attempted to move away from mainframes and replace them with newer technologies and programming languages. More often than not, those projects ran years past their original completion dates and ended up costing far more than anyone expected.There are many reasons for this. As projects move forward, new requirements are discovered. Businesses change how they operate. Users often realize that the old system handled situations they had forgotten about. Perhaps the biggest challenge, however, is understanding the business logic hidden within decades-old COBOL applications.Many of these programs have been modified and enhanced over the course of 30, 40, or even 50 years. They don’t just contain computer code. They contain years of business rules, exceptions, and knowledge that may never have been fully documented.

This enormous amount of existing COBOL code is another reason organizations continue to rely on mainframes today.

Over the years, I was involved in several projects that attempted to move away from mainframes and replace them with newer technologies and programming languages. More often than not, those projects ran years past their original completion dates and ended up costing far more than anyone expected.

There are many reasons for this. As projects move forward, new requirements are discovered. Businesses change how they operate. Users often realize that the old system handled situations they had forgotten about. Perhaps the biggest challenge, however, is understanding the business logic hidden within decades-old COBOL applications.

Many of these programs have been modified and enhanced over the course of 30, 40, or even 50 years. They don’t just contain computer code. They contain years of business rules, exceptions, and knowledge that may never have been fully documented.

When developers attempt to replace these systems, the challenge isn’t simply writing new code. It’s making sure the new application produces the exact same results. In industries like banking, insurance, utilities, and government, accuracy isn’t optional. Processing millions of transactions means even a tiny mistake can have enormous financial consequences.

I also know that the U.S. government has made several attempts to modernize or replace some of its older mainframe systems. The IRS and Social Security Administration are two examples that immediately come to mind. Many of these modernization efforts have gone over budget, missed their deadlines, and in some cases have even been canceled before they were completed.

That’s one of the biggest reasons many organizations continue to modernize around their mainframes instead of replacing them outright. When a system has proven to be reliable, accurate, and capable of handling enormous workloads, replacing it is often much more difficult than people imagine.When developers attempt to replace these systems, the challenge isn’t simply writing new code. It’s making sure the new application produces the exact same results. In industries like banking, insurance, utilities, and government, accuracy isn’t optional. Processing millions of transactions means even a tiny mistake can have enormous financial consequences.That’s one of the biggest reasons many organizations continue to modernize around their mainframes instead of replacing them outright. When a system has proven to be reliable, accurate, and capable of handling enormous workloads, replacing it is often much more difficult than people imagine. I’ll be honest. Over the years, I’ve read countless articles and had many discussions about the enormous amount of COBOL code still running on mainframes. I truly expected that number to be much smaller by now.

Now, I don’t think mainframes are ever going to disappear. As I mentioned earlier, their ability to reliably process enormous volumes of data for specialized tasks such as payroll, billing, banking transactions, and other high-volume business processes isn’t going away anytime soon. That’s exactly what mainframes were designed to do, and they continue to do it exceptionally well.

What I do think is that we’re eventually going to reach a tipping point with the aging COBOL applications that run many of these systems. As the number of experienced COBOL programmers continues to shrink, organizations may find themselves with little choice but to modernize those applications, regardless of the cost.

That doesn’t mean the mainframes themselves have to disappear. Modern programming languages can also run on today’s mainframes, and many organizations are already moving in that direction. The challenge isn’t replacing the hardware. It’s replacing decades of proven business logic while maintaining the same level of accuracy and reliability.

So, while the future of COBOL may eventually change, I believe the future of the mainframe is far from over.

And just like old programmers like me, these systems have continued to adapt rather than disappear. Experience still has value, even if it isn’t the newest thing around.

Which brings me to one final thought.

For years, one of the biggest obstacles to replacing COBOL applications has been the sheer amount of code and business logic that has accumulated over decades. But today we have something we didn’t have before: artificial intelligence.

Can AI analyze millions of lines of COBOL, understand the business rules buried within that code, and help convert those applications into modern programming languages while preserving their accuracy? If it can, AI may become one of the biggest reasons organizations can finally modernize systems that have resisted change for decades.

I don’t know if that’s the answer. But it’s certainly a question worth asking.