Some programming languages come and go, while others come and stay for a while. In the case of COBOL, “a while” means more than six decades: The language debuted in 1959 and is still alive and kicking. In fact, the consultancy COBOL Cowboys says that roughly 90 percent of Fortune 500 firms have production systems that rely on COBOL code.

COBOL is a great litmus test of your notion of “legacy” applications: If you’re using the term as synonymous with “old,” you’re right in the sense that the language is now, in human terms, in its golden years. But if you’re using “legacy” to automatically mean “outdated,” that’s far from a given.

“COBOL is an established programming language,” says Bhabani Misra, an associate dean at the University of St. Thomas in St. Paul, MN, where he oversees graduate programs in the software engineering department. “Applications written in this language touch everything we do, from airline reservations to healthcare and phone calls. These applications solve thousands of problems every day.” COBOL is also widely used in government IT organizations.

[Which IT jobs will position you well for the future? Read also: 5 flourishing and 5 fading IT careers. ]

COBOL is not going to excite developers who write cloud-native applications to run in Kubernetes. But that doesn’t negate the value of many longstanding and often mission-critical applications. Is transaction processing – especially when the volume of those transactions is high – a fundamental requirement of yours? Guess what, COBOL still does that well.

Jeff Hall, senior consultant at Wesbey Associates, cut his teeth in IT writing COBOL applications. He notes that because there will always be newer, shinier languages, some mistakenly assume that COBOL has become obsolete. Worse, they assume it was “abandoned” because it was a poor language. Not so, according to Hall: “It was not a poor tool and never was.”

Two reasons COBOL gets a bad rap

Two big factors underpin the misconception that COBOL is “bad” in some way.

1. COBOL applications tend to be large monoliths – very large, in the case of decades-old systems.

“The biggest problems organizations face with COBOL is the amount of code they have written in COBOL,” Hall says. “ In an organization with applications written in COBOL, there are typically tens to hundreds of millions of lines of code.” Those millions of lines of code represent years of business rules and logic, which is why many companies are reluctant to replace those systems, Hall explains.

Mike Loukides, VP of content strategy at O’Reilly Media, notes COBOL was born before more flexible approaches to software development, such as microservices architecture.

“COBOL was invented before we understood the importance of making programs that were modular or had the tools to do it,” Loukides says. “Monoliths aren’t necessarily bad, but they’re certainly hard to understand. They’re hard to modify as you need new features – and they tend to become even harder to modify over time.”

2. COBOL seems stuck in a perpetual cycle of skills shortages. It most recently made headlines again as unemployment claims skyrocketed during the COVID-19 crisis, and state systems sagged under the weight of the demand. The governor of New Jersey, for example, put out a public plea for COBOL programming help. (In response to that talent need, IBM is offering free open source training on this skill.)

“Every few years an alarm goes up about the shortage of COBOL programmers. And then it dies down,” Loukides says. “It’s hard to tell whether that’s because programmers are found, or because other solutions are found.”

Misra says there’s a relationship between COBOL’s age and the age of most programmers with deep expertise in the language.

“Individuals with a COBOL skill set are nearing retirement, and many companies are realizing they don’t have the candidates with the appropriate skills to keep COBOL functioning,” he says. As a result, companies are being forced to get creative and redirect talent from elsewhere in the organization, sometimes working in partnership with universities like Misra’s to develop new skills. The other choice: Application modernization projects.

4 factors to weigh before modernizing a COBOL application

For IT leaders weighing COBOL modernization projects, these are rarely simple go/no-go decisions. There are plenty of legitimate reasons why an organization might opt to stick with their COBOL systems, just as there are plenty of reasons why it might decide it’s worth the costs and effort to modernize – or replace – a COBOL application.

With that in mind, experts shared four important questions to consider when you’re evaluating whether or not to modernize a COBOL system, starting with the talent concern.

1. Do you have the talent /skills needed to properly maintain the application?

First, some good news: There are plenty of resources for COBOL training, including university courses, boot camps, online education, and other options, Loukides notes. (O’Reilly, known in the tech industry for its publishing, conferences, and training programs, offers Beginning COBOL for Programmers, for example.)

But that doesn’t mean there’s a bountiful supply of COBOL talent out there itching to keep your systems running well.

“If we’re having trouble finding COBOL programmers to maintain code today, what will that look like in 10 years?” Loukides asks.

There’s another way of looking at the talent question: How many COBOL programmers do you currently have working on your application(s)? Do you have a large cohort of programmers nearing retirement? Conversely, if the answer is “one COBOL programmer,” you should ask: What happens if that person leaves?

Software engineer Randy Ryschon was the sole developer responsible for a billing system written in COBOL that he’d maintained and updated for 24 years. The company’s eventual decision to replace it was based on that basic reality.

