A Thorough Guide to Legacy Systems, and How to Move Past Them
Like the crumbling walls of an old building, legacy systems represent a major problem for organizations.
Paradoxically, they are instrumental in keeping tasks and processes running, although the risks associated with their use grow over time. But what are legacy systems in the first place?
As a former legacy software user and researcher, I understand how frustrating it is to deal with these products, so I decided to perform additional research and share with you what I have learned about them.
Hopefully, this article will provide you with a comprehensive picture of legacy systems, and also help you identify the most pressing issues for your future digital transformation efforts.
What Is a Legacy System?
A legacy system is an outdated, cumbersome, and increasingly obsolete technology that is still in use.
In the context of information technology, the term refers to old, clunky, non-iterable software products, including operating systems, apps, libraries, and even programming languages. Other terms for “legacy system” are:
Legacy IT system
Characteristics of a legacy system
Legacy systems tend to share a series of characteristics, albeit not each one of them checks the same boxes. Nevertheless, the following aspects are commonly found in legacy systems:
Difficult or cumbersome to operate
Nearly impossible to update, expand, and iterate
Hard to integrate with other systems
Limited functionality (not by design, but in comparison to more contemporary alternatives)
Vulnerability to security breaches
Poor or non-existent documentation
Scarcity or lack of maintenance experts
The stuff of nightmares
Examples of legacy systems
There are countless examples of legacy systems. Some are:
Operating systems: Android 1 to 6 (Marshmallow), Windows XP, Windows 7
Enterprise Resource Planning (ERP): Tradecard, Baan ERP, SAP R/2
Programming languages: OptimJ, FoxPro, PL/B, COBOL
Health software: Google Health, MyWay, Allscripts
It is good to clarify that these represent very obvious examples of legacy systems. There are many other examples, some of which are still produced andcommercialized by vendors in the US and around the world.
Why are legacy systems still in use?
There are several reasons why companies use legacy systems to fulfill their operational needs. Some of these are:
The system has a limited or marginal impact on the organization’s processes
The organization does need to rely heavily on systems (legacy or not) to operate
The organization is accustomed to the system and shows little flexibility to change (the famous “comfort zone”)
The risks of changing systems outweigh the potential benefits of doing so. This is particularly true in industries and areas like nuclear defense, space exploration, and air traffic control
Costs. In certain cases, the cost of replacing core systems is higher than what an organization can afford
Complexity and sensitivity of transition. A good example here is the case of MOCAS, a piece of software that has been in continuous use by the US Department of Defense since 1958
Which organizations are most impacted by legacy systems?
Based on the reasons stated above, there are two types of organizations that legacy software that is more prevalent:
Large organizations that operate on numerous complex, multi-layered workflows
Organizations in which safety and system uptime are critical factors
Examples in the first group include:
Government bodies and agencies
Banks and financial institutions
Transportation and logistics organizations
Examples in the second group are:
Energy generation and distribution companies
Nuclear defense departments
Space exploration agencies
Banks and financial institutions
How do legacy systems affect organizations?
The most common way legacy systems affect organizations is by tampering with their productivity, efficiency, and security levels. Legacy systems pose limitations on what an organization does, but also in what it can do.
Moreover, when a legacy system is put under stress, it can also impede the correct functioning of an organization as a whole.
Take government agencies, for instance. Earlier this year, The Verge reported that at least 12 US states still relied on unemployment support software that was built on ancient COBOL code.
The systems were “working”, but the unforeseen event of the COVID-19 pandemic brought them to the ground. With unemployment skyrocketing, these legacy pieces of software were quickly overrun by the sudden spike of traffic and requests.
As a result, thousands of people found themselves struggling to access the system that was supposed to deliver their unemployment benefits. Feel free to call the pandemic an exception and whatnot, but it definitely exposed the “legacy” status of these systems: cumbersome, inefficient, and virtually impossible to update.
Eventually, the problem became so pressing that private companies began to step in to help fix the problem:
What are the risks of moving past a legacy system?
The two main risks associated with leaving behind a legacy system tend to be the following:
The migration towards a new system goes wrong, deriving in unrepairable damages
The migration goes well, but the new system provokes a series of problems that worsens the organization’s previous issues
Both scenarios are equally dreadful, and it is always recommended that such changes take place under the organization’s leadership and technical teams overview.
There are some nightmarish stories about legacy system migration out there, but if I had to recommend one, I’d go with the one The New Yorker published in November 2018.
It’s about a 1.6 billion dollar legacy health system migration gone wrong, and it never fails to send shivers down my spine whenever I think of it.
How to modernize a legacy system?
For smaller organizations, moving past legacy systems is an attainable goal in the short term.
There are plenty of new software alternatives for SMBs that are easy to onboard, test, and replace. Learning curves come in all sorts of forms and colors, but that will be for each organization to assess and decide upon.
Larger organizations, on the other hand, face a different kind of beast when it comes to legacy system migrations. In their case, everything starts with four major projects:
Identification of needs, risks, and goals
Evaluation of resources and costs
Development of an action plan
It is also fundamental to pay special attention to staff training and system maintenance costs, as these can be particularly heavy on resources.
Of course, this a very brief version of where a migration starts for a large company. The whole process can take several months to prepare, and it requires the leadership and technical teams’ full attention at several points.
Furthermore, it is not uncommon for large companies to hire external professional services firms for further guidance over the process. Since these transitions are both fundamental and stressful, every single detail must be taken into account.
Dealing with legacy systems and transitioning to modern software products is something that most organizations will have to endure at one or more points during their lifetime. That’s what digital transformation is all about.
Unfortunately, there is no “ultimate solution” for nothing, and only a limited amount of companies have the talent and resources to maintain permanent research and development programs for their core systems.
Having participated in a few system migrations over the course of my career (mostly as an observer, but also contributing at some points), I can recommend the following:
Never lose focus on the people who will be using the new system. If it doesn’t work for the users, it will not work for the organization!
Don’t be afraid of migrating, but be prepared for an array of scenarios (including the bad ones)
Consult with the specialists, and ask for second (and third) opinions. There’s nothing wrong with dissent among leading minds, and options are worth it
Image credits: The New York Times, Stackoverflow, Coderthemes.