Over time, Legacy applications in enterprises become hard to update, tune, and maintain. However, replacing these applications with newer ones is also complex and expensive in the early stages. It requires a solid mindset and a visible business benefit to make the decision. This paper introduces a simple 3S (signs, strategies, and solutions) paradigm to ease decision making. Wearing a design thinking hat, it is known that after a certain amount of time, an application, platform, or product needs a jump to the new S curve – to innovate new things and get the next opportunity for growth. The 3S paradigm can be applied in every innovation window cycle – whenever a jump is needed from one S curve to another throughout the lifecycle of an organization.
Understand the Signs:
The maturity point of any product, application, or platform is the first paradigm of the discussed 3S approach. Any jump to the new S curve demands CapEx (Capital Expenditure) investment. So, the right level of understanding the symptoms of the modernization requirement is quite vital. The existing product/platform should continue to operate until it is under growth and within the OpEx (Operational expense) budget. When saturation happens, in growth over time, – is high time to make a jump to innovate and be competitive in business. Below are the various important signs of saturation point –
- Higher operational costs: According to The Government Accountability Office, around ten of the federal government’s legacy systems cost around $337 million annually.
- Incompatible in integration with modern systems: It is important that software, regardless of its age, integrates well with the other apps needed to operate the end-to-end business effectively. Organizations cannot afford to ignore compatibility problems in the overall transformation journey.
- Weak Security: The older the software gets, the more vulnerable it becomes because attackers have had enough time to uncover the vulnerabilities.
- No more performance tuning is feasible: When product or platform reaches maturity, no process improvement or service improvement helps anymore to reduce latency. System reaches saturation – thus stagnating growth in business.
- High Time to Market: Legacy platforms prevent a company from competing effectively against those with modern systems that provide sufficient agility and flexibility. Therefore, its use can seriously impact the Time to Market of a company. When it is found that building any new feature in a legacy application takes more time than even doing transformation – it is another sign of making the decision to do transformation. On a lighter note, a famous Dilbert cartoon depicts the situation of intention.
Shrinkingthef experts: The lack of community support for obsolete technologies discourages IT staff from continuing to work in the legacy world.
Brainstorm the Strategies:
Once the various signs are realized, look at modernization strategies, the second S of the paradigm. There are many R strategies available on various forums and blogs. Many forums describe similar or specific cloud provider related strategies. Here we talked about provider agnostic strategies. Out of these, one or more options can be adopted by organizations. Which one to choose depends on use cases, but a good rule of thumb is to always migrate simpler applications first. The well assessed strategy in the transformation journey determines the success rate. We emphasize understanding and adopting the correct one based on specific business needs.
- Rehost: When enterprises rehost an application, it means moving the application to a different host platform without making any changes to the app itself.
- Replatform: An application replatform is similar to rehosting – but with additional adjustments.
- Repurchase: This is perhaps the easiest way to modernize an application. Rather than refactoring, rebuilding, or rehosting, enterprises repurchase new software from the marketplace.
- Refactoring / rearchitecting: This involves rewriting the underlying code of an application to improve operating performance without altering existing functionality. This is commonly seen in monolithic application packages, where enterprises may want to leverage microservice architecture.
- Retire: Many old legacy applications no longer serve the business’s needs. The functionality itself is no longer appealing. It is prudent to retire such applications and launch new ones.
- Retain: Usually this means “revisit” or do nothing (for now). There is always no need to modernize – unless it gives business value. It is possible the legacy is still serving well and no additional value would be added post migration.
- Hybrid: Another strategy to transform in phase wise fashion An organization adopts a hybrid architecture model where the product remains in on-prem, and data is migrated to the cloud. Production runs on-premises, and Disaster Recovery (DR) migration happens in the cloud. This gives organizations confidence in their cloud transformation roadmap.
Design the Solutions:
When a strategy is selected, the 3rd S, i.e., the solution of our discussed paradigm, comes into play. There are various example solutions discussed – corresponding to most adopted strategies. The reader will benefit from having reference knowledge of potential solutions.
Rehosting Migration Solution: –
The solution basically means lifting existing applications and shifting them to a different infrastructure. The target platform should not necessarily be in cloud only; e.g., when IBM mainframe modernization takes place, it is possible to have an Emulated Mainframe platform as target, supported by some like Microfocus, Hercules-390, Oracle Tuxedo, etc. For an easy and simple way to migrate applications, rehosting is the best bet.
Replatforming Migration Solution
Like rehosting, application replatforming is also referred to as lift, tinker, and shift. What this means is that the application is first lifted, tinkered with, and then shifted to the appropriate platform. This suggests that before moving the application to another infrastructure, a significant number of changes are embedded within the system. It is believed that modifying, optimizing, or tweaking the existing application helps increase the performance of the target infrastructure. For example, a common “shaping” activity during Replatforming is to just move data to a suitable cloud native target – and not the database to the cloud.
Repurchase Migration Solution
An organization can eliminate a lot of migration effort and cloud setup by purchasing directly as software as a service (SaaS) or via a different cloud provider’s Marketplace. For example, it is becoming increasingly unusual for organizations to build and operate their own email, payroll, and CRM systems now that mature, capable third-party solutions are available at a low cost. More and more software vendors now offer their wares as managed services hosted on their own infrastructure, or conveniently packaged for hassle-free download and installation in the customer’s estate. It is thus possible to avoid migrating on-premises applications and instead buy the end-user functionality, avoiding the maintenance and management overhead.
Refactoring / Rearchitecting Migration Solutions
Refactoring and Rearchitecting applications enables us to hold onto the best parts of those applications while also adopting agile, scalable, and secure cloud-native features. While many options exist for potential migration methods, rearchitecting is the one that creates a complete transformation, totally reimagining how legacy applications can be rebuilt and operated on the cloud. A good solution example is to decompose the legacy monolith application into microservices and containerize those microservices before deploying them to a Kubernetes cluster or any other cloud native serverless options of any cloud provider.
Hybrid Migration Solution
An enterprise often chooses a hybrid architecture between private and public clouds. With this solution, a phase wise migration happens where, at the initial time, an integration between on-premises and the cloud takes place. Some example solutions are placing data in the cloud but keeping the product in on-prem, or migrating disaster recovery applications to the cloud and keeping production in a private data center. This gives the enterprises tremendous confidence in full-fledged migration. This hybrid nature is not just restricted to on-prem and cloud; it can be done in mainframe modernization too, where data can be kept on the mainframe when products are migrated to open-source worlds where data is fed from the mainframe.
Comparative benefits of the Solutions:
|Refactor / Rearchitect
|No code or architecture changes
|Long-term cost savings
|Immediate Cost saving
|Migrate core services easily
|Start small and scale as needed
|Reduce in-house skills
|Adapting to changing requirements
|Flexibility to use both legacy and cloud
|Easier compliance and security management
|Cloud native functionality
|Reduced effort increases speed of migration
|Gain confidence in phase wise migration
Comparative challenges of the Solutions:
|Refactor / Rearchitect
|Does not take full advantage of the cloud
|The scope of work can grow
|Loss of control
|Does not take full advantage of the cloud.
|Latency and performance issues is inherited
|Might need to common cloud components
|Time & cost
|Difficulty is integration
|Old known problems is inherited
|Automation is required
|Security concerns due to multiple platform
Market trends in modernization adoption:
Gartner Says more than half of enterprise IT spending in key market segments will shift to the Cloud by 2025. Below, market analysis of the worldwide cloud shift from 2019 to projected 2025 shows how much enterprises are moving towards legacy modernization.
In another forum, it shows the trends of various cloud offerings over the last three years. These statistics and references to market trend analysis will help the reader of this paper understand what offerings enterprises are adopting most.
In this paper, it is being tried to encapsulate the legacy modernization journey, starting from the symptoms to its potential solutions. It has been explained from the design thinking point of view – when is the right time, what are the signs to make the call by the organizations with the right strategy selection by knowing its potential solutions, including the pros and cons? It is very important to realize that everything has a lifespan. Today is the era of cloud computing, and tomorrow the same S curve rule will be applicable – when even products and cloud platforms will encounter their maturity point. At that time, some other strategies and solutions would have to be adopted by organizations to be innovative and competitive.
CapEx :- Capital Expenditure
OpEx :- Operational Expenditure
DR :- Disaster Recovery
DaaS :- Desktop as a Service
IaaS :- Infrastructure as a Service
PaaS :- Platform as a Service
SaaS :- Software as a Service
BPaaS :- Business Process as a Service