Legacy Systems: They Are All Fundamentally Obsolete

Some people are afraid to wake sleeping giants, but it's the giants that may not wake the next day that keep government IT personnel up at night. These silent legacy computer system behemoths are a force that disproportionately affects IT departments at all levels of government.

As Dave Rey, a vice president for Salesforce, recently told Government Technology, “Government at all levels remains shackled to legacy systems, which can account for 70 to 80 percent of IT dollars.”  

Defining what constitutes a legacy system is not new. Each agency, academic institution and company seems to have a different standard of what is, and is not, legacy. The issue with so many definitions is it prevents us from seeing a situation clearly and assessing the threat with accuracy. 

Thus far, the definitions are generally based on one or two of the following criteria: 

1. The system is no longer the newest edition.
2. It does not meet the needs of its users. 
3. It is no longer capable of being upgraded/supported. 

Subjectivity and ambiguity are the primary problems with these attempts; furthermore, when evaluating government systems, the definition must be simple, quantitively measurable and precise. 

At the Center for Digital Government,* we took a step back from looking solely at the technical aspects, and focused on crafting a definition that could be used to evaluate systems right now instead of creating a generic definition for all time. 

Legacy systems actually have little to do with an implementation date or when the last update was installed. These were just symptoms. Digging through the obvious similarities between legacy systems, one inescapable parallel is found: They are all fundamentally obsolete. 

Obsolescence can come on several levels. Hardware ages and has its limits. Operating systems and software codes come and die. Software applications cease to be updated and no longer work on newer operating systems. Even changes in business practices make otherwise acceptable systems obsolete by making application elements unnecessary or by demanding new abilities from unchangeable software.  

With this in mind, we crafted the following definition: 

A legacy system is a business-critical system implemented prior to Oct. 25, 2001, and is currently unable to meet user demands.

This date was chosen because on Oct. 25, 2001, Microsoft released Windows XP, a system that dramatically influenced computer use for over a decade and continues to be used today. Anything built before that point would necessitate or imply a system with the following characteristics: 

• Built for an operating system that has now been without support for three generations (Windows Vista support ended April 11, 2017)
• Hardware that is around 20-plus years old
• Maintaining data formats or code that are likely no longer supported. 

In this way, the advent of XP draws a noticeable line where three out of the four means of obsolescence are likely to have been met. However, as the second half of the definition dictates, the system must be unable to adequately deal with user demands. This prevents bias against age, when a system may be old, but processes and demand have not changed sufficiently to make it obsolete. 

If a more extensive definition is used, such as expanding it to any system that needs modernization, problems arise, as systems behind on a replacement cycle are not necessarily obsolete. 

With a good sense of what is legacy, we can face this issue head on and know exactly where we stand. Legacy systems are critical to completing business and deserve the time necessary to determine which are in the worst shape. Does your department track its legacy systems? If so, what definition do you use and why did you choose it? We would love to hear from you. 

*The Center for Digital Government is part of e.Republic, Government Technology's parent company.