This essay offers a practical tip in the system life cycle disposal phase as part of establishing good governance in private companies, non-profit organizations, and public institutions. It is the third part of a nine-part series to support organizations in modernizing their information systems.
The Department of Health and Human Services announced on April 2, 2026 that it had replaced its time and attendance payroll system programmed in COBOL with a secure cloud-based platform.[1]
COBOL refers to the Common Business Oriented Language, a computer software programming language created in 1959. It has been used to run software programs on mainframe computers since the 1960s. COBOL was adopted by government agencies and financial institutions to process high volume transactions.
The General Accounting Office (now the Government Accountability Office, GAO) reported in 1982 that COBOL was widely used in the federal government.[2] The GAO concluded at the time that agencies can recover significant cost savings by reducing their COBOL applications, but cautioned that such a change needs to be carefully implemented.[3] Three decades and seven years later, federal agencies continued to run software programs that relied on COBOL, Microsoft DOS, and other old languages. In 2019, the GAO identified 10 critical systems that had been operating as long as 51 years at a combined cost of $337 million per year to operate and maintain.[4]
Why is it so difficult for organizations to modernize their information systems? What will it take for organizations to replace outdated technology? Are there strategies that can be employed to change organizations?
Samuelson and Zeckhauser conducted experiments to understand how individuals would make decisions given a number of alternatives to pursue. What they found is striking.
“In sum, status quo bias is pervasive. It is a natural consequence of many well-known psychologically based deviations from the rational choice model. As a result the canonical choice model is unlikely to provide a reliable explanation for a substantial range of behavior, including economic behavior.”[5]
People are unlikely to choose a different course of action because they prefer doing what they’ve been accustomed to do over a long period of time. Ironically, Samuelson and Zeckhauser explained that staying with the status quo is a perfectly rational decision, because of the presence of transition costs or uncertainty inherent in pursuing an alternative.[6] A cost may be involved in switching to a new way of doing things. A person may lose what she had valued from the present course.
Status quo bias can be observed in individuals carrying out the same tasks repetitively day after day. In other words, a habit can form that keeps a person doing the same thing.
The information systems (IS) literature has begun to produce studies on how habitual usage of an information system can create resistance to changing to a new system. One study suggests that habit has an influence on continued usage.[7] Another study shows that the prevalence of switching costs increases resistance; but to counter the effect, computer users would need to see a greater amount of perceived value in the new system in order to reduce their resistance.[8] If the benefits of a new information system are not communicated, then computer users are unlikely to change and will continue using their current system.
Polites and Karahanna examined how user resistance turns into inertia. In their words, “Inertia represents a rigid continuance of the status quo.”[9] They found that sunk costs, transition costs, and habitual usage contribute to inertia, which in turn has a negative impact on the relative advantage of using a new system.[10] This finding suggests that even if a new information system is better than the current system, users would still resist switching to the new system. Human behavior is indeed tenacious.
Is there a way to release inertia and change habits? The same scholars drilled down to understand how work tasks can be modified to change behavior. Polites and Karahanna explored several strategies. Leadership can stop the current system outright; employees can become aware of their behavior through monitoring and feedback mechanisms; employees can also be trained to learn about the new system; the computer user interface can be reconfigured (for example, replacing the shortcut icon on the Windows desktop from the old system to the new system); and standard operating procedures (SOPs) can be revised to connect specific tasks and goals to the new system.[11] Among these options, revising SOPs would be the most effective (and neither a drastic nor an intrusive move by management) as employees would understand the reasons why they need to start using the new system. While SOPs would impose new requirements, users will realize that the change is necessary to accomplish work-related goals.
A strand of research examines the level of satisfaction (captured by beliefs and attitudes) in continuing or discontinuing computer software programs. At the individual level, satisfaction is found to have an influence on continuance[12] and that it tends to be at its highest before using a software program and then it drops precipitously after a relatively short period of use.[13] This finding reveals that people’s attitudes toward computer software would turn negative once they realize the software doesn’t fulfill their expectations. The software vendor may have executed a compelling marketing campaign to attract new customers, only to raise expectations so high that don’t match the quality of the software product.
While user satisfaction affects the drive to use computers, other more tangible factors are considered in deciding to decommission and replace a legacy information system. Organizations would assess how much time the system has remaining before the original vendor ends all technical support. The complexity of the system would be reviewed in terms of its size and how much it is integrated with other systems, processes, and dependent components. In a nutshell, organizations examine whether the environment has significantly changed to determine that the procurement of a new information system is in order.
Studies confirm that decisions are based on observable, verifiable facts surrounding the operation of an information system. However, decision-making grows increasingly complicated with large systems. A large system may be used by multiple divisions within an organization (an enterprise resource planning system, for example) or by numerous geographically dispersed entities (an unemployment insurance system, in another case). Large, complex information systems become embedded in equally large institutions. Thus, a decision to change a system is not a simple one that can be rushed.
One study revealed that tension exists in the life expectancy of old and large systems. Swanson and Dans found that large systems have greater maintenance of effort and an extended life, but the remaining life left can be shortened for an old system.[14] An old and large system may continue to provide value to its users, on one hand, but may be somewhat of a pain for the information technology (IT) manager to operate, on the other hand. The IT manager is in a quandary. He understands the implications of continuing the old system, yet knows how important the system is to users. That places a great amount of pressure on deciding how much time, money, and resources should be expended to keep the system operational without it posing a risk or exposing its vulnerabilities to further operations.
A study by Furneaux and Wade provides instruction on deciding factors to replace a legacy system. Their study suggests that an IT manager would not rely on reliability and cost factors to make a replacement decision, but she would replace the system when it no longer meets users’ needs or when no technical support is available.[15] Such a decision, however, would be overridden by the extent to which the system is integrated with other systems and processes. The current system may not be replaced if systems integration is relatively high.
Replacing a complex information system with numerous dependencies can still be done. It may, however, require a significant amount of time and effort to do so. Mehrizi and his team mapped out the process for a group of private companies to convert their information systems operating in Microsoft DOS to Microsoft Windows. They described sequential phases where (1) employees first realize that their legacy system is inadequate; (2) technical specialists then implement some development work to cope with limitations at least temporarily so as to prevent abandoning the legacy system in haste prematurely; (3) mechanisms (gateways) are deployed to transfer resources and data from the legacy system to the new system; and finally (4) efforts are underway to limit and restrict access to the legacy system as employees gain increasing familiarity with the new system through ongoing training and guidance.[16] In addition to all efforts to end operations of the legacy system, another process involves work to acquire a new system. An organization must be able to manage both decommissioning an information system and implementing its replacement in parallel. Mehrizi and his team documented that the complete process to replace a complex system for a large company took more than 10 years.[17]
The effort just described assumes that a legacy system operates in a traditional client-server operating environment. Can the strategies and process be made moot if the system operates on a cloud-based platform? Researchers suggested that a software-as-a-service (SaaS) online solution establishes a new mode of operations that makes the system life cycle process outdated.[18] Although I disagree with their assertion, their argument is compelling to consider.
IT providers have changed their business models in delivering solutions. In the past, software was packaged that had to be installed in a computer following a complicated, lengthy procedure. Organizations would pay a fee to use a particular version of the software. More recently, software is available via the Web where organizations can begin using the software immediately. The IT provider manages all operations, creating new versions and adding new functionalities. Organizations would pay a periodic subscription fee to use the online service and may cancel their subscription. In the previous business model, organizations had to acquire, operate, and maintain all the hardware and networking in addition to purchasing the software product. In the current business model, organizations can reduce their operating overhead by focusing on acquiring and maintaining end-user workstations and an Internet connection.
From the user’s perspective: operating and support costs can be reduced significantly when using a SaaS solution. Discontinuing one online service and switching to another service may hasten the transition process.
One thing that hasn’t changed in either business model is the extent to which a software solution can meet all the needs and requirements of a particular organization. Whether it comes on a CD-ROM or is available online, the provided software is in a form that will attract a mass customer base at scale. That is, functionalities are generalized to suit the lowest common denominator. Such features may be difficult to integrate into an organization’s peculiar environment. While a small business may find generalized software adequate to meeting requirements, a large enterprise would not and would want a customized version of the product.
A SaaS solution may help lower the cost for a large organization. But the modern format of the technology must not drive decision-making to replace a legacy information system. The non-IT elements[19] such as functional requirements, workflow processes, operating procedures, and relevant regulations must be taken into account. If the system is mission critical to operations, the organization must not rely solely on the IT provider to operate the SaaS on a shared public network. In this case, the organization would still maintain hardware and networking equipment in a secured private network.[20] Deciding to change to a SaaS solution is just one variable in the equation to transition from a legacy information system.
Changing information systems necessitates a methodical, thoroughly planned approach. Technology itself absolutely plays a role. Equally or more important are the risks and impacts that such a change will have on the organization, its work environment, its goals, and of course its employees. People may be unwilling to accept a new system, but they can come around once they know the benefits and the reasons for switching. It will take time. Change is difficult for sure, but change is not impossible. Leaders and managers must realize that decommissioning a legacy system and implementing a modern one require long-range planning.
Old and complex systems may have been running for 10 years or a half a century. No reasonable person would expect that stopping a long-running operation can be done in a few months. Transitioning to a new system will involve a yearslong endeavor. Managing the change will span across two or more IT strategic plans.
COBOL may still be around for a few more years. Eventually, its life will expire as it happens with all other technologies, and its performance will be for historians to tell. Are agencies ready to change?
Evidence for Practice
Resistance to change is real, created by habits and insulated and comforted by doing the same thing day in and day out.
Communicating the benefits and reasons for wanting a new system and tactfully weaning users off the current system offer avenues to overcoming user resistance.
Replacing a legacy information system, especially a complex one with interdependencies, requires deliberate actions that may take years—not a matter of months—to complete.
Next Steps for Leaders
The IT strategic planning committee should convene a meeting to discuss if there are information systems that need to be decommissioned. Managerial and technical assessments should be conducted to evaluate present systems including their dependencies. Recommendations should be made for executive action.
The IT strategic plan should be reviewed and modified to include the replacement of any information system that needs to be replaced as determined by executive leadership. The plan would include, among other things, estimated costs for decommissioning the legacy system and implementing a new system, two or three viable solutions for a new system, and procedures for transitioning from the legacy to the new system. More than one multi-year plan may be necessary to manage the change, where subsequent planning covers follow-on activities to ensure successful completion of the replacement.
For those organizations that recently transitioned to a new information system, the standard operating procedures (SOP) manual should be reviewed and revised to align workflows, decisions, and document capture with the new system. Do sections of the manual still refer to the legacy system? Those sections need to be updated. Does the underlying business process continue to have steps reflective of using the legacy system? Those parts of the business process need to be updated as well. The SOP manual must be revised accordingly in order for employees to understand how the new system relates to their work.
Notes
1. Department of Health and Human Services, (2026) “HHS Replaces Legacy COBOL Payroll System, Delivering Faster, More Reliable Services,” Press Release, 2 April, revised 8 April, U.S. Department of Health and Human Services. (Accessed 18 May 2026 at https://www.hhs.gov/press-room/hhs-replaces-legacy-payroll-system-improving-service-delivery.html.)
2. General Accounting Office, (1982) “Improving Cobol Applications Can Recover Significant Computer Resources,” AFMD-82-4, 1 April, U.S. General Accounting Office: 1. (Accessed 18 May 2026 at https://www.gao.gov/products/afmd-82-4.)
3. General Accounting Office: iii.
4. Government Accountability Office, (2021) “Information Technology: Agencies Need to Develop and Implement Modernization Plans for Critical Legacy Systems,” GAO-21-524T, 27 April, U.S. Government Accountability Office: 8. (Accessed 18 May 2026 at https://www.gao.gov/products/gao-21-524t.)
5. William Samuelson, and Richard Zeckhauser, (1988) “Status Quo Bias in Decision Making,” Journal of Risk and Uncertainty 1: 41.
6. Samuelson and Zeckhauser: 33–41.
7. Moez Limayem, Sabine Gabriele Hirt, and Christy M. K. Cheung, (2007) “How Habit Limits the Predictive Power of Intention: The Case of Information Systems Continuance,” MIS Quarterly 31(4): 727–729.
8. Hee-Woong Kim, and Atreyi Kankanhalli, (2009) “Investigating User Resistance to Information Systems Implementation: A Status Quo Bias Perspective,” MIS Quarterly 33(3): 578.
9. Greta L. Polites, and Elena Karahanna, (2012) “Shackled to the Status Quo: The Inhibiting Effects of Incumbent System Habit, Switching Costs, and Inertia on New System Acceptance,” MIS Quarterly 36(1): 24.
10. Polites and Karahanna: 35–36.
11. Greta L. Polites, and Elena Karahanna, (2013) “The Embeddedness of Information Systems Habits in Organizational and Individual Level Routines: Development and Disruption,” MIS Quarterly 37(1): 234, 238, 239, 241–242.
12. Anol Bhattacherjee, (2001) “Understanding Information Systems Continuance: An Expectation-Confirmation Model,” MIS Quarterly 25(3): 364.
13. Anol Bhattacherjee, and G. Premkumar, (2004) “Understanding Changes in Belief and Attitude Toward Information Technology Usage: A Theoretical Model and Longitudinal Test,” MIS Quarterly 28(2): 240.
14. E. Burton Swanson, and Enrique Dans, (2000) “System Life Expectancy and the Maintenance Effort: Exploring Their Equilibration,” MIS Quarterly 24(2): 292.
15. Brent Furneaux, and Michael Wade, (2011) “An Exploration of Organizational Level Information Systems Discontinuance Intentions,” MIS Quarterly 35(3): 588, 590–592.
16. Mohammad Hosein Rezazade Mehrizi, Joan Rodon Modol, and Milad Zafar Nezhad, (2019) “Intensifying to Cease: Unpacking the Process of Information Systems Discontinuance,” MIS Quarterly 43(1): 155.
17. Mehrizi, et al.: 153.
18. Xiao Xiao, Saonee Sarker, Ryan T. Wright, et al., (2020) “Commitment and Replacement of Existing SaaS-Delivered Applications: A Mixed-Methods Investigation,” MIS Quarterly 44(4): 1813.
19. Several elements, both technology related and non-technological (non-IT), comprise a complete IT ecosystem. Read more in: Edward Y. Uechi, (2020) “Chapter 1: The IT Ecosystem: Elements Described,” in Public Service Information Technology: The Definitive Manager’s Guide to Harnessing Technology for Cost-Effective Operations and Services, (New York: Routledge/Productivity Press): 1–25.
20. The private network may be a virtualized environment that operates virtualized instances of computer servers and network applications in a private cloud. It doesn’t necessarily require physical machines operating in physical space.