Welcome to our cookbook series on replacing mainframe tools, where we’ll provide expert tips to help you navigate the process with ease. In this blog, we’ll cover the essential initial assessment phase and preparation of a transition plan for migrating to newer, more cost-effective solutions.
Mainframe systems are complex and critical for many organizations. The applications running on these systems are often responsible for critical business operations, which makes it essential to maintain the systems and applications’ availability, reliability, and performance. Mainframe systems usually have a large number of specialized software tooling, which can make the cost of maintaining the system high. As a result, many organizations are considering replacing their mainframe tools with other offerings from various vendors in the eco-system or even migrating to open-source solutions, in hope of achieving higher saving and once again proving the cost-effectiveness of the platform. This process of replacing mainframe tools is a complex one that requires careful planning and execution. Needless to say, the process also poses significant risks, but with careful planning, those can also be mitigated to the lowest possible measure.
How to get started?
The process of replacing mainframe tools typically begins with an initial assessment phase. During this phase, we would evaluate the current mainframe environment to determine which features can be replaced on a direct one-to-one basis and which features must be reengineered to achieve same business purpose albeit with a different behind-the-scenes technical implementation. The assessment will involve gathering data about the current system and applications, identifying the dependencies between the tools and applications and day-to-day business processes and requirements, and identifying any potential risks or issues that may arise during the migration process.
Key steps for the assessment phase & migration plan development
The assessment phase will typically involve the following steps:
1. Identify the scope of the project: You must determine which tools will be replaced and in which environments the tooling will be replaced. This will depend on factors such as the level of support for the current toolset, dependence on the tooling from the aspect of business continuity, and the organization’s budget. The scope of work must be very unambiguous in its’ wording, otherwise the whole project might be declared a failure for exceeding the budget and/or timeline due to scope-creep.
2. Gather data: You must gather data about the current tooling and used features. This will also involve identifying any customizations or modifications that have been made since the introduction of the tool in question. Some of the data can be gathered directly by examining the system configuration and peeking in the PARMLIB, but the primary source of knowledge are always the people that are using the toolset on a day-to-day basis. “Trust but verify” is the mantra during this phase. Oftentimes engineers using the system are unaware of all the features that are used, especially if they are not user accessible (think exits, custom modules, deprecated features, etc.) and these should be specifically searched for in the system using the available documentation from the vendor. Sometimes, even simple things such as a basic keyword search through the configuration files can prove (or disprove) the use of a feature which might be difficult to replace. A real-world example that comes to mind for such a situation is proving the usage of custom ACF2 routines for CICS applications that we encountered during the migration from Broadcom CA ACF2 to IBM RACF. There, the customers’ team thought that they did not have any non-standard security interfaces in their applications, but a basic keyword search using ISPF’s SearchFor utility and an exhaustive list of keywords proved them the opposite! The ACF2 routine ACFAEUCC was used in several very old applications, but its’ business function was migrated easily to standard CICS security interfaces.
3. Evaluate the data: Once the data has been gathered, it must be evaluated to determine which features can be outright transferred to the new tools and which ones must be reengineered to perform the same business function as the existing features. This evaluation will involve looking at factors such as the complexity of replacement, the impact on the applications and end-users, and the potential risks and issues that may arise during the migration process.
Checklist : How to develop a migration plan?
Based on the evaluation of the data, the organization must develop a plan for replacing the toolset. The development of a migration plan is a critical part of the process of replacing mainframe tools. The migration plan will outline the steps involved in the migration process, including the identification of replacement tools, the migration approach, and the timeline and budget. The migration plan will typically involve the following steps:
✔ Develop a timeline: The organization must develop a timeline for the migration process. This timeline will typically include milestones and deadlines for each phase of the migration process, such as the configuration of the replacement tools, the testing phase, and the deployment phase.
✔ Develop a budget: The organization must develop a budget for the migration process. This budget will include the cost of configuring the replacement tools, the cost of testing and deploying the tools, and any other costs associated with the migration process, such as training and support costs.
✔ Plan for risks and issues: You must plan for any potential risks and issues that may arise during the migration process. This will involve identifying the potential risks and issues, such as system downtime or data loss, and developing mitigation strategies to minimize the impact of these risks and issues, along with a development of a backout plan.
✔ Plan for testing: You must plan for testing the replacement tools before deployment. This will involve developing a testing strategy and identifying the resources and people needed for testing.
✔ Plan for deployment: You must plan for deploying the new tools. This will involve communication and planning with other users and external stakeholders and also identifying the resources and tools needed for deployment.
In the end you must ensure that the plan is above-all realistic, and achievable within the allocated budget and timeline. The plan must also be flexible enough to account for any last-minute changes or unexpected issues that may arise during the migration process.
Let’s wrap it up!
In conclusion, replacing mainframe tools is a complex multi-step process that requires careful planning and execution. The assessment phase involves evaluating the current mainframe environment to determine which features can be replaced and which ones must be reengineered or outright decommissioned. The goals of replacing mainframe tooling are typically cost reduction, performance improvement, and higher availability. The development of a migration plan involves identifying replacement tools, determining the migration approach, developing a timeline and budget, planning for risks and issues, and planning for testing and deployment. A well-developed migration plan can help you successfully replace mainframe tools and achieve your goals of reducing costs and improving performance and availability.
