From COBOL to the Cloud? Lessons from Individual Master File, the Massive Software Modernization Project

In the 1960s, as the Apollo missions were getting underway, another government agency was quietly making their own strides in technology: the IRS, with help from IBM, began using the Individual Master File (IMF). The IMF is a running record of individual tax events for each taxpayer in the U.S., spanning decades. The IMF is written in assembly and COBOL. The IRS relies on this antiquated program to this day, despite billions of dollars spent and several failed attempts to modernize it.

I love a good software project story, and the IRS’ story is a juicy one. Reports of their difficulty with technology modernization begin in the 1980s and continue today. Currently, they project that the IMF will finally be retired in 2030. It is the oldest technology system still operational in the US government. In honor of Tax Season 2024, I thought it would be fun to look at what we can learn from the IRS’ failures in software modernization.

Lesson 1: Buy for capabilities and trust, not price.

In 1986, the IRS canceled a $76 million, multi-year effort to replace its aging computer system. This happened after years of fraught tax seasons, with delays, errors, and lost records holding back taxpayers’ tax returns. After a shady bidding process, the losing vendors protested that the system selected wasn’t capable of running COBOL to federal standards. An administrative judge ruled that the contract was full of errors. Additionally, it underestimated the true cost of the system, which he placed at $101 million. An agency official testified that “thoroughness took a back seat to expediency” in the vendor selection process and was quoted as saying, “I basically pretty much started accepting the bottom-line figures in the proposals.”

Fortunately, hardware compatibility is much less of a factor in the buying process these days. But here’s the reality: software modernization projects are rife with complexity and unknowns. It is impossible to accurately estimate how long it will take to replace functionality built up for years or decades. Looking at the bottom-line cost is not the best barometer for a vendor’s ability to smoothly transition you from your old system to a shiny new one. And, as much as you need to get this long-procrastinated project underway, rushing through the bidding process can be a huge mistake.

Key Takeaway

Take your time when selecting a vendor. Pay attention to how deeply they seek to understand your business and your needs. When competing vendors come in with differing estimates, discuss with them and see how they respond. Most modernization projects are both difficult and essential. Choose the vendor you feel excited to work with and believe can get the job done.

Lesson 2: Falling behind is risky and costly.

This interesting nugget from a 1990 New York Times article caught my eye:

In 1976, concerned about the misuse of I.R.S. data during the Nixon Administration, President Carter and Congress joined in halting an I.R.S. plan to purchase a new generation of computer equipment. Instead, the agency was instructed to make incremental improvements in its existing systems.

Is it possible the repercussions of this decision are felt by the IRS to this day? By 1976, their existing computer systems were a decade old. Throughout the 1980s, project after project to revitalize their key systems were started, and then scrapped. Meanwhile, the technology aged and their reliance on it grew – as did the cost to upgrade.

It is always easier and cheaper to upgrade to the next version of something, versus skipping a generation (or 10). It can be tough to invest to upgrade something that seems to be working “just fine” and kick that cost down the road. But those costs pile up.

Key Takeaway

If your business depends on your custom software to run, it is essential to keep your software in good shape. Invest in ongoing maintenance to upgrade libraries and frameworks, maintain security, and monitor performance. And the minute your technology’s end-of-life is announced, it’s past time to modernize or migrate to a new platform.

Lesson 3: Business logic changes lead to complexity and modernization cost increases.

One of the key difficulties of replacing the Individual Master File is that the tax code has changed over time. Each update of the tax code required changes to the IMF and how it handles the data contained within it. Old entries needed to be preserved, but new entries needed to adhere to updated standards. This created enormous complexity in the IMF. And, the complexity will continue to grow with every tax code change, until the IRS can retire it.

This complexity was on full display in 2021, when the IRS needed to deliver CARES Act economic stimulus payments on a quick timeline. I can only imagine how stressed those programmers were, trying to update the Individual Master File in time to issue payments. They actually missed the deadline. Many edge cases resulted in many people not getting payments, or getting them late. And latent code from a 2007 update (the last time the government issued an economic stimulus payment) sent false information about their stimulus payment and tax liability to over 109,000 people. What’s more, key people were diverted from the replacement effort to support the changes needed to comply with the CARES Act – directly contributing to the ongoing schedule delays.

Key Takeaway

It’s important to recognize that the longer your business software has been in use, the more difficult it will be to replace. You’ll be faced with tough tradeoffs. Responding to urgent business needs can impact the delivery timeline for your new software. It’s critical to minimize disruption wherever possible, to keep moving forward. Work to decrease dependence on the old system: instead of trying to move things over all at once, try to build in a way that segments of the business can move over. Invest in building mechanisms to import records from the old system on demand or to keep the two systems in sync during the modernization process.

Lessons from Individual Master File

Software modernization projects are difficult and painful for businesses to undertake. If your business depends on software (and what business doesn’t?), your best way to avoid this pain and difficulty is to keep investing in your software. Don’t defer maintenance, and proactively plan when it’s time to migrate to a new technology platform. Don’t use niche, emerging, or proprietary technologies to drive your business – look for widely-used, actively-maintained frameworks and platforms. Think and budget for the long term when it comes to adopting new technology in your business. It’s easy to become dependent on software, and difficult and expensive to manage big changes.

Conversation

Join the conversation

Your email address will not be published. Required fields are marked *