IT leaders on DOGE’s bold COBOL ambitions: Pure folly

Many IT leaders scoffed when they heard that Elon Musk’s US Department of Government Efficiency wants to rip out millions of lines COBOL code at the Social Security Administration and replace it within a matter of months.

COBOL is more than 60 years old, and concerns about maintaining the ancient programming language are on the rise, as many longtime COBOL coders head toward retirement and enterprises across nearly every industry remain beholden to it for mission-critical systems.

But the SSA maintains an estimated 60 million lines of COBOL, and while there have been past attempts to replace the code base, it appears to largely be working, with more than 66 million US residents receiving their Social Security payments every month.

It’s unclear why Musk and the DOGE team want to replace COBOL at the SSA. In February, Musk falsely claimed that 150-year-old people were still receiving Social Security benefits, and his assertions were likely based on a misunderstanding of COBOL.

DOGE has been silent about its COBOL plans since the original news reports in late March. The agency did not respond to a request for clarification.

Don’t do it

Several IT leaders, however, urged DOGE to rethink its plans, although some dissenting experts suggested that AI tools are now able to refactor existing codebases and assist with large-scale projects like COBOL replacement at the SSA.

However, when John McKenny, SVP and general manager of mainframe optimization at BMC Software, heard that DOGE planned to replace COBOL at the SSA within months, his reaction was: “You don’t know what you’re talking about.”

COBOL replacement projects of this size can cost millions of dollars and take years to complete, says McKenny, who acknowledges he may be biased toward COBOL.

Digital transformation projects at the size of the reported DOGE plans often fail, McKenny adds. “Most CIOs have either direct or arms-length experience with different transformation initiatives and migration initiatives of that scale,” he says. “There are a few companies that have done it at a much, much smaller scale, but at that scale, those who have tried have failed and quietly walked away.”

While COBOL is an old programming language, it continues to be updated and supports a variety of modern development methodologies, McKenny says. It’s an easy programming language to learn, he adds, and it has an ecosystem of dev tools around it.

COBOL can be difficult to replace, because it is often fine-tuned over a series of years, and the SSA can’t afford to have its systems go down for any length of time, he adds.

“You’re re-architecting decades of business logic,” McKenny says. “There’s middleware dependencies, there’s database connections, and when you think about rewriting something this mission-critical, you need really intensive testing.”

Despite the pressure on many CIOs to eliminate tech debt or replace legacy systems, COBOL use is widespread, with an estimated 220 billion lines of code still in use and 43% of banking systems built on it. A major reason is because COBOL just works, particularly for transaction processing systems, McKenny says.

“It’s really not whether you can rewrite COBOL in Java or Python; it’s really about whether you should,” he adds. “Changing a language out for the sake of changing language out just doesn’t make sense.”

DOGE is unrealistic

McKenny, as a mainframe optimization executive, is invested in COBOL, the longtime programming language for big iron. But other IT leaders also question the goal of replacing millions of lines of COBOL in months.

Large COBOL-based systems often include “countless” work-arounds and organization-specific code changes that are difficult to identify, says Ryan Frankel, president and CTO of HostingAdvice, a web hosting review and education site.

“Replacing COBOL systems at the Social Security Administration within a few months is highly ambitious and unrealistic due to the complexity of legacy code built up over decades,” says Frankel, a former COBOL coder. “A rushed rewrite risks introducing critical failures in a system that millions rely on. Social Security is not something to ‘fail fast’ on.”

In some cases, organizations may see some benefits from moving to a newer code base, but making the change within months appears to be unrealistic, adds Amrit Jassal, CTO and co-founder at cloud collaboration vendor Egnyte.

“In general, rewriting any legacy system needs to make a business case,” he says. “The case against moving on from COBOL is that a mainframe and COBOL system excels for transactional data.”

The SSA’s COBOL-based systems would have to be reverse-engineered to ensure proper test coverage of the new code, a major undertaking, Jassal adds. If possible, DOGE could attempt to rewrite the code in modular chunks, he says, but it’s unclear if that approach would be possible at SSA.

“If the existing systems meet the business requirements, then I don’t see any issues in continuing to run COBOL at government agencies and organizations at all,” he says. “A rewrite is the last thing one should consider for a system that is running fine.”

Keeping the status quo

Nevertheless, many CIOs see tech debt as a major problem, with many looking for cost savings from replacing legacy systems to pay for new AI initiatives.

Jassal and McKenny argue that sometimes the best move is no move. CIOs should consider keeping legacy systems that work without major maintenance costs involved, they say.

IT leaders should have a compelling reason to replace legacy systems and code, McKenny says. Mainframes running COBOL code have survived when other IT systems have fallen out of favor, he adds.

In some cases, pressure to replace legacy code focuses on the wrong problem, but CIOs should drill into the actual challenge that needs to be solved, he adds.

For example, if organizations depending on COBOL are worried about retiring developers, they can train younger coders on the programming language, and if COBOL developers are using old tools or process, CIOs can update those pieces without replacing an entire code base.

“If there’s pressure to improve development velocity, take a look at that,” he says. “If there’s pressure to address a workforce transition, is there some training that you need for that team?”

CIOs should consider replacing legacy systems in stages and fully consider the business justifications before pulling the trigger, Jassal recommends. “You can actually attack the problem piecemeal,” he says. “When you are looking at large-scale rewrites, it’s almost like you’re trying to change the engine in midflight.”