Estonian companies are aware of the threats posed by outdated software, but they are still using it, writes Raimo Seero, CTO of Uptime.
Legacy software is a system or platform that is used in a company’s day-to-day operations but is technologically outdated and no longer meets modern requirements. This may be software for which vendor support has expired or has simply not been updated for a long time.
Not updating the platforms, in turn, increases the risk of security vulnerabilities that can be exploited in cyber-attacks or that an IT asset stops working altogether. This is what is known as a technical risk for legacy systems. Business risks are much less talked about.
Imagine, for example, a situation where no one has changed or added new features to a company’s software for a long time. Years go by, developers have changed jobs and the necessary documentation is not produced. Then, when the need suddenly arises to change the business logic in the system, for example, to introduce tax changes, there may be no one left to implement this on the business software platform. The scenario of having to develop new software from scratch is also a genuine possibility.
When money isn’t used wisely
In reality, IT departments in Estonian companies are aware of the risks associated with legacy systems. The problem often arises in communication or prioritisation.
In practice, in large companies in particular, we see that the IT department is constantly sounding the alarm about legacy, but the management is failing to recognise the risks or is only focusing on adding new functions, i.e., mitigating the business risk. This can lead to a situation where the software meets the company’s business objectives but is technically outdated and fragile in terms of security.
The problem can also be reversed: in the absence of direction from management, the IT department will usually tend toget into the habit of managing technical risk, while the business perspective and maintaining the necessary development expertise will take a back seat. The result is a well-managed platform on which a lot of money has been spent, but which is commercially dead or dying because soon no one will know how to develop it further.
In time, the debts associated with both technology and business risks will grow exponentially. It’s like a car – if you skip one service, you can still save it, but a vehicle that hasn’t been serviced for five years is likely to need an overhaul.
Map out and communicate
The management has to decide how to deal with legacy software because they set the priorities and allocate the money to implement them. It’s a good start when it can be made clear and put on paper that the IT budget is not one line but two – the money going towards managing the existing platform and implementing changes.
Setting goals and communicating them will help IT people make decisions about how they spend their working hours.
There are also in-house procedures to map legacy risks. A good place to start is with a business resilience audit, which identifies the IT systems that are critical to the business. Then, going into more detail, it is necessary to spell out what the realisation of a particular risk means for the company, whose responsibility it is, and how it will be addressed.
During the audit and risk mapping process, it may turn out that an old system, previously considered as a high risk, does not need to be scrapped entirely and, after a minor upgrade, can be used for the next 5-10 years. But before that, getting under the bonnet with the IT department or an external partner and checking the engine is essential because if it turns out that software that is considered to be reliable needs to be replaced in the next few years, then it needs to be addressed.