Skip to main content

How can I reduce risk when performing an IBM Z hardware upgrade?

IBM Lab Services Senior Project Consultant Lynne Drummond on how to securely perform IBM Z hardware upgrades.

"Ask the Expert' in white letters against a green background

Q: How can I reduce risk when performing an IBM Z hardware upgrade?

Because IBM Z® runs business-critical workloads, a hardware upgrade may seem scary. Proper planning, a skilled team and good communication help reduce the risk and lead to a smoother upgrade.

Planning starts prior to processor delivery. Key team members are the project manager, IBM Z architect, Z network engineer, data center management, Z hardware configuration expert, IBM system services representative and Z system programmers. They need to be engaged in IBM’s Pre-Install Technical and Delivery Assessment (TDA). The TDA is updated for every new processor model and helps identify project tasks, risks and issues.

An important planning step is determining the upgrade approach such as a push-pull or a side-by-side. If multiple processors are upgraded, then what will the order be? Does the granularity need to be at the LPAR, Sysplex or OS level? A design session with colocated key team members is suggested to brainstorm approaches and agree on the plan and timeline.

Upgrade problems often have their root cause in the I/O definition file (IODF). An IODF review by the Z architect, Z consultant and Z system programmer reduces the likelihood of issues and identifies single points of failure. Employ a second set of eyes throughout the project to check cables and labels, LPAR configurations, and hardware management console inputs. If possible, activate a sandbox LPAR on the new processor prior to the actual cutover to perform early checkout of its hardware configuration.

A detailed, choreographed day-of plan with a back-out plan is vital to capture the steps, performers and times required to shut down the old processor, move to the new processor, and perform the checkout activities within the allocated change window. The plan should be reviewed many times prior to the event and include multiple go/no-go checkpoints. A tested, documented back-out plan reduces discussions, decisions and errors if a fallback to the old processor is needed.

A critical participant in the day-of event is operations. A day-of plan may have many parallel tasks in a tight change window requiring experienced operators focused only on the upgrade. Schedule enough operators to support the parallel activities and include them in the final day-of plan review.

A communication plan documents how, what and when communications occur about the event with affected stakeholders (e.g., the project team, end users, application owners and third parties). Take advantage of your change control board (CCB) to schedule the event well in advance. Your team’s CCB representatives will watch for other changes scheduled during the same change window that may impact or be impacted by the upgrade. If possible, the upgrade should be the only event in the window; otherwise, the upgrade becomes an easy target to designate as causing a problem and this can lead to an unneeded back-out.

Following these best practices will help you reduce risk when upgrading your IBM Z hardware. If you have questions or need support, contact IBM Lab Services ( or reach out via email at

IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →