IBM i High Availability Software

How often should role swaps be tested in an IBM i high availability environment?

Role swaps should be tested often enough that the procedure stays routine, the application dependencies stay current, and leadership can trust the continuity promise being funded. The exact cadence depends on workload criticality and change rate, but the important point is that testing must be scheduled, evidenced, and reviewed instead of deferred indefinitely.

Answer

A useful starting cadence for critical IBM i workloads is a full role swap at least quarterly, with a lighter failover verification monthly for the systems that carry the highest business risk. Less critical applications can often tolerate semiannual testing, but the schedule should be written down and tied to a calendar trigger, not left to whenever operations has a free maintenance window. Change is the enemy of an untested swap: new PTFs, RPG or COBOL program changes, added subsystems, or new interfaces to the application can all break a failover path that worked cleanly six months ago.

A real test means the secondary system actually takes over production processing for a defined period, not just a technical confirmation that replication is caught up. That includes verifying 5250 session access, interfaces to other systems, printed output routing, and that batch schedules resume correctly on the new primary. Buyers should ask vendors how the software documents each swap, including start and end times, issues encountered, and remediation items, because that evidence is what auditors and executives actually want to see.

Ask specifically what happens to the swap-back. A platform that makes swapping to the secondary easy but swapping home again cumbersome will discourage exactly the testing cadence the organization needs.

Back to IBM i High Availability Software