It’s time for the second blog in our replacing mainframe tools blog series – this time focusing on the importance of the PoC. Throughout this blog, we will guide you through the six key steps involved in PoC, providing insights and tips to ensure a smooth transition to your new mainframe tools.
The proof-of-concept phase is a critical step in the migration of existing mainframe tooling to its replacement. During this phase, we aim to validate the both the feasibility of the migration and the new tools’ performance and functionality. The proof-of-concept phase helps us to identify potential issues and bottlenecks and challenges early in the migration process or even before the start of migration and ensures that the final solution will meet your requirements.
From identifying the scope of the PoC to validating results
We consider the following steps as the key steps involved in this phase of mainframe tools migration:
1. Identify the scope of the proof of concept: The first step is to define the scope of the proof-of-concept phase. This involves identifying the specific tools and functionalities that need to be migrated and the expected outcomes of the migration. An abundance of caution must be observed when defining the scope since the PoC phase must tackle all technical aspects of the migration and be particularly focused on proving that there are no obstacles in terms of migrating the features to the new tooling. On the other hand, you should be cautious also to not over-do the PoC and perform the actual migration. Usually that means that you should somehow limit the PoC by agreeing on a subset of users, applications, rules, subsystems of the actual environment (say most complicated 10% of rules or applications). During the migration of Broadcom CA ACF2 to IBM RACF, we agreed with the client to limit the PoC to the scope of roughly 100 users that are accessing half a dozen CICS regions (each with different features and resources attached), and to protect only the system resources along with the application resources (CICS transactions, CICS files and also the physical VSAM files themselves).
2. Set up the environment: The next step is to set up the new environment for the migration. This includes reconfiguring the hardware, software, and network infrastructure to support the migration process. Ideally, this would entail setting up new LPARs and sysplexes that are an (almost perfect) replica of actual environments which would later be migrated.
3. Perform the small-scale migration: The PoC phase usually entails performing a migration which is limited in its scope when considering actual migration process can now be performed, where the mainframe tools are migrated to the new platform. This step involves installing the new tooling, migrating the existing data, code, and other assets from the old toolset to the new.
4. Test the functionality: Once the migration is complete, the project team should test the new tools’ functionality. This involves running comprehensive set of tests to verify that the new tooling works as expected and meets your requirements.
5. Test the performance: In addition to testing the functionality, the project team should also test the new tools’ performance. This involves benchmarking the tools to ensure that they perform well under expected loads and that they can handle your workload. This is especially important in the mainframe world since most of the tooling, along with hardware is licensed by the CPC capacity and/or use (otherwise known as MSUs).
6. Validate the results: Finally, the project team should validate the results of the proof-of-concept phase. This involves comparing the performance and functionality of the new tools against the old tools’ performance and functionality to ensure that the migration was successful. Formal sign-off of this result should be used as the input to any further decisions on migration.
Based on the results of the proof-of-concept phase, the project team can make informed decisions about whether to proceed with the full migration or make necessary changes to the migration plan. If the results are positive, the team can move forward with the migration process, confident that the new tools will meet the organization’s requirements.
On the other hand, if the results of the proof-of-concept phase are not satisfactory, the project team may need to revisit the migration plan and make necessary changes. For example, the team may need to plan for alternative implementation of old features to better use the feature set which is available in the new tooling or to even identify alternative set of tools that better meets the organization’s requirements.
Why should you keep PoC in mind?
Overall, the proof-of-concept phase is a critical step in the mainframe tools migration process. It helps mitigate potential risks and ensures that the final solution meets the organization’s needs. By carefully planning and executing the proof-of-concept phase, the project team can ensure a successful migration and a smooth transition to the new platform, and by performing comprehensive testing of the new tools’ functionality and performance, the project team can also confirm and prove that the end solution meets the organization’s requirements and also that potential issues were successfully identified and addressed early in the migration process.
