I completely believe it. The critical paths in critical software operated by every major company or governmental entity that you deal with were written in COBOL/Fortran/Progress and run on IBM mainframes (hence why they are still a tech titan and will probably remain so for the foreseeable future). And they aren't moving away any time soon because they are too important to fail.
Things that are largely or entirely done on mainframes today:
- Airlines: ticket reservations, crew management, route planning, critical flight operations, some parts of traffic control
- Banking: money movement, loan origination (though some of this has moved off over the years), account management (most of the slick frontends you use on the daily are just wrappers around mainframe programs)
- Government: So much state government stuff (licenses/registrations, tax systems)
I haven't personally done a lot of work on the mainframe, but as I understand it, they are still unbelievably robust machines that are extremely redundant and reliable and still have unmatched uptime guarantees.
Many of these claims about COBOL originate from reports which are decades old. I sometimes hear a stat that 5 billion new lines of COBOL are written per year. When I looked into this claim, it turned out that it originated from a Gartner report written in the 90s.
And they do not link out to anything that even remotely validates this
> Various recently published COBOL articles state the following…
For all we know those articles could be LLM written blogpost spam that just happens to support what the authors of a COBOL consulting firm want us to believe
Mainframes are king on Wall Street and any company dealing with extremely high volume of transactions. They are hardware optimized to process millions (billions?) txns per second. Nothing yet can still compete. The main language for Mainframes is COBOL.
Replacing just any failed hardware component does require downtime, that is critical for any financial business.
So he number does not surprise me.
Many companies tried to move off mainframes, but they realized the costs and risks are to great to bet their business in order to be "cool".
I am absolutely certain that there is a huge amount of COBOL code underpinning financial transactions, but the 65% and 85% numbers seem suspicious to me in 2025.
Hey all, I'm the poster but I don't have a relationship to the domaine/site here. I just found it interesting and was hoping that people would chime in with arguments/counter-arguments.
I've also now been trying to chase down sources for these numbers - one archived page [0] from 2013 might have been the origin for this, but it itself sources unlinked reports such as "Aberdeen Group; Giga Information Group; Database & Network Journal; The COBOL Report; SearchEngineWatch.com; Tactical Strategy Group; The Future of COBOL Report"
---
I can ... "half" believe it's not that 90% of Fortune 500s own/run/manage their own custom COBOL code, but rather that many of them rely on a few HR systems, or payment systems, that are written in COBOL. That's one theory.
Again, sorry if this seems a bit outlandish and/or maybe an exaggerated claim - but I do appreciate everyone's input here. I feel like it would be great to fully debunk this, or actually to collectively learn something ha. Cheers
We did a COBOL project in our CS program way back in college (circa 2002). I remember liking it a lot considering it was "mostly write code in Plain English". AI Prompts have nothing on COBOL :). They were doing it way before it was cooler.
Regardless of what we think of it, we must appreciate its longevity and reliability. Sure, it is hard to change and all that but can we really imagine today's modern tooling surviving 50 years and counting ? I don't know.
This site is obviously just an ad, but it does remind me that I do want to learn about how modern mainframe systems work. I understand the basics of COBOL but I understand nothing about how mainframes execute it in such a way that it can process the sheer volume of data that is crunched. The OS and execution environment sounds wild and completely foreign to me. Does anyone have any good resources on how to learn about the computational model of modern mainframes?
"supports" is a very generous description! Kind of like how a collapsing mine underneath a house "supports" it... as long as you don't mind a bit of subsidence.
> COBOL is 65% of active code used today; and runs 85% of all business transactions.
That... just doesn't feel plausible to me. I might believe the second half of that sentence, but I don't think I believe the first.
I completely believe it. The critical paths in critical software operated by every major company or governmental entity that you deal with were written in COBOL/Fortran/Progress and run on IBM mainframes (hence why they are still a tech titan and will probably remain so for the foreseeable future). And they aren't moving away any time soon because they are too important to fail.
Things that are largely or entirely done on mainframes today:
- Airlines: ticket reservations, crew management, route planning, critical flight operations, some parts of traffic control
- Banking: money movement, loan origination (though some of this has moved off over the years), account management (most of the slick frontends you use on the daily are just wrappers around mainframe programs)
- Government: So much state government stuff (licenses/registrations, tax systems)
I haven't personally done a lot of work on the mainframe, but as I understand it, they are still unbelievably robust machines that are extremely redundant and reliable and still have unmatched uptime guarantees.
Many of these claims about COBOL originate from reports which are decades old. I sometimes hear a stat that 5 billion new lines of COBOL are written per year. When I looked into this claim, it turned out that it originated from a Gartner report written in the 90s.
And they do not link out to anything that even remotely validates this
> Various recently published COBOL articles state the following…
For all we know those articles could be LLM written blogpost spam that just happens to support what the authors of a COBOL consulting firm want us to believe
Mainframes are king on Wall Street and any company dealing with extremely high volume of transactions. They are hardware optimized to process millions (billions?) txns per second. Nothing yet can still compete. The main language for Mainframes is COBOL.
Replacing just any failed hardware component does require downtime, that is critical for any financial business.
So he number does not surprise me.
Many companies tried to move off mainframes, but they realized the costs and risks are to great to bet their business in order to be "cool".
I am absolutely certain that there is a huge amount of COBOL code underpinning financial transactions, but the 65% and 85% numbers seem suspicious to me in 2025.
But can it do HFT?
The information and the statistics on the page have been the same since at least 2014 (when the first instance was recorded in the Internet Archive).
You're right, I wonder how they calculated that number...
I can’t prove it but it sounds like complete bs. How is “active code” even measured?
>We offer experienced COBOL (and other software) consultants
Hmmm
Imagining an exec coming across this article in 2025 and talking about COBOL like they are currently talking about AI.
"Hey X, can you check with the IT guys how much COBOL we are using and how that number can be increased? Thx"
Maybe this is today. Because, you know, AWS is down.
Hey all, I'm the poster but I don't have a relationship to the domaine/site here. I just found it interesting and was hoping that people would chime in with arguments/counter-arguments.
I've also now been trying to chase down sources for these numbers - one archived page [0] from 2013 might have been the origin for this, but it itself sources unlinked reports such as "Aberdeen Group; Giga Information Group; Database & Network Journal; The COBOL Report; SearchEngineWatch.com; Tactical Strategy Group; The Future of COBOL Report"
---
I can ... "half" believe it's not that 90% of Fortune 500s own/run/manage their own custom COBOL code, but rather that many of them rely on a few HR systems, or payment systems, that are written in COBOL. That's one theory.
Again, sorry if this seems a bit outlandish and/or maybe an exaggerated claim - but I do appreciate everyone's input here. I feel like it would be great to fully debunk this, or actually to collectively learn something ha. Cheers
[0] https://web.archive.org/web/20180707025312/https://www.micro...
We did a COBOL project in our CS program way back in college (circa 2002). I remember liking it a lot considering it was "mostly write code in Plain English". AI Prompts have nothing on COBOL :). They were doing it way before it was cooler.
Regardless of what we think of it, we must appreciate its longevity and reliability. Sure, it is hard to change and all that but can we really imagine today's modern tooling surviving 50 years and counting ? I don't know.
I think Grace Hopper invented (or was pivotal in the invention of) COBOL. She was damn good at this nerd stuff.
Grace Hopper developed FLOW-MATIC and she had said 95% of COBOL=60 is FLOW-MATIC.
This site is obviously just an ad, but it does remind me that I do want to learn about how modern mainframe systems work. I understand the basics of COBOL but I understand nothing about how mainframes execute it in such a way that it can process the sheer volume of data that is crunched. The OS and execution environment sounds wild and completely foreign to me. Does anyone have any good resources on how to learn about the computational model of modern mainframes?
"supports" is a very generous description! Kind of like how a collapsing mine underneath a house "supports" it... as long as you don't mind a bit of subsidence.
Poor analogy. The house can be built without a mine underneath it. Those transactions however cannot occur without encountering this code.
IBM mainframes still are core infra for the Fortune 500 and COBOL (and JCL) are common languages in there.
Flagged. It talks about published articles and then doesn't link to them. Give me a break.