Legacy software series — Part 3 — Modernizing legacy software
In this article I’m discussing the risks of modernizing a legacy system and the risks of not modernizing. Furthermore, I write about the approaches that are often applied when modernizing a legacy system.
Risks of modernizing legacy system
Legacy systems seldom have a complete documentation specifying the whole system with all its functions and use cases. In most cases, the documentation is badly out of date or missing completely. Many years of maintenance under different developers and managers can cause the documentation to degrade. Without up-to-date documentation specifying the legacy system, it is hard to create a new system that would function identically to the previous one. Companies have often coupled their legacy software with their business processes. Changing legacy software can cause unpredictable consequences to the business process that relies on it, which in term can cost a lot of money to the company. Replacing legacy system with new one is risky, since the new system can be more expensive than expected and there can be problems with delivering it on time (Sommerville, 2016).
Risk of staying with legacy system
Sometimes legacy system is not compatible with new software, and it cannot interface with internet or any other modern data transfer protocol. There are can also be too few developers that know old languages or none. Therefore, maintenance needs to be bought from specialized companies, which is expensive (Dogru, et al., 2011).
In some cases, documentation is out of date or completely missing. It might even be that there is no source code. In this case developers need to map out the functionalities of the software and try to create a new system with similar capabilities (Dogru, et al., 2011).
Sometimes the source code of the legacy system may have degraded over the years. It might be collection of programs from different time working together with questionable logic. Furthermore, the code could have been written in a more optimized manner, that new developers do not understand. This is true for the older low level programming languages (Dogru, et al., 2011).
Legacy systems may also have many different data files from different time periods with duplicate data that can be out of date or corrupted. At worst, the databases might not even be compatible with each other. At some point, the cost of maintaining legacy systems will exceed the cost of replacing them with a new system (Dogru, et al., 2011).
Strategies for updating legacy system
There are three popular strategies for dealing with legacy systems: scrap the legacy system, keep maintaining the system or replace the whole system (Malinova, 2010). Because companies have limited amount of money to spend on their legacy systems, they need to be careful when choosing what to do.
Scrapping the system can be an option when the company has found out that the legacy system no longer creates any value and is not critical part of any business process. In this case, the best solution is simply getting rid of the legacy system.
Continuing to maintain the legacy system can be done when the system is still stable, and maintenance is cost effective. Improving the legacy system is possible when the system has degraded a bit, but it can still be maintained. Possibly through adding new interfaces to make the system easier to maintain.
Lastly, replacing the legacy system all together should be attempted when there is no longer hardware to support for the system, maintenance is too expensive, and the cost of a new system is not too high (Seacord, et al., 2003).
When company is assessing the state of their legacy system to determine what to do with it, it is important to evaluate the legacy system from a technical perspective and from business perspective (Warren, 1998). The technical perspective means that the quality of the legacy system is evaluated. The business perspective is used to determine if the business needs of the company require a new software to perform optimally. By combining these two perspectives, a company can decide on whether they should invest into the legacy system.
If a legacy system has low quality and low business value, the system should be removed. Legacy system with low quality but high business value should not be removed, but because of the low quality, its maintenance is expensive, so it should be replaced with a modern system. Systems with high quality and low business value do not create much value, but they do not cost much to maintain. Thus, these systems can be left running. Legacy systems with high quality and high business value are the best possible option. They do not cost much to maintain, and they are creating value to the company. These systems should be left running with normal maintenance (Sommerville, 2016).
System modernization is a similar act of transforming software as maintenance is. However, modernization differs in the sense that it is much more extensive process than maintenance because modernizations often incorporate restructuring, functional changes, and new software attributes. A legacy system can be modernized to lower its maintenance costs if it still has business value.
There are two types of modernization strategies that can be used: white-box modernization and black-box modernization. The key difference between them is the amount of knowledge of the legacy systems needed to complete the modernization process. White-box modernization requires a lot of technical information about the internals of the legacy system. Contrary to that, black-box modernization only requires information about the external interfaces of the legacy system. Sometimes these methods are not enough, and a legacy system is so outdated that it is not cost effective to modernize it. Thus, it should be replaced (Comella-Dorda, et al., 2000).
In order to do white-box modernization, it is necessary to reverse engineer the legacy system in order to build up a higher level representation of the system, its relationships and components (Chikofsky, et al., 1990). Program understanding is often used to reverse engineer legacy systems in white-box modernization. In essence, program understanding is the act of examining and studying the legacy system, modeling the system domain, using reverse engineering tools to study the code base, and developing abstract models that help to understand the system (Comella-Dorda, et al., 2000). The task of reverse engineering a system is a time consuming and expensive operation. It is even more difficult if the system is large and complex, and the documentation is outdated.
Once there is a sufficient understanding of the legacy system, the restructuring of the code and the system will commence. Restructuring is transforming the code to increase performance, maintainability and other quality attributes, while maintaining the functionality (Chikofsky, et al., 1990).
Black-box modernization does not attempt to uncover the inner workings of the legacy system. Because, only the inputs and outputs of the system must be examined. This makes the modernization process easier compared to white-box modernization (Comella-Dorda, et al., 2000). Black-box modernization builds new interfaces around the legacy system rather than trying to restructure it.
Replacement of a legacy system is the best course of action when a system is so badly outdated, that it is not cost-effective to modernize it. When replacing legacy system, a new system needs to be built from the ground up to take its place. Building a new system requires a lot of resources and knowledge. Since most developers work on maintenance, they may not know how to design new systems. Another risk is, that some of the business knowledge, that is embedded in the legacy system, is lost. Furthermore, the new system might not work as well as the old one (Comella-Dorda, et al., 2000).
Chikofsky, E., & Cross ll, J. (1990). Reverse Engineer and Design Recovery: A Taxonomy. IEEE Software. Retrieved from https://ieeexplore-ieee-org.ezproxy.cc.lut.fi/stamp/stamp.jsp?tp=&arnumber=43044
Comella-Dorda, S., Wallnau, K., Seacord, R., & Robert, J. (2000). A Survey of Legacy System Modernization Approaches. Carnegie Mellon University. Retrieved from https://www.researchgate.net/publication/235126722_A_Survey_of_Legacy_System_Modernization_Approaches
Dogru, A., & Bicer, V. (2011). Modern Software Engineering Concepts and Practices: Advanced Approaches. Retrieved from https://books.google.fi/books?id=mor9t6v-AAYC&pg=PA98&dq=software+modernization&hl=en&sa=X&ved=2ahUKEwjHlM6oibrtAhWNAxAIHQmUDhUQ6AEwAXoECAIQAg#v=snippet&q=legacy&f=false
Malinova, A. (2010). Approaches and techniques for legacy software modernization. Retrieved from https://www.researchgate.net/profile/Anna_Malinova/publication/267181092_Approaches_and_techniques_for_legacy_software_modernization/links/5739e7c508ae298602e36682.pdf
Seacord, R., Plakosh, D., & Lewis, G. (2003). Modernizing Legacy Systems: Software Technologies, Engineering Process and Business Practices. Addison-Wesley Professional. Retrieved from https://www.researchgate.net/publication/234822137_Modernizing_Legacy_Systems_Software_Technologies_Engineering_Process_and_Business_Practices
Sommerville, I. (2016). Software Engineering Tenth Edition. Pearson Education.
Warren, I. (1998). The renaissance of legacy systems. London, Britain: Springer. Retrieved from https://www.researchgate.net/publication/265287408_The_Renaissance_of_Legacy_Systems