This blog discusses the primary disposition strategies for mainframe modernization - and the pros and cons for each approach.
Thinking of pursuing a mainframe migration project in 2022 and beyond?
Well, the good news is that there are several different approaches (or disposition strategies) available when looking to modernize your mainframe estate.
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, or the future direction of your company, to name a few. This blog helps break down the primary options and determines 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 (including your favorite Cloud provider), while 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 saving 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.
- Developers can continue to work on their familiar code and applications.
- Reduces MIPS, which in turn, reduces costs significantly.
- Fastest way to migrate workloads off a mainframe.
Cons:
-
- Retains the legacy code (COBOL, JCL) as-is, which doesn’t address the shortage of legacy developers capable of working with the applications.
- 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.
- Refactoring (also known as ‘Automated Conversion’) retains functional equivalence while refactoring core legacy applications to fully maintainable, object-oriented Java or C# code. This means once the legacy application and database are transformed, 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. 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) needed by the application workloads being migrated.
When to consider Automated Refactoring:
-
- 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 per cent faster than a re-engineering approach, and are significantly less expensive.
- Eliminated or greatly reduced ongoing software fees depending on the selected target solution.
Cons:
-
- Possibility of receiving unmaintainable and / or un-optimized converted source code (commonly known as ‘JOBOL’).
- As with Rehosting, if the application doesn’t meet the business needs then Automated Refactoring may not be the best solution.
- 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.
- 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.
- Re-engineering (also known as ‘Rewrite’) 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.
- Extremely long code freezes are required in the source environment to allow for development and deployment of newly re-engineered / rewritten modules.
- 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.
Further resources
- On-demand webinar: Know the details, reduce the risk: How to begin your mainframe modernization journey
- On-demand webinar: Rehosting mainframe applications
