Friday, February 22, 2019

How to decide to when to move out code from the legacy application

Several times as an Architect, one of the most challenging aspects of decision-making is when to start disintegrating a legacy platform. Working on a Legacy E-commerce platform, I have had my share of struggles with the business trying to understand the long terms goals of a system and to decide how to build around a legacy platform. For years the business teams have been relying on legacy systems to run all critical business processes and operations. They are least bothered about the development and operational struggles, as their focus has been on getting features implemented.  


Also, as the system has been aging, it has been increasingly difficult to maintain and update it as the applications have outdated technology stacks, no documentation, and has grown unwieldy over time. In this article, I have tried to put in some of the key points that we as Architects need to convince the business in order to make them realize various thresholds of when a platform has to change. 


Business Value

One of the primary factors to consider when deciding whether to move out code from a legacy application is the business value that the code provides. It's very important to question and understand the business values in terms of numbers. If the code is critical to the organization's operations and generates significant revenue, it may be worth investing in modernizing the codebase to ensure its long-term viability. On the other hand, if the code is not generating significant business value and can be easily replaced by a newer solution, it may make sense to retire the legacy application and move on.


Scalability

Legacy applications may not be designed to handle the scale of modern business operations. In our case, the licensing model with the infrastructure made it even more difficult. If the application is struggling to keep up with growing demand or is frequently experiencing downtime, this is the time to get businesses' attention. It may be time to move the code out of the legacy application and into a more scalable, modern environment.


Technical Debt

Technical debt has become my go-to word in every meeting. It refers to the cost of maintaining and updating software that has not been built to current best practices or standards. Legacy applications are often associated with significant technical debt, as they may be built with outdated technology stacks and with years of patching over time without proper documentation or testing. If the technical debt associated with the legacy application is making it difficult to maintain and update. Just create a holistic list as it may be time to move out the code to a modern platform. 


Skillset

Legacy applications may rely on outdated technologies and programming languages. This has been one of the main reasons why it has been hard to find developers with the necessary skill set to maintain and update the codebase. This is a clear indication when an organization is struggling to find developers with the necessary expertise, it may be time to move the code out of the legacy application and onto a modern platform that is more widely supported.


Security

Very few business teams pay attention to the Security aspects of a platform. It is very often the ITs problem, and Legacy applications are bound to have security vulnerabilities that make them more susceptible to cyber-attacks. If the legacy application is not being properly maintained and updated, it is putting the organization's data and operations at risk. It's very important for us Architects to explain and educate the stakeholders about these security vulnerabilities and risks.


In conclusion, deciding when to move out code from a legacy application can be a complex decision that requires careful consideration of multiple factors. By assessing some of the above critical points, businesses can make informed decisions about when to modernize their codebase and move to a more sustainable platform. Ultimately, this decision has to tie in with the organization's technology infrastructure to support its current and future business needs.

No comments:

Post a Comment

Building Microservices by decreasing Entropy and increasing Negentropy - Series Part 5

Microservice’s journey is all about gradually overhaul, every time you make a change you need to keep the system in a better state or the ...