How to understand that a system that has been useful for 4–5 years has become legacy? What are the signs that it’s time to regard it as technical debt and look for analogs in the market? What is the scope of work aimed at identifying problem areas? In this article, you will learn the answers to these questions, which will help you conduct a quick legacy system assessment.
How to Understand That Your IT System Has Become Legacy?
First of all, it is worth deciding what legacy software is. This is software that is outdated and needs to be either refactored or replaced
To make legacy system assessment, in particular in the banking sector, it is best to use a checklist developed jointly by the departments of IT development, IT architecture, information security, colleagues from IT support, and other specialists.
Among the criteria for identifying the legacy level of each system:
- The relevance of the technology stack. Here we are talking, firstly, about the version of the frameworks used.
- Implementation of business logic at the level of RDBMS (relational database management system), as well as the possibility of horizontal scaling.
- Information security requirements, at least in the format of the possibility of their implementation in the current system.
- The availability of available personnel on the labor market to work on this technology stack (including Oracle experts, etc.) with a goal for the next two years.
- Readiness of the system for containerization.
In addition, there are a number of prohibitive signs, the presence of which automatically transfers the system to the legacy class. For example, if the system does not have any integration patterns other than the database link, or it does not support the basic three-tier architecture. In other words, if user interfaces interact directly with databases.
Having passed all the current systems through this checklist, it is worth breaking them into three groups:
- Definitely not legacy, or targeted;
- Exactly legacy, or non-target;
- Target modifiable. Part of the criteria hints at the viability of the system but does not outweigh the certainty that it is still legacy. The fate of such systems is considered within the framework of the architectural committee. Based on the results, it is decided whether it is worth starting refactoring of this software or transferring it to the legacy category.
Are There Any Critical Deadlines Allowed For The Life of a Legacy System?
If the target business process linked to the legacy system belongs to the mission-critical category, as a rule, it should be replaced as quickly as possible.
If processes with office productivity priorities remain in the system, they can be operated for a long time without any special risks, until we come to a solution for a comprehensive upgrade. Depending on the criticality of processes, the system will be subject to different requirements for stability and reliability and margin for horizontal scalability.
Much depends on the owners of business services that work with a legacy system. If modernization is not yet part of their plans, then it is worth isolating this system, securing it to the maximum, and breaking integration ties, leaving it to live out its life.
There are systems whose replacement is not economically feasible, provided that they do not bear obvious risks for priority business processes. There are no errors, and they meet the requirements for infrastructure and for updating application software, although not completely, but they comply.
The timing of system decommissioning is determined by the level of complexity of legacy decommissioning projects. So, it will take no more than 2-3 months to leave the old system, which has five or six services left.
Upgrading software that is responsible for a large number of different processes, including quite sensitive ones, such as, for example, the backend for payment cards, will take more time.
But the main question is not how long a legacy system can live. The main thing is that all activities to abandon the legacy should be systematic and continuous.
It is important to consider the following points here:
- If we set a three-year period for decommissioning a legacy system immediately after its identification, this does not mean that after three years it will automatically disappear. In fact, such projects can be postponed, deprioritized, etc. At different stages of work, different injections of resources will be required.
- It is impossible to consider IT systems in isolation from the layer of business processes and the top-level corporate architecture. If we simply change the frameworks on which solutions are written without regularly reviewing business processes, we run the risk of not fixing and eliminating the legacy, but transferring it with all the problems and limitations to a new system, to a conditionally slightly more modern stack.
How Can You Evaluate the Success of a Completed Project to Abandon The Legacy System?
There are projects where the results are obvious. For example, within the framework of the project to abandon the database link, the success of the team and the project as a whole can be measured by the actually disabled database link, focusing on quarterly and annual plans.
If we are not talking about integration components, but about systems that support various business processes, at the preparatory stage of the project it is worth creating a target system for migrating all existing business processes from a legacy system. Next, you should focus on the volume of processes actually transferred from legacy systems.
This is a really important stage in the life of such projects because in the absence of transparent KPIs and goals for decommissioning, they run the risk of becoming a long-term project that turns into a legacy even at the time of abandoning such a system
Final Thoughts
If a legacy system does not meet the requirements for performance and speed, which can affect the efficiency of business processes, then this is one of the good reasons to replace it. We recommend that you contact Modlogix specialists who will help you perform a high-quality legacy system assessment and carry out a replacement.
