Legacy Systems

A legacy system, in the context of computing, refers to outdated computer systems, programming languages, or application software that are used instead of available upgraded versions. Legacy systems also may be associated with terminology or processes that are no longer applicable to current contexts or content, thus creating confusion. In theory, it would be great to be able to have immediate access to use the most advanced technology. But in reality, most organizations have legacy systems - to some extent. A legacy system may be problematic, due to compatibility issues, obsoletion, or lack of security support. A legacy system is also known as a legacy platform.

Gartner defines a legacy system as, "An information system that may be based on outdated technologies, but is critical to day-to-day operations. Replacing legacy applications and systems with systems based on new and different technologies is one of the information systems (IS) professional’s most significant challenges. As enterprises upgrade or change their technologies, they must ensure compatibility with old systems and data formats that are still in use."

Legacy System Structures

Legacy systems are not simply old software systems although the software components of these systems are the main focus of this section. Legacy systems are socio-technical computer-based systems (so they include software, hardware, data, and business processes). Changes to one part of the system inevitably involve further changes to other components. Decisions about these systems are not always governed by objective engineering criteria but are affected by broader organizational strategies and politics.

Figure 1. illustrates the different logical parts of a legacy system and their relationships:

1. System hardware: In many cases, legacy systems have been written for mainframe hardware that is no longer available, which is expensive to maintain, and which may not be compatible with current organizational IT purchasing policies.
2. Support software The legacy system may rely on a range of different support software from the operating system and utilities provided by the hardware manufacturer through to the compilers used for system development. Again, these may be obsolete and no longer supported by their original providers.
3. Application software: The application system which provides the business services is usually composed of a number of separate programs which have been developed at different times. Sometimes the term legacy system means this application software system rather than the entire system.
4. Application data: These are the data that are processed by the application system. In many legacy systems, an immense volume of data has accumulated over the lifetime of the system. This data may be inconsistent and may be duplicated in different files.
5. Business processes: These are processes that are used in the business to achieve some business objective. An example of a business process in an insurance company would be issuing an insurance policy; in a manufacturing company, a business process would be accepting an order for products and setting up the associated manufacturing process.
6. Business policies: and rules These are definitions of how the business should be carried out and constraints on the business. The use of the legacy application system may be embedded in these policies and rules.

An alternative way of looking at these different components of a legacy system is a series of layers as shown in Figure 2. Each layer depends on the layer immediately below it and interfaces with that layer. If interfaces are maintained, then it should be possible to make changes within a layer without affecting either of the adjacent layers.

Identifying Legacy Systems

• The year of creation or implementation, as most legacy systems are outdated and advanced in age.
• Current performance - legacy systems are often associated with poor efficiency and lower productivity.
• The availability of software updates and vendor support (or lack thereof, to be precise).
• Compatibility with new systems and the possibility of adding more functions - since legacy systems are limited in their functionality and can’t be developed further.

Once you identify a legacy system, it’s time to decide whether it’s worth replacing it. The process will certainly be time-consuming, but keep in mind that legacy software should be replaced at some point. Especially if it doesn’t meet your needs and is not secure anymore, as it may be using old security protocols and standards. Still, one of the most important factors will most likely be the cost of upgrading the outdated technology, as well as the time required for the whole process. Evaluate both of them carefully, and trust a specialist to carry out a proper analysis for your organization. Only then you can make an informed choice about the future of a legacy system.

Legacy System Types

When considering legacy systems, there are five different types of issues or problems that companies can encounter.

• End of Life: Perhaps the most common legacy system type, end-of-life (EOL) legacy systems are everywhere. The reason for EOL systems is actually fairly simple. Vendors and Developers are businesses too. They also need to stay current with the latest technology. This often means that systems designed with older legacy software fall out of support as the resources and knowledge are either lost or become too expensive to maintain. With EOL legacy systems, vendors stop offering updates and discontinue selling the product.
• No Updates: With an EOL legacy system, the vendor might offer to upgrade you to a new solution that offers similar functionality. If this option is not available, however, businesses are stuck. In the case where no updates are available, businesses need to consider alternatives whether that is a new software solution or a new provider, or both.
• Scalability: Legacy systems and legacy software were designed at a time when specific infrastructure was available. As such newer technologies – for example, AI, the cloud, and big data – are things they are unable to support. In this case, the legacy solution will not be able to grow with the business and a new alternative will need to be explored.
• Patches: Security patches are critical for many systems, however as time progresses, older legacy systems become more and more vulnerable. If the original developer has stopped supporting the product (EOL) then the risk can become critical.
• Knowledge and Training: As technologies change, new resources hired often lack knowledge of how legacy software solutions work. While some training can be provided, the impact can become quite severe as time progresses.

Why Businesses Continue to Use Legacy Systems

Despite their inefficiency and high costs of maintenance, many corporations and governmental systems around the world still use outdated software. In fact, countries that use these systems admit that the software has even exceeded its end-of-life date. Recently, the inability of state unemployment servers to keep up with application demands highlighted the difficulties of maintaining legacy platforms. Compounding the problem was the lack of COBOL programmers to maintain the legacy on-premise infrastructure. In addition, a June 2019 report by the U.S. General Accountability Office revealed ten critical legacy systems in need of modernization. Meanwhile, many retail, e-commerce, and manufacturing companies still rely on legacy systems. Common reasons for not modernizing include:

• The lack of financial resources to support the transition
• The fear of major disruption to the business during the modernization
• A lack of ability to retrain staff and prevent service delays
• The overwhelming prospect of upgrading an unwieldy system

Updating Legacy Systems

