This blog discusses the primary disposition strategies for mainframe modernisation - 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 modernise 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 modernisation approach which provides an environment that runs on distributed platforms (including your favorite Cloud provider), whilst emulating the legacy operating environment. The emulation capability minimises 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 customised 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 are 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 optimised 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, whilst enabling deeper integration with other Java or C# workloads and additional customisation to meet evolving business requirements. Code is analysed 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-optimised 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-optimised 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 modernisation options due to the level of customisation 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 Re-engineering:
-
- 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 customised 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 utilised.
- Extremely long code freezes are required in the source environment to allow for development and deployment of newly reengineered / rewritten modules.
- Difficulty specifying requirements, and ultimately the increased testing effort (a critical function of all modernisation 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 modernisation journey
- On-demand webinar: Rehosting mainframe applications
