If you have spent any time in the software industry, you would have heard of the term ‘legacy system’. All software systems become legacy systems at some point. In this article, we will discuss why this happens but first, we need to define what exactly a legacy system is.
What is a legacy system?
Depending on who you ask, you may get different answers to this question. However, a popular definition of a ‘legacy system’ is a software application that has become obsolete and is hard to update or maintain. The legacy application could still be working fine or is maybe just a little slow, while still performing its basic purpose.
We have a different opinion. Imagine you buy a swanky new car from the showroom. The moment it’s out on the road it starts to become ‘used’ or ‘old’ and starts losing value. We believe software systems are the same. As soon as they are deployed, legacy starts to set in. This is applicable to any off-the-shelf (OTS) software, custom-built software, or any combination of the two.
But why does this happen?
Well, as mentioned above, there are many scenarios in which systems become legacy. Here are some examples:
The development team who built the system are no longer with the company and there is a lack of proper documentation. This leads to a lack of knowledge, which in turn can cause issues with maintaining or upgrading the system.
End of life software/frameworks were used and are no longer supported. A simple example of this is Windows XP or Angular JS 1. Now, if your software system was designed for an older version of Windows operating system (OS) and Microsoft has stopped supporting that OS, you would need to upgrade your software system as well for it to continue to run.
Off-the-Shelf (OTS) enterprise software that you were using is not supported because the company was acquired or has been shut down. Imagine a small Customer Relationship Management system that is acquired by a giant company that decides to slowly close a part of their business down and tells you to migrate to their platform.
Aging technology with obsolete architecture, such as on-premises database servers, might no longer be developed or maintained by the vendor. Financial institutions are a fantastic example of this scenario. A bank using an old banking application based on a local database would need to move to a cloud-based architecture in order to modernise its operations and customer experience.
Similarly, there could be other reasons for a system becoming legacy, such as resistance to maintaining and updating the software. A functionally resilient system might still be working fine but may not be able to deliver the performance or experience for modern customers and users. Think of how frequently your business changes. To prevent your software from becoming legacy, it needs to change with your business. The old mindset of “If it ain’t broke, don’t fix it” is not helpful in the long run.
How do you deal with legacy systems?
Beyond turning a blind eye to the problem, there are multiple ways in which you can migrate to a modern system once you recognize that your software system needs an upgrade. Here are some do’s and don’t’s for your legacy migration. There are typically two options for migration:
The first option is you replacing the legacy system with an OTS solution already available in the market. It could be buying a new hotel booking system, POS software or a modern inventory management system. There are risks with this approach. While the initial cost of these systems might be lower in the case of a SaaS product, the cost to customize it could be high, or alternatively, the customisation might be impossible. The queue to fix bugs could be very long due to the large backlog for these systems and you could become vendor locked.
Another option is to have a custom software solution developed for your specific needs. If you need something specific to your business process which is not available with an OTS product, or is a niche requirement to your business, you can have the system custom developed for you. Based on the complexity and the number of features you need, the initial cost could be higher than an OTS product but you would also have a higher level of customisation and you would own your IP.
But here comes the conundrum, the new system would be a legacy system soon enough as well. Even if you have used the latest and the greatest technology or methods to build the new system, they will need to be upgraded in future. So how do we break this cycle of legacy systems? The short answer is taking the approach of continuous modernisation.
Here at WorkingMouse continuous modernisation is our bread and butter. So, if it sounds like modernising your legacy system is the right fit for your business, be sure to schedule a free product strategy session with us today.