The most important thing about updating a legacy system is to protect the data that already exists. This can only be done through successful data migration. Imagine a hospital that has tens of thousands of historical patient records in a legacy system. It would be devastating to lose that information because of an insecure legacy system. It would be equally as devastating to lose that information due to poor data migration. Successful data migration includes:

• Extracting the existing data. Data in existing legacy systems might be siloed, splintered, duplicated, or incomplete. It may exist in a variety of data stores and in a variety of formats. Migrating data out of a legacy system starts with making sure it can all be extracted safely.
• Transforming data so it matches the new formats. The data is transformed to the new system’s requirements through data mapping. Rarely does data from legacy systems do an exact mapping to the new system. This step is vital to ensure that the new system understands the data from the legacy system.
• Cleansing the data to address any quality issues. The migration process is a good time to clean data by getting rid of duplications, incomplete data, and data that is not properly formatted. A legacy system with phone numbers that contain dashes won’t work with a new system that doesn’t allow for them.
• Validating the data to make sure the move goes as planned. Once data is extracted, transformed, and cleaned, a sample set of data is imported to test for problems and errors. This weeds out potential issues before the new system goes live.
• Loading the data into the new system. The final step to successful data migration is loading all the data into the new system so it is ready for use.

Migrating From Legacy Systems

System migration can be a complex challenge, especially if the legacy system is in everyday use. As with most change projects, it's typically a matter of good planning. The migration process usually goes like this:

1. Establish the new system. The organization will set up the new system so that it's ready to use. The data manager may run a small pilot scheme to confirm that the new system works and offers the same functionality as the old system.
2. Extract the existing data. The migration team will do this using the legacy system's export tools. This will create a file of raw data that's not yet compatible with the new system.
3. Apply data transformations. The team will then perform a sequence of data transformations. This may include:
   • Data cleansing to remove any corrupt or duplicate values.
   • Data validation to ensure that all values are logically consistent, like checking that all phone numbers contain ten digits.
   • Data mapping transpose the data from the old schema to a new schema that's compatible with the more modern system.
   • Data enrichment to merge the raw data with other relevant data, which helps to create more detailed records.
4. Load data into the new system. The team will then perform a data import to bring all the legacy data into the new system. Systems users will still have access to the records that previously lived on the legacy system.
5. Switch off and roll out. Finally, the team will take the legacy system offline. Users will move fully to the new system. This helps to avoid a situation in which some users are still creating fresh data on the legacy system, which may lead to inconsistency and redundancy.

This kind of migration is easier when there's a reliable data transfer platform between the two systems, such as an Extract Transform Load (ETL).

Challenges of Legacy Systems

Legacy systems are considered to be potentially problematic by some software engineers for several reasons.

• If legacy software runs on only antiquated hardware, the cost of maintaining the system may eventually outweigh the cost of replacing both the software and hardware unless some form of emulation or backward compatibility allows the software to run on new hardware.
• These systems can be hard to maintain, improve, and expand because there is a general lack of understanding of the system; the staff who were experts on it have retired or forgotten what they knew about it, and staff who entered the field after it became "legacy" never learned about it in the first place. This can be worsened by a lack or loss of documentation. Comair airline company fired its CEO in 2004 due to the failure of an antiquated legacy crew scheduling system that ran into a limitation not known to anyone in the company.
• Legacy systems may have vulnerabilities in older operating systems or applications due to a lack of security patches being available or applied. There can also be production configurations that cause security problems. These issues can put the legacy system at risk of being compromised by attackers or knowledgeable insiders.
• Integration with newer systems may also be difficult because new software may use completely different technologies. Integration across technology is quite common in computing, but integration between newer technologies and substantially older ones is not common. There may simply not be sufficient demand for integration technology to be developed. Some of this "glue" code is occasionally developed by vendors and enthusiasts of particular legacy technologies.
• Budgetary constraints often lead corporations to not address the need for replacement or migration of a legacy system. However, companies often don't consider the increasing supportability costs (people, software, and hardware, all mentioned above) and do not take into consideration the enormous loss of capability or business continuity if the legacy system were to fail. Once these considerations are well understood, then based on the proven ROI of a new, more secure, updated technology stack platform is not as costly as the alternative—and the budget is found.
• Due to the fact that most legacy programmers are entering retirement age and the number of young engineers replacing them is very small, there is an alarming shortage of available workforce. This in turn results in difficulty in maintaining legacy systems, as well as an increase in the costs of procuring experienced programmers.

Risks and Issues with Keeping Legal Systems

If legacy systems are critical for an organization, it is important to conduct security and performance audits once in a while. Because despite the numerous reasons to maintain a legacy system, there are also diverse potential risks and issues to consider.

• Compatibility. As it uses outdated technologies, the legacy system can become incompatible with new systems or technologies that are also essential to the business. As a result, departments using legacy systems may not benefit from all the features offered by new systems.
• Support. If the vendor is no longer selling the system or software your company is using, nor offering support for it, it is not likely that he will be able to help when a problem arises.
• Data silos. Legacy systems are not usually built to be integrated with newer systems; isolating data from other systems.
• Security. The lack of support, updates, or maintenance, as well as the fact of using old security protocols and standards, leads to creating patches that can end up causing security breaches. This can also make meeting regulatory compliance more difficult.
• Performance and productivity. Legacy systems become slower and slower over time, which means performance, efficiency, and productivity can also decrease.
• Maintenance costs and competitiveness. Maintaining a legacy system means investing money in an IT resource that will need to be replaced sooner or later.

See Also

• Application Modernization
• Application Modernization Services
• Mainframe
• Maintenance Repair and Operations (MRO)
• Data Migration