Reviving Legacy Systems: Why Expert Advisory is Vital in 2023 as Time Passes On

Have you ever seen a rusty car, device or any other scrap of metal? It’s a completely natural process and nobody denies the fact that sooner or later every metal-based device will succumb to nature’s laws, getting covered by rust. There are ways of preserving the initial state and fighting the rust, but it requires some additional effort, therefore keeping physical things in good shape means taking some extra costs. Interestingly, people do not think that software follows similar rules. Probably it stems from the fact that software itself cannot get literal rust (although computers definitely can!). Nevertheless, old and unkept software might cause many problems, especially if its initial creators are not still present to do their job. To address such issues, legacy system advisory services are typically used.

This issue is becoming increasingly significant as more and more companies buy software that becomes obsolete over time. While programmers in such situations like to rewrite software from scratch – and sometimes this is a wise decision – you do not often have such a luxury, since there is not enough budget or time to implement such a scenario. Either way, the problem of dealing with old software that is nearing the end of its life – or even becomes completely unsupported – usually referred to as “legacy system,” (or “legacy application”) is something that many companies using software for their operations will sooner or later need to deal with.

What is legacy system?

Let’s start from some more precise definitions. There is no single definition of a legacy system, but I’d like to mention three important points:

1. A legacy system is no longer compatible with current standards and requirements, both in terms of code quality, security and compatibility with current versions of dependencies (e.g. operating system, the database server, etc.).
2. Nevertheless, it is software that still (mostly) works.
3. It is software that is still used in the company’s operations.

The important part here is that true legacy system should include all three rules. Obviously, if you consider old software that is not used in the daily life of the company (taking into account only arguments 1 & 2), this does not pose a problem, as well as software that is kept up-to-date and follows all the current standards and obligations (2 & 3). Combination of arguments 1 & 3 seems impossible – how can you use software that doesn’t work? Please remember that even non-working software might have business value, for instance, it might contain important business logic that captures the essence of business processes in the company, so it becomes crucial as a form of documentation.

Off-the-shelf legacy system vs the Software-as-a-Service (SaaS) model

The problem of legacy systems heavily depends on the type of software we are talking about. In terms of off-the-shelf software we need to define whether we are talking about “boxed” software, sold usually as unlimited license to use a particular version of the software (similar to how you bought MS Office or MS Windows in the past), compared to SaaS model that is becoming more and more popular nowadays.

In SaaSes, legacy systems don’t really appear (at least not visibly to the public, for the company developing the product it’s a whole different story), because the service itself is being constantly updated by the provider. It is the provider’s role to include all the security updates as well as updating the whole infrastructure and dependencies of the SaaS software. So, may SaaS users sleep tight and safe? Mostly yes, although they should realize that SaaSes are always susceptible to some form of external hacker attacks, due to the Internet nature of these businesses. On the other hand, there is not really much you can do, other than carrying out a bit of research before you start using such software, and making sure that you choose the right provider.

In case of “boxed” software, or if you install typical SaaS software on your own premises (usually in bigger organizations), the situation becomes much different. It is your responsibility to perform all the updates – obviously, nowadays operating systems do these things mostly automatically, but you still need to supervise the process; sometimes you need to restart the server, for example. Even beyond the regular system updates, you need to take care of other dependencies, such as the database. A great example of this situation is JIRA, a project management tool. You can buy SaaS licenses in the cloud, but you can also buy a license to install software in your own infrastructure. Obviously, when you keep JIRA in your own servers, you have greater control over it – you can have access to the JIRA database and extract some information that you cannot find a good report for! On the other hand, you need to keep all the other software components up-to-date, configure them and react if anything goes wrong in your server. Obviously, this is not the case in the cloud version of JIRA.

You might ask what will happen if you don’t update your software? Aside from not getting any new features – which might not be that problematic – you might encounter some crucial security issues which can be exploited by hackers. It is a known practice that if popular software has a critical vulnerability, hackers try to find instances of the software running on the flawed version on the Internet, and then simply try to exploit the security flaw that has been found. Besides security, an important problem with lack of updates might be, after a few years, the inability to update the whole operating system, as the new OS version might not be compatible with your old, obsolete software. 

To wrap things up, when it comes to maintenance, off-the-shelf software doesn’t leave you with many options, but we still can give you some advice:

• Check your software producer’s website and verify the “end of life” for the software you use, especially in terms of security updates – many companies release security fixes to their customers for a period past the regular updates. When software security fixes are no longer released, the software becomes a high security risk.
• You can take appropriate precautions when you know the end-of-life date. You can buy additional support, a new version of software or you can simply invest in new software, e.g. tailor-made (custom) – you have plenty of options, but you shouldn’t waste your time. If you are not sure what to do, we’ve advised in many similar situations in Makimo, so we can help you decide whether to invest in existing software (it often makes sense!) or to switch to some other software, either off-the-shelf or custom.

Benefits of legacy system advisory

Maintenance of your legacy system becomes much more important if you have a custom, tailor-made software created by an external company or an internal team, sometimes even one employee who used to work in your company for years, but now they have resigned so you cannot ask them for help, yet their influence on your company is still vast! In the custom software world, there is no single scenario because a lot depends on:

• the particular software development technology,
• the infrastructure that was used to create the application,
• the time when the application was created,
• the integrations that were applied in the project.

Therefore, as a rule, it is a good idea to first perform a technical due diligence, which is a form of a digital audit procedure, focused heavily on the different aspects of the IT infrastructure – in this case, it focuses mostly on the bespoke software, of course. TDD includes some of the tasks I described before – e.g. analysis of end-of-life dates for all dependent technology – but in the context of custom software. It is extremely important to verify the building blocks of custom software, such as libraries, frameworks, programming languages and other external components.

Such an analysis is not enough, though. Another crucial aspect of legacy system advisory is the code quality and its extensibility, i.e. how easy it would be for a new team to work further with the existing project. I have done such an analysis many times and very often experienced a huge mess under a beautiful and well-working application – code with quality so low that no developer would like to work with it. What can you do in such a situation?

In extreme cases, performing a rewrite – writing the application from scratch, while applying all the new security, performance and scalability standards – is a good approach. It is not as bad as it sounds since when you perform a rewrite, you know exactly what you want to achieve, because you have access to existing software. Therefore, there is much less risk than in the case of writing software truly from scratch, often without having a very precise idea of what should be done.

Most of the time, writing a completely new version of software is not required. What you can do is to perform a process of code refactoring. Code refactoring means improving the quality of the code without changing the features/functional aspects of the software. It is not necessarily something that clients like – they’d rather pay for new features and enhancements than just keep things in good shape. The good approach here is to treat it like an operating cost. Just like you need to periodically change oil in your car (as well as oil filter or brake pads) and it does not give you any new possibilities – it keeps your car in good condition, though. Refactored code can be later updated to new versions of frameworks and libraries, because it is in good shape and can be worked on without big risk.

After performing code refactoring and software updates, it should be much easier and more secure to develop further features and utilize the software; therefore, you might get a good return on such an investment.