Collaborations > Minimize Costs, Maximize Security: Mainframe Migration from CA ACF2 to IBM RACF in 6 Months

5 Min reading time

Minimize Costs, Maximize Security: Mainframe Migration from CA ACF2 to IBM RACF in 6 Months

The migration project not only optimized costs but also strengthened security, showcasing a strategic partnership and technical prowess in mainframe management.

Overview

This case study showcases a collaborative project between IBM and CROZ to migrate a mainframe customer from CA ACF2 to IBM RACF. The project focused on cost optimization, minimal downtime, and ensuring operational continuity. It involved extensive planning, testing, and the development of specialized migration tools. The successful six-month migration demonstrated technical expertise and a deep understanding of client needs, enhancing security while maintaining system effectiveness.

Challenge

Minimize Costs, Maximize Security: Mainframe Migration from CA ACF2 to IBM RACF in 6 Months. Together with IBM we helped a large mainframe customer to migrate from CA ACF2 to IBM RACF while having in mind cost optimization with minimum downtime and impact on customer’s regular operations.

“CROZ has demonstrated a great level of technical understanding, expertise and empathy of the client needs. Prerequisites, implementation approach and project activities which helped in ensuring a smooth project outcome – were aptly identified and managed.

The successful implementation of the project within 6 months is a tremendous achievement for all of us and is highly appreciated by the client. Truly the dedication and partnership we have shown to the client is extraordinary. We are looking forward to working with CROZ on other zOS projects in the future!”

-Bee Lin Ng, Senior Project Manager, IBM Technology Services, ASEAN.

Solution

The client is relying on IBM Mainframe technology for many years to support their core business and mission critical services. Client’s mainframe runs z/OS as an operating system, and it is specific to z/OS that security is handled through an external security manager. Today, there are three common mainframe security system solutions on the market: IBM RACF, Broadcom CA – ACF2 and Top-secret. They all do the same thing but in different ways. In addition to different ways of functioning, they are also distinguished by price, which is the main reason the client decided to move to IBM RACF after 30 years.

The customer’s main objective was cost optimization due to increased third party SW licensing & maintenance costs. The key challenge was the short runway to migrate before Broadcom contract renewal with minimum downtime and impact on regular operations. It was also important to provide the same level of effectiveness for the new product in a day-to-day operations, which also meant that a thorough education on the RACF features and differences between RACF and ACF2 was required.

Our journey with the client began by performing an initial assessment, during which we analysed the client’s infrastructure and client’s pain points. After getting a better picture, we agreed to do a Proof of Concept (PoC) to prove to the client that IBM’s RACF security system can do everything that Broadcom’s security system was doing and that their applications and everything else will work with the same quality (as they did before the replacement). As part of the PoC, we tested the security system on several dozens of users, main subsystems, and middleware.

After we showed the client that tool replacement to RACF was feasible, a full assessment of the production and development environment began, followed by detailed replacement planning. The tool replacement started from the smallest production LPAR to the largest LPARs which were affecting many users and business services. For the migration to be successfully prepared and tested we needed to have an exact copy of z/OS LPARs. This was achieved by the client providing isolated clone LPARs. Cloned LPARs had volumes that were a FlashCopy of all existing production volumes. We trimmed them and tuned them to start up with IBM’s RACF product. After cloned LPARs were working with RACF and we finished testing all main z/OS components and subsystems, the applications and 3rd party software products and components (such as the tape and backup management systems) were thoroughly tested. At the moment when everything was configured and working without any errors, the RACF database and all of the changes that were made on the clones were transferred to the production systems, and a migration (cut-over) of the system was performed. The last two LPARs had the greatest impact on operations and business services. Due to the high complexity and the sheer number of subsystems and applications, we agreed to perform the migration of the last two LPARs on-site at the Customer’s location to minimize any possible mishaps in communication. The tool replacement has been done through the night during the previously approved downtime window. For the actual migration, we developed several tools to ease the process itself.

The main tool which was used is the ACF2 to RACF conversion tool which was designed to be adapted to the client’s needs and requirements regarding the naming conventions, RACF group structure, etc. It is a tool that generates RACF commands designed to mimic the security rules that was already in place in ACF2 based on many-to-many relationships between existing and new rules. It uses the data available from various ACF2 utilities and does not access the ACF2 databases directly, and instead relies on documented interfaces available in ACF2. This allows for seamless use, no matter which version of ACF2 is used and/or possible exits that could be affecting the normal operation of ACF2. For the client, we provided several tools and solutions designed to ease the migration of business procedures dependent on ACF2-specific features such as UID strings, which are not available in RACF. The most important tool is the ACF2 lookup tool which allows the security administrators to quickly determine the necessary groups to which the RACF user needs to be connected to allow the same kind of access as it was in ACF2. For further ease, the utility generates relevant RACF commands which can be copied directly to job cards or to ISPF to minimize the chances of typos and mistakes. The greatest challenge which was present during the migration was the issue of undercutting access in RACF profiles, which doesn’t happen in ACF2. This kind of problem had to be fixed manually, per each reported issue. Some features of ACF2 simply did not have a direct replacement in RACF (such as PDS member protection) and for these instances, we had to work with the client to analyze the business need behind the feature and come up with equivalent protection in the form of operator command protection. We embraced the challenge and successfully completed ACF2 to RACF migration within the stipulated Customer timeline requirements with strong Project Governance and PM leadership to manage a delivery team from four different time zones.