Thinking of pursuing an application modernization project this New Year? Well, the good news is that there are several different approaches (or disposition strategies) available when looking to modernize your legacy-based assets. Of course, the ideal approach (or combination of approaches) for you will depend on a number of factors, such as budget, timeframe, available skill sets, the future direction of your company, to name a few.
This blog helps break down the primary options and determine when to consider selecting them, as well as pros and cons for each approach.
Rehosting (also referred to as “Replatforming”, or “Lift and Shift”) is a proven, mature modernization approach which provides an environment that runs on distributed platforms, emulating the legacy operating environment. The emulation capability minimizes the amount of change that occurs when migrating legacy systems to a distributed platform. Source code is recompiled where possible (or transformed using tools where not), and customized to support the specific rehost technology. Data is migrated – with the structure of some original data types retained, e.g. Relational, VSAM, Sequential, GDGs, etc. Operational functionality provided by third party solutions such as job schedulers, print and output management, security, and systems management solutions is replaced in order to support the same processing capabilities as the original legacy environment.
When to Consider Rehosting:
- Application functionality is meeting the business needs, application development skills are not an issue, cost savings is a primary driver, and there’s an aggressive timeframe to complete the project.
- Also an option if the application is close to the end of its lifecycle and will be retired or replaced in the upcoming years – however has become an obstacle to exiting the mainframe.
Pros:
- Provides a relatively low-cost, low-risk way to reduce operating costs and maintain the business value existing business rules provide.
- Fastest way to migrate workloads off a mainframe.
Cons:
- Retains the legacy code (COBOL, JCL) as-is, which doesn’t address the massive shortage of legacy developers capable of working with the applications. As a key modernization driver, this can be a major showstopper.
- If the existing legacy application doesn’t meet the business needs, a rehosting solution will likely not be the right selection (you’re just moving the problem to a different platform).
- Project complexity increases when targeted legacy workloads contain assets that don’t have an emulated equivalent, e.g. Assembler, proprietary 4GLs, specific Databases, COBOL generated code, etc.
- Resulting target application isn’t optimally positioned to integrate with newer technologies, or initially optimized to take advantage of capabilities, such as scalability, offered by Cloud-based platforms.
- Associated one-time and ongoing maintenance costs of the rehosting software (+ target COBOL solution). For software-focused vendors, this can be high.
Automated Conversion (with various levels of Refactoring) retains functional equivalence while converting core legacy applications to fully maintainable, refactored object oriented Java or C# code. This means once the legacy application and database is converted, developers can extend application functionality directly without having to navigate the original legacy code to do it. Critical business logic from the legacy system is preserved, while enabling deeper integration with other Java or C# workloads and additional customization to meet evolving business requirements.
Various levels of refactoring can be applied during or following an Automated Conversion project. Code is analyzed during the assessment to determine application cloud-readiness and the required refactoring effort to obtain the desired level of elasticity (i.e. horizontal scalability (scale out/in) and vertical scalability (scale up/down)) required by the application workloads being migrated.
When to Consider Automated Conversion:
- Application business logic is generally meeting the business needs.
- Legacy application development skills are becoming scarce.
- Mandated target environment is “legacy free,” leveraging modern technologies and (often) the capabilities offered by elastic Cloud-based platforms.
Pros:
- Legacy languages are consolidated to object oriented languages such as Java or C#, legacy data stores to modern distributed databases.
- Ability to leverage modern distributed platforms and the dynamic scaling abilities provided by a cloud-optimized environment by applying different levels of refactoring.
- Projects typically complete in a similar timeframe to rehosting – approx. 75% faster than a reengineering approach, and are significantly less expense.
- Eliminated or greatly reduced ongoing software fees depending on the selected target solution.
Cons:
- Possibility of receiving unmaintainable converted source code (commonly known as “JOBOL”). There are different levels of Automated Conversion solutions available, and it’s critical that the right solution is selected. Transcoding solutions are highly automated, however generate unmaintainable, un-optimized line-for-line procedural Java or C# code. Select a rules-based solution if the goal is to actually maintain the resulting code, and if required – leverage a Proof of Translation (PoT) in order to get a better understanding of the converted source code.
- As with Rehosting, if the application doesn’t meet the business needs, reengineering might be a better option if the timeframe and budget is available.
Reengineering captures original application specifications where applicable, incorporates any required new functionality (and this is typically a driver for this approach) – then redesigns and develops the new solution using the latest application frameworks.
When to Consider Reengineering:
- Existing application business logic isn’t meeting the business needs
- Little-to-no time pressure or budget constraints
- Ultimate goal is to replace existing monolith functionality with a cloud-native architecture such as microservices.
Pros:
- Completely customized solution which meets exact requirements
- Ability to leverage the latest application frameworks, architectures, and solutions, e.g. Cloud-native platforms, Microservices, DevOps to increase agility and meet evolving market demands, etc.
- Eliminated or greatly reduced ongoing software fees depending on the selected target solution.
Cons:
- While initially appealing – project costs, complexity and delivery timeframes often spiral out of control due to the low-level of automation utilized.
- Difficulty specifying requirements, and ultimately the increased testing effort (a critical function of all modernization projects) when the project is no longer a like-for-like validation.
A Replace (also referred to as a Repackage or COTS replacement) approach focuses on replacing legacy application functionality with packages and components available from third party vendors. A key example of this is replacing specific legacy functionality with a proprietary Enterprise Resource Planning (ERP) solution such as SAP.
When to Consider Replace:
- Commodity packages are perfect for situations where the business requirements and application are a natural fit with an existing package.
- Application source code is no longer available, reducing the feasibility of a successful Rehosting or Automated Conversion project.
Pros:
- Reduced application maintenance as the vendor is responsible for fixing production bugs and implementing new functional enhancements.
Cons:
- Commercial packages offer standard domain business processes that often end up being far more expensive than other modernization options due to the level of customization required to meet the specific requirements of the customer (think: traditional multi-year SAP adoption horror stories!).
- Additionally, once vendor code is changed it is no longer supported by the vendor and fixes/enhancements from the vendor become more complicated to apply and test.
Finally, when you think about selecting vendor partners on your disposition path, keep in mind that the majority of application modernization specialty vendors focus on only a single modernization option, whereas large Systems Integrators claim to be experts in many approaches, however masters of few – often relying on the aforementioned specialty vendors to deliver their specific solutions.
