Organizations stick with legacy applications primarily because of inertia: “If it’s not broken, why fix it?” And it’s undeniably smart logic since it frees up time, energy, and resources for other mission-critical parts of your business that affect your bottom line. So, at what point is it advisable to finally switch from a legacy application?
Managing outdated, legacy applications require highly-specific developers and run much higher operational costs. Let’s look at a specific example from COVID-19, where millions of people filed for unemployment every week. But, the Department of Labor couldn’t process those claims quickly enough, leaving thousands of Americans unable to receive unemployment or pandemic-related stimulus checks. A disproportionate amount of federal agencies (including the U.S. Treasury, IRS, State Department, and NASA) and 45 states, plus the District of Columbia, run their mainframes on COBOL, a 65-year-old programming language that’s slowly being phased out in favor of newer, more versatile languages. Estimates suggest that there are just over 27 million developers; the number who are still COBOL-proficient is vanishingly tiny. While COBOL might be old and inflexible, legacy industries love it for precisely that reason: it’s the backbone for at least 43% of modern banking, and an estimated 95% of ATMs worldwide run on it, apart from usage across private and public institutions where COBOL applications are used to process payroll, manage government pension funds, manage hotel bookings, book airline tickets, etc. So, when the workload ballooned larger than these legacy COBOL applications were designed to accommodate, and since there was no easy way to make these requisite changes on the fly, state governments and corporations like IBM and the Linux Foundation had to put out a call for programmers, offering to hire COBOL experts post-haste or train existing developers to master the language quickly. If these systems had been written in modern programming languages like Python, C++, and JavaScript, modifying their functions or hiring more programmers on short notice would have been trivial. This anecdote has repeated itself in every primary industry, from manufacturing to retail. It is the best argument for retiring legacy systems: they’re often outdated, have a limited talent pool to hire from, are extremely limited, and their functionality scales poorly. These government agencies couldn’t hire experts quickly enough, so they had to default to contractors, paying them up to $100 per hour. If they were trying to hire some languages with even rarer experts, it wouldn’t be unusual to budget up to $500 per hour for any expert with the bandwidth to take on the work. And that’s before you factor in the overhead of integrating such an outdated system with newer tools.
Microsoft released XP in 2001, a popular Windows operating system version. In 2009, they ended mainstream support for it, while extended support continued until 2014. But, as late as 2020, systems used in critical industries like healthcare, defense, and energy were still running Windows XP. Specifically, research by Palo Alto Networks’ Unit 42 shows that a wide range of internet-connected imaging devices—used for taking X-rays, MRIs, mammograms, and CAT scans—still run on outdated operating systems like Windows XP, that can’t be updated, even when they contain vulnerabilities hackers can exploit. In fact, it’s easy for a motivated hacker to disrupt or disable such systems, which is why estimates suggest that ransomware attacks on American healthcare organizations have cost the economy around $77.5 billion in downtime since 2016.
Major oil and gas operators across the United States still run on the aforementioned Windows XP, the same system the United Kingdom uses for its nuclear arsenal. Surveys from as recently as 2019 show that at least one in three businesses still run on Windows XP—industrial machinery, assembly line equipment, US Navy vessels, and even nuclear reactors. Another modern example is SAP’s S/4HANA migration project. Currently, thousands of enterprises run on a legacy SAP Business Suite 7 ERP instance must migrate to S/4HANA by the end of 2027, or pay a premium on additional application support and maintenance, as well as a lack of future development work on the application. In other words, all these tools are still cutting-edge and perform their intended functions flawlessly. But due to the lack of vendor support, they’re hopelessly outdated and would need significant, multi-billion dollar investments to bring them up to date.
Like in the COBOL example we started with, legacy applications are usually adopted early into an organization’s lifetime. They work well with minimal hiccups, and then gradually, an ecosystem of experts and consultants is built around it, fixing problems, tacking on custom software scripts, and going to great lengths to integrate it with the rest of the organization’s stack. Initially central to an organization’s operations, legacy applications often fade into the background, receiving attention only during infrequent maintenance periods. Despite this neglect, they tend to function smoothly. That is, until your organization’s workload increases significantly, turning your legacy application into a bottleneck. Because they were designed or adopted early on, legacy applications tend to fail at critical moments when usage exceeds their low historical benchmarks.”
Modernizing your legacy applications can take months (and even years). Here’s an 11-step process to support your legacy application modernization strategy:
| Business-related factors | Business fit: Does the application fit within new business goals? |
| Business value: Does the application bring greater value to the business? | |
| Business agility: Can the application keep up with the pace of today’s business demands? | |
| IT-related factors | IT cost: Is the total cost of ownership for the application too high? |
| Application & implementation complexity: Does the application require too much oversight to manage and implement? | |
| Risk: Does the application expose the business to new security risks? |
This also involves identifying all legacy applications within your organization’s IT ecosystem and creating a comprehensive catalog that documents their key details, such as application name, version, purpose, functionality, dependencies, and business importance.
Once the inventory is established, the next step is to assess the business impact and technical debt associated with each legacy application. You must evaluate factors such as:
Understanding these aspects will help you prioritize the retirement efforts based on business criticality (i.e., how essential a legacy system is to your organization’s operations), technical feasibility, cost-effectiveness, regulatory compliance, and strategic alignment with organizational goals.
You don’t have to replace your legacy application to modernize your IT. Before you start making any changes, it’s essential to know all your options to make the right digital strategy choices.
Here are seven modernization strategies to consider when building and modernizing your IT roadmap :
Modernization can bring long-term improvements to your business — but what exactly do you need to improve? Identify why you need to modernize your IT infrastructure and what you hope to achieve.
Understand exactly where customers and employees are running into friction and frustration, why your legacy environment is causing it, and how you can modernize to solve that problem.
But you’ll also want to look for areas where your legacy system performs well. Knowing what works is as important for building your strategy as knowing what doesn’t.
Right from the moment IT leadership starts thinking seriously about retiring any legacy application in your stack, you need to consult with stakeholders—basically, everyone interacting with said application—to plan the logistics. You need their opinion to understand if it’s necessary, the pitfalls to avoid, temporary arrangements that can be put in place in the interim, etc.
Whether it’s the controller that manages the application in question, end-users who use it for their day-to-day workflow, or external implementation experts to advise on your switch, these stakeholders will help you avoid costly mistakes and limit unnecessary experimentation to make the required changes faster.