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:
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:
Myth # 2: My customers are not complaining
Reality: Customers not complaining doesn’t necessarily mean that they are satisfied and happy!
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:
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.
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.
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.
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.
Myth # 8: Application modernization is ‘Once and Done’
Reality: Modernization is a continuous process, and is certainly not a once and done thing.
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.