“Although deemed legacy, it successfully billed $80 million per year with growing revenue,” Ryschon. “I was the sole developer, which drove the decision to migrate.”

2. Why are you modernizing or migrating?

“Because COBOL is old” is, on its own, not a great reason to undertake a modernization effort. In fact, it might be a terrible reason.

CIOs and other IT leaders need to look at this choice from a cost-benefit perspective, Misra says. The latter should significantly outweigh the former; otherwise, you might be undertaking a heavy-duty project to achieve outcomes that don’t produce significant business value. Ryschon points out that you also need to consider how much time you have to devote to the project: Depending on the particulars, you could be looking at a multi-month or even yearlong-plus process.

If you’re looking at a COBOL system as part of a broader modernization of your application portfolio, then you also need to answer the “why” question in relationship to “when.”

“I always point people to Figure 2 on page 28 of the Federal CIO Council’s Application Rationalization Playbook when prioritizing what should and shouldn’t get modernized,” says David Egts, chief technologist, North America public sector for Red Hat. “Is the application providing critical business value? Is it going to be retired soon? No sense modernizing something that adds little value or will be replaced with something else in the near future. The same goes if you have applications in need of modernization that would have a greater impact on service delivery.”

There are various ways you can frame the big picture questions of “why” and “when” to potentially modernize or migrate a COBOL app. Todd Loeppke, lead CTO architect at Sungard AS, shares two examples: “Are there better ways to accomplish the same outcome?” and “What is the current solution lacking?”

“There could be a need for improved security, zero downtime upgrades, improved performance, better resiliency, better integration with the company data lake so that AI/ML tools can be utilized, et cetera,” Loeppke says. “Can we accomplish this with the existing platform?” If the answer is “no” or “only with great pain and difficulty,” he says, you might have a modernization candidate.

Ryschon shares some related development-oriented questions to consider: “What is the system doing or not doing that warrants the need for change?” and “What is the general quality of the code?”

Evaluating your project should start with a robust list of such questions; then you can appropriately weigh the answers against the alternative of sticking with the current system, Loeppke says.

Let’s examine two more important questions you should ask:

3. Does this have to be an “all-or-nothing” choice?

The short answer: No.

“You may not have to completely rewrite an application to make it cloud-native,” Egts says. “Perhaps a lift-and-shift migration to the cloud would be a solid first step on a longer journey, which would lead to augmenting new layers to make the application API-driven, to ultimately refactoring it as microservices.”

If your primary motivation is to move to a more modular mode of software development, then you don’t have to look at it as a demolition-and-rebuild project.

“I don’t think it’s an all-or-nothing decision – i.e., let’s scrap our legacy software and replace it by January 1, 2021,” Loukides says. “One advantage of a microservices approach (and also one of the difficulties) is that you can split your existing infrastructure into different independent services. So it’s not an all-or-nothing thing. You can start with pieces like authentication, then move on to things like billing and other services.”

In this sense, Loukides adds, software design is more important than the programming language itself.

[ Learn the do’s and don’ts of cloud migration: Get the free eBook, Hybrid Cloud for Dummies. ]

4. What does the future look like?

“Who knows?” might be a realistic answer; we can’t actually predict future events. But you can anticipate some of them.

Loeppke asks: “Will emerging technologies negatively impact the current solution in the next two to three years? If so, how does a new architecture [address] that?” For example, if you know your organization is moving to a DevOps (or similar) model, that should be part of the equation.

Egts points out that any modernization discussion – of a COBOL system or otherwise – shouldn’t just be a technology decision, but a people and process decision.

“If you only modernize the technology with a faster computer, you may not be addressing underlying reliability and scalability issues forcing the modernization effort in the first place,” Egts says. “These issues can be addressed by reskilling the workforce to write cloud-native applications as well as using Agile and DevSecOps practices.”

Loukides notes that major migration projects are better served when they’re not conducted in “crisis mode:” The path forward will be more straightforward if you are proactive rather than reactive. Think about various external demands and what they might require in terms of code changes; everything from tax law changes to supporting cryptocurrency transactions to new business models might apply, Loukides says.

In this sense, the answer to “should we modernize?” is always yes – you want to be continuously evaluating things and updating things on your schedule, not under the duress of a proverbial five-alarm fire.

“The real decision is whether that’s going to be a crisis-mode yes or a yes that lets you think about the best approach, explore options, and design an infrastructure that will last you for another 20 or 30 years,” Loukides says.

Don’t look now, it’s the Y2038 problem

Loukides points to another “Y2K”-type event: What impact could it have on your system(s)?

“There’s been some talk about 2038, at which point timekeeping on 32-bit Unix systems will run out of bits – and 2038 isn’t as far off as it seems,” Loukides says.

Indeed: Loukides points out that we’re already closer to 2038 than we are to 2000.

[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]