How to deal with legacy systems?
Strategies for repaying the technological debt
There are three strategies for managing technological debt created by legacy systems: building a new system from scratch, code refactoring and code rewrite. In this article, we will bring each of the approaches closer.
Recently, we have written a lot about legacy systems — what they are, what problems they generate, how they deepen the technological debt in companies. We also explained profoundly why the problem of legacy is mainly a knotty problem of responsibility and sweeping uncomfortable issues under the carpet, and is not a hitch related to a lack of modern technology [LINK TO THE ARTICLE].
This article is dedicated to those of you who have already made the right decision to start managing the legacy systems and are wondering how to bite the bullet.
Strategies for solving the problem of legacy systems
On the whole, there are three basic strategies to reset the technological debt:
- complete replacement of the legacy system with a new one
- its reconstruction/modernization by refactoring the code
- rewriting the system.
When does it pay off to use which one? To tell the truth, the answer is not simple and depends on the state of your current legacy system (how obsolete it is, how many errors it generates, what size it is, etc.). An appropriate tool to determine which of the approaches is more advantageous in a given case is an IT audit. It should be before you start to consider specific technological options.
Strategy #1: Replacing the legacy system with a new one
We build everything from scratch
This strategy is more expensive than code refactoring and in practice, it is used only when “there is really nothing to save” from the old.
If an IT audit reveals that the current system is built upon an archaic code that contains a bunch of errors, the performance and security are totally down, and the current service architecture does not fulfill its functions, then there is no sense to fix the current code piece by piece. Code refactoring or rewriting would take thousands of hours of work, and the final result would still not bring us any closer to the company’s business expectations. When a legacy system is beyond redemption, it is better to build a new one from scratch.
It is worth noting here that such a comprehensive replacement of the entire legacy system is also an (often underestimated) opportunity to improve not only the technical performance. It is also a great chance to thoroughly map all the processes taking place in the company and rearrange them much more efficiently for the future.
For instance: if the current legacy system is a monolithic system in which the entire customer database is shared in the same way by all company departments, and we know that some departments do not use it or only need part of data, it is much better to focus on a microservices architecture that will be created around a legacy system base. As a result, each organizational unit will be able to download data from a specially created API instead of directly from the legacy database. Each department will receive and forward only the data it should have and in the future the company will be able to integrate further data with the system or increase or decrease the given rights. Importantly, each microservice that surrounds the legacy database can be split into smaller microservices at any time.
Here you have a full Case Study of replacing a legacy system with a new system from our Transparent Data portfolio:
Strategy #2: Code refactoring
We improve the quality of the code in small steps, and as a result we finally repair the entire system
Refactoring is the process of changing of the internal structure of the code without interfering with its external behavior. For example, if a code snippet is responsible for making some calculations and we refactor it, some lines of the code will change (they will be better written) but this snippet will still be responsible for making calculations.
This code improvement is done through small but systematic and frequent actions, which, taken individually, are not noticeable. However, when you put them all together, they really make the difference. In this way, a given legacy system can be refactored to a modular monolith or microservices or be prepared for new business functions.
What is most characteristic of refactoring and differentiates it from the standard code rewrite is the fact that it is done it in small fragments by introducing microscopic changes that are easy to control and test. Consequently, they can be integrated very quickly with the old developer code. These freshly written code pieces accumulate over time and gradually replace the archaic code, but as it happens in tiny fragments, the system still works as if nothing has happened. We can compare this strategy to a million operations on a living body that normally functions, goes to work, takes a bath, etc.
In other words, code refactoring gives us a better-quality, clean code whose implementation does not affect the current functioning of the system in any way — it does not require long technical breaks, etc. It is an extremely safe and effective method.
In fact, refactoring can not only be a one-time investment but also a year-round strategy of the company — it can be a continuous, daily process whose goal is, as the Boy Scout Rule says, to leave the code better than you found it.
Strategy #3: Code rewrite
We gradually rewrite the entire system
Rewriting the code for a new technology assumes (in contrast to refactoring) that we do not look into the current code and its operations, but we take some of its snippets and rewrite them again from scratch. We can use for this for example a strangler pattern and rewrite the critical parts of the legacy system in pieces.
Importantly, it makes no sense to throw yourself into the deep end and assume that you will rewrite the entire system right away. On paper it is possible but in practice this never happens and it is just art for art’s sake. Code rewrite takes time and makes sense only if a legacy system is really small. In the case of large monolithic systems there’s no point in revitalizing the whole at once. We can rewrite only some sensitive pieces of it (i.e. fragments that constantly cause bugs or are developed for new business purposes).
Just one more thing worth mentioning…
(applies to all three strategies above)
Any system will eventually grow old and become a legacy system if we don't take care of it. Every system, even one that has just undergone refactoring or a rewrite, must be regularly looked after. To maintain good code quality it is recommended that tools be used for a static code analysis, a write unit, a function, and integration tests. In addition, the company architect or technical leader should take care of the system architecture. If we fail on that, in a few years, we will generate a huge technological debt again and we will be forced to invest in a new product.
Methods of convincing management that investment makes sense
At a time when looking for savings is a global trend, a lot of managers wonder how to convince the management board that a larger investment in rebuilding legacy systems makes sense.
The most common practices used for this purpose are:
- Demonstrating in Excel that the investment will finally (soon) pay off and, in the long run, will lead to the elimination of costs — it is enough to calculate the current costs associated with maintaining the legacy system (working hours devoted to taking care of the system by its own IT department and hours of work of an external company), and add the costs of downtime in the operation of the website (e.g. the warehouse system did not work a total of 70 hours, which led to the loss of X orders with a value of Y; as a result of ERP stagnation, 15,000 customers were serviced whereas normally it would have been 17,000 contracts worth Y etc.). Knowing that a new system will cost XYZ, and its annual maintenance possibly costs CYZ, you can easily compare both variants (the actual costs of the legacy system vs. the investment in a new one) and show after how long of time the new system will pay for itself.
- Presenting arguments and financial simulations showing that the new system will increase the company’s profits — a trouble-free system means: faster customer service and higher satisfaction, increased sales, greater production, faster changes here and now, the ability to quickly respond to competitors, a chance to leave the competition behind. At least some of these business benefits can also be nicely presented in Excel.
- Placing part of the investment in another project —“hide” an expenditure on investing in a legacy system in the ROI of another project. For instance, you can place the investment of a legacy system in the company plans to create a new tool for the sales department whose ROI calculation is X if this tool is somehow connected to it.
In addition, it is also worth establishing that a certain percentage of the project budget will put towards updates, new licenses, and minor refactoring of the code on a regular basis in the future. This so-called write-off for technological debt fluctuates in various companies from 5 to 12% and means that we won’t lead to a situation when in a few years it will be necessary to replace the entire system again.
You might also like:
