Application Modernization: Myths vs Reality

Myth #1: If it ain’t broke, don’t fix it

If you are an ISV (software company) that offers a legacy application, then the following scenario may sound familiar:

• Your legacy application is working well and serves its intended purpose

• Your product is still a money-spinner, generating steady revenue!!

If either or both of the above scenarios are true, then what’s the business case for modernizing your legacy application?

Reality: I have seen many software businesses subscribe to this myth, only to rue their short-sightedness down the road. Even if your application isn’t broken, you must consider modernization for the following reasons:

• Your legacy application could be easily replaced by a nimble competitor with a superior, state-of-the-art application

• Modernization is not just for retrofitting, but it is also to make your applications future-ready

• Legacy applications are not as scalable or flexible as modern applications, and cannot leverage emerging technologies, which is essential for integrating with other applications in a platform landscape

• Modernizing is the only way to safeguard your legacy investments, and unlock the intrinsic value of your product!

Myth # 2: My customers are not complaining

Reality: Customers not complaining doesn’t necessarily mean that they are satisfied and happy!

• Legacy applications might serve the current business needs of your customers, but they are incapable of meeting their future business needs, especially in a fast-changing technology and business landscape

• You may be able to retain current customers with a legacy offering, but will not be able to attract new customers or expand your offering to adjacent markets

• Legacy technologies will become a stumbling block, preventing you from leveraging accumulated, functional and domain expertise

• Your customers might not be aware of the perils of technology/business-model disruption, or the competitive forces at play, and the costs of not modernizing

Myth # 3: My monolith is rock solid

Most legacy applications were developed with monolithic and tightly-coupled architecture using conventional 2/3-tier patterns. These applications are typically designed to serve as either Systems of Record (SoR, to automate core business processes) or Systems of Differentiation (SoD, to provide integration and orchestration capabilities). From that perspective, legacy applications are stable and rock solid. Right?

Reality: Nothing could be farther from the truth. This is at best a self-perpetuating myth and the reality is far more complex:

• In large enterprise-scale applications, an explosion in the number of modules with interdependent business and data logic created spaghetti code with huge complexity

• Legacy applications often have a non-responsive UI, making them incapable of rendering on the new class of devices

• Monolithic architectures and lack of separation of concerns makes it very difficult to scale legacy applications

• Monolithic code bases are difficult to maintain, and it’s a nightmare to make incremental changes and nearly impossible to support frequent deployments.

• Lack of modularity is a great barrier to adopting newer technologies

Myth # 4: Rehosting makes my application modern

Rehosting is a commonly used lift-and-shift strategy, that enables quick redeployment of legacy applications on modern infrastructure. Does rehosting modernize a legacy application?

Reality: Rehosting only achieves partial infrastructure modernization.

• Doesn’t remove any of the underlying constraints of the legacy application in terms of technology obsolescence, architectural limitations, and code complexity

• Without architectural and technology modernization, mere rehosting will not enable the application to leverage full capabilities of modern infrastructure and cloud deployment.

Myth # 5: New UI is the same as application modernization

Tinkering with UI and enabling legacy applications for web or mobile access is a common modernization approach. Is a UI facelift equivalent to application modernization?

Reality: UI modernization could be the first step towards application modernization, and as such is a means, but not an end. A UI facelift is only a quick fix to web-enable a legacy application and/or to make it look modern.

• A truly modern application needs a responsive UI framework, which will work well, only when the underlying technologies and architecture are also modernized.

• A UI facelift doesn’t alter the behavior of the legacy application and does nothing to make it scalable or extensible

• A new UI doesn’t remove code complexities or technology constraints of a legacy application

Myth # 6: Adding a wrapper makes my product open

Using a wrapper to create an interface and expose legacy applications as web services or APIs is another popular approach to modernization. Does this really open up a legacy application?

Reality: It only helps in extending lifecycle of the legacy application, but doesn’t remove the underlying constraints.

• At best, a wrapper exposes only a specific layer and doesn’t capture the holistic functionality of the legacy application

• The basic behavior of a legacy application is neither modified nor modernized

Myth # 7: Automated code migration solves all my legacy problems

Along with rehosting, automated code migration is a popular strategy for application modernization. There are many proprietary tools and service providers which enable migration of legacy code to a more modern programming language. Does this mean that the migrated code is a modern application?

Reality: This strategy will result in only partial modernization of the legacy code, and not the entire application.

• In the absence of architectural modernization, constraints of legacy code will remain

• A monolith will be recreated in a new technology, with all the complexities of the legacy application

• This often works better when migration is from an earlier version to a modern version of the same programming language or within the same technology stack

• Difficult to anticipate how the migrated code will function and will realize only when it fails

Myth # 8: Application modernization is ‘Once and Done’

Reality: Modernization is a continuous process, and is certainly not a once and done thing.

• The emergence of disruptive technology paradigms are difficult to anticipate

• In an inherently disruptive environment, enterprise business needs are rarely static and are continuously evolving

• One can be future-ready, but never future-proof.

Concluding thoughts

Challenges of legacy applications and the technology/business drivers for modernization are well known. Yet, there is no silver bullet for application modernization. It is important to understand the pros and cons of various modernization approaches, distinguish between myths and reality, and to formulate a holistic strategy for creating future-ready applications. Modernization mustn’t be equated blindly with eliminating everything that is legacy, but must be seen as an approach to leverage accumulated business value, domain expertise, and make the application reliable, scalable, and open.