An IBM i release never moves alone
An IBM i operating system upgrade succeeds when every dependent layer is ready for the same cutover. The target release may be supported while an ISV package, Java job, driver, printer, scheduler, interface, or license key is not. Those smaller dependencies are what turn a routine plan into a surprise outage.
Start with the business deadline and supported release options. Then give every dependency an owner, readiness state, test, and rollback requirement. The upgrade date should be the result of that evidence, not the starting assumption.
Move these dependencies as one upgrade plan
Use the table as a cutover gate. Nothing is ready because it appears on an inventory. It is ready when the owner has support evidence, a test result, and a recovery action.
| Dependency |
Decision to make |
Evidence before cutover |
|
IBM i release and hardware
|
Choose a supported source-to-target release sequence for the current or new Power system. |
IBM support matrix, machine compatibility, target release media, and a dated support reason for the move. |
|
Firmware, HMC, VIOS, and PTFs |
Set the order for platform updates and required PTF groups around the operating system change. |
Required levels, install order, estimated duration, IPL needs, and rollback limits. |
|
Packaged software and license keys |
Confirm every ISV product supports the target release and can be licensed on the target machine. |
Vendor statement, version requirement, install media, key delivery date, and support contact. |
|
Applications and integrations
|
Test RPG, COBOL, Java, ODBC, JDBC, APIs, EDI, reports, printers, schedulers, and downstream handoffs. |
Named owner, test case, expected result, actual result, defect status, and go-or-stop decision. |
|
Cutover and rollback
|
Define the change window, backup checkpoint, validation order, stop conditions, and recovery choice. |
Timed runbook, current backup, restore proof, decision owner, communication plan, and accepted outage window. |
Open the IBM i version guide before choosing the target release
Use go, fix first, or stop for every dependency
A spreadsheet full of product names is not an upgrade plan. Give each dependency a readiness state, owner, evidence link, test result, and cutover action. Anything marked fix first needs a completion date. Anything marked stop blocks the change. That simple discipline keeps an optimistic schedule from overruling the facts.