Software businesses that sell/support applications built over the past few decades, often with the same code base and technology stack, actually run mission and business-critical processes with such software. We call that legacy, sometimes a positive connotation, but in reality, the legacy burden is a ticking time bomb.
While many businesses acknowledge that legacy modernization is no longer a choice, but a vital business imperative, they are unsure of the right approach. In this piece, I will present a regenerative approach to overcome the limitations of conventional modernization strategies.
Conventional modernization strategies can be broadly classified into layered modernization, en masse modernization, and infrastructure modernization. Even though the purpose, impact, value, and risk associated with these approaches differ, they all have their own limitations as described below:
Limitations of layered modernization
In layered modernization, each application layer is modernized separately.
UI facelift: A UI facelift typically entails strategies such as web-enablement or HTML emulation. Web-enablement converts green screens into functional web pages, whereas HTML emulation creates a web or mobile interface to work with legacy application. In both cases, only partial UI modernization will be achieved, without altering the behavior of the legacy application or overcoming the constraints of the underlying architecture or technology.
Code migration: This approach is akin to a technology upgrade and relies on using automated tools to either migrate the legacy code to a more recent version within the same stack (ex: from VB to .Net) or migrate to a more modern language (ex: from Forte to Java). While this strategy will result in partially modernizing the code, in the absence of architectural modernization, constraints of the legacy code will still continue, and a monolith will be recreated in a new technology with the same complexities of the legacy application.
Database migration: This approach is used to migrate data from legacy systems such as HDBMS (Hierarchical database management systems) or NDBMS (Network database management systems) to a more modern Relational Database Management Systems (RDBMS). This is typically accomplished using automated tools and data mapping. Database migration only helps in migrating data to a more modern and robust database, but doesn’t alter the underlying UI, architecture, or technology of the legacy application.
Limitations of en masse modernization
In en masse modernization, the entire legacy application with all its constituent layers is modernized at one go.
Rebuild: This approach calls for a complete rewrite of the application from scratch, using modern technologies and newer architectural paradigms. While this strategy will yield a fully-modernized application, the fact remains that rebuilding or rewriting an application is often very expensive, time-consuming, and a high-risk endeavor. This approach doesn’t safeguard legacy investments while calling for significant new investments with uncertain outcomes.
Rip & Replace: This strategy calls for discarding the legacy application, and picking a commercial, ready-to-use modern application that meets the business needs of the enterprise. The reality is that it is very rare to find an off-the-shelf solution that fits the custom needs of a business.
Keeping the lights on with rehosting
Rehosting is an approach that redeploys legacy applications to a modern hardware and software infrastructure with minimal changes. This is a short-term strategy that enables businesses to keep the lights on and reap value from legacy investments, while the bigger modernization initiatives are taking shape.This approach achieves partial infrastructure modernization, but doesn’t remove any of the underlying technology and architecture constraints of the legacy application.
Old is gold
Having spent most of my career in building software products, I understand very well that, notwithstanding technology and architectural constraints, legacy applications still have lots of business value. Very often, the significant functional and domain expertise of the engineers and developers who have built these legacy applications is overlooked. While the existing team may not be skilled or adept at using latest technologies, its collective, accumulated expertise is invaluable, and cannot be replicated or replaced easily.
SecuRef, an approach to regenerate and regrow
After expending significant efforts, we developed SecuRef (coMakeIT’s IP), a unique approach that overcomes the limitations of conventional strategies and achieves legacy modernization with a safety net.
“SecuRef is a modernization strategy that enables extraction of business logic into a separate layer, even from monolithic applications; in other words, transforms a 2/3-tier legacy application into a reactive system”
Some of the key features and advantages of SecuRef are listed below:
SecuRef is an approach that is akin to strangler pattern and achieves modernization by regenerating the existing functionality in a modular manner, with modern technologies and architectural patterns. This strategy enables regrowing the legacy application into a modern reactive system.
Choose the right modernization strategy
I would like to reiterate the same advice that I share with my customers and prospects:
To conclude, I recommend any software business with legacy applications to aim for meaningful modernization with a target to achieve the following: