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.

Designing systems to push or pull data

When to use and not use Event driven design

AssertThrows insted of Expected exception, Grouped assertions, Better paramaterized tests.

What would it take to be able to release your legacy application multiple times/week

Building a simple DB monitoring tool using spring boot

How to optimize the load time in browser in various ways.

How to prepare for a holiday traffic when on a legacy ecommerce platform

The advantanges of API documentation

Are Technical design documents really helpful and how to adapt to minimal documentation approach ?

As Architects and Developers, we have all been in projects writing high-level to low-level design documents. Design documents are a common artifact in software development projects, but their usefulness and effectiveness in an Agile organization have been the subject of debate among IT teams. The main intention of the design documents is to ensure that all stakeholders understand the project goals, technical blueprint, and requirements at a granular level. But, limited audiences are reading this document, and very seldom do these documents get updated. Hence, these documents tend to become cumbersome, time-consuming, and ineffective. 

The Case for writing Technical Design Documents

In a waterfall project software lifecycle moves from one stage to another, and writing design documents made a lot of sense as these were a deliverable and inputs to the next stage. Also, it served as a reference for various teams throughout the project lifecycle without many changes to the document. Additionally, in large projects where the development team expanded rapidly in different stages, design documents became helpful for onboarding new team members. 

However, developers still complained if the document became too long or technical for business stakeholders. Additionally, in a fast-paced project where requirements changed abruptly, design documents quickly became out-of-date or irrelevant as the project progressed, rendering them ineffective as a reference.

The Case for Minimal Documentation

In recent years, with several organizations adopting the Agile work model, there has been a growing trend toward minimal documentation. This approach typically emphasizes lightweight and flexible documentation and more on communication and collaboration among team members. Facilitation happens via regular meetings, syncs, retrospectives, tech guilds, stand-ups, and other forms of communication. Different Agile teams adopt different strategies:-

One of the minimal documentation approaches is to use lightweight documentation tools, such as Wiki or shared Google Docs, to document project goals, requirements, design, Architecture artifacts, decisions, diagrammatic representation of solutions, etc.

Some teams that involve business teams closely follow a BDD/TDD approach and want that as a starting reference for any requirement or even design-specific decision. The development teams also follow a strategic approach towards committing code and documenting every release into production. 

Development teams that hate to write documentation can use code documentation like Doxygen, Javadocs, etc or template-based tools like Markdown, Asciidoc, etc that generate documentation based on source code annotations, structures, or comments using automatic scripts.

Conclusion

Most development teams in today's Agile Organizations hate design documents as they are time-consuming and have maintenance overhead. They can slow down the development process leading to Analysis Paralysis. Also, many tools and techniques are available to automate the creation of diagrammatic representations and technical blueprints in the development process. 

How organizations complicate price information changes

Importance of Logging the right messages in your application

Writing code to get rid of testing teams

How to optimize image display on the website