Choosing the right modernization strategy

There are many quick fixes that are touted as genuine modernization strategies. Most often, these are nothing more than ad hoc measures that might yield low-hanging fruit, such as:

• rehosting that will result in partial infrastructure modernization
• UI facelift, that could quickly web-enable a legacy application
• adding a wrapper, that could expose partial functionality as a web service or API
• automated migration to migrate legacy code into a modern version/ language

You must resist the temptation to buy into these quick-fix strategies. It is a myth to believe that any of these approaches will lead to genuine modernization. At best, they will only result in partial modernization, and would neither remove legacy constraints, nor alter the application behavior in any meaningful manner.

It is also vital to understand the limitations of conventional approaches to modernization, before choosing the right strategy:

Layered modernization: Using this approach, each layer of the legacy application i.e. UI, database, and code are modernized separately. While this approach might lower the operational risks, it will only result in partial modernization. Most of the architectural and technology constraints will remain the same, and wouldn’t yield a truly modern, flexible and responsive application.

en masse modernization: Strategies such as Rehost, Rebuild, and Rip & Replace call for en masse modernization of the legacy application. These conventional strategies are often expensive, time-consuming, and high-risk endeavors, and each strategy has its own limitations. Rehost will only result in partial infrastructure modernization; Rebuild calls for a complete rewrite, doesn’t leverage legacy investments or accumulated domain expertise, and demands significant investment with uncertain outcomes; Rip & Replace involves discarding the legacy software, and picking a COTS, which rarely meets the business needs and often demands significant customization.

There will always be competing pulls and multiple factors that influence the choice of modernization strategy, and one must be aware of the limitations of conventional approaches. A short-sighted modernization strategy may help you deal with a few pressing challenges, and yield short-term results, but will not result in any meaningful modernization. Irrespective of the choice of modernization strategy, you must aim to achieve the following:

• A reactive system that is flexible, loosely coupled, scalable, resilient, and responsive.
• A future-ready application built with modern programming languages, using flexible and modular architecture, and capable of delivering consumer grade experience – at scale, usability and intelligence
• Process and Deployment modernization to support rapid development, continuous delivery and deployment
• A modern, reactive and open application that is easy to integrate and which can support multiple business models as part of different platforms

I recommend you to read the latest white paper on application modernization, that details our insights and point of view:

Layered modernization:

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, without 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. A major limitation of code migration is also the fact that product developers will not understand the new technology, and product owners will not know until the migrated code fails.

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 RDBMS (Relational Database Management Systems). 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.

en masse modernization:

Rehost (lift-and-shift): This strategy is based on redeploying legacy applications to a modern hardware and software infrastructure with minimal changes. This approach only achieves partial infrastructure modernization, and doesn’t remove any of the underlying constraints of the legacy application in terms of technology and architecture. This is a myopic solution that only relieves the burden of maintaining the underlying infrastructure, but can never make the application truly SaaS and cloud-native.

Rebuild: This approach aims to modernize all tiers of the application along with deployment modernization, and 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 from scratch is often very expensive, time consuming, and a high-risk endeavor. Success of this approach will be dependent on the availability of people with skills in modern technologies and architectures, and ability to leverage domain or functional expertise of the existing team. This approach also 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, and another major disadvantage of this approach is the fact that significant legacy investments will have to be written off.