Answer
At a technical level, this usually means the software has to track object-level and IFS-level replication or restore status, confirm the target LPAR or partition has adequate capacity and the right PTF level to actually run the workload, and verify that subsystems, job queues, and communications configurations activate in the correct order. It also needs to account for security: user profiles, authorization lists, and exit point rules have to exist and function at the recovery site, or users will have a running system they cannot sign onto or use correctly.
Buyers should also look at how the software handles application-layer validation, since a technically successful IPL at the recovery site says nothing about whether RPG or COBOL programs are producing correct output against the recovered data. The strongest DR platforms provide a way to script or checklist these validation steps and capture evidence that they passed, which is what turns a data recovery event into a business recovery event. When comparing products, ask each vendor to walk through what happens in their tool between the moment data is present at the target and the moment the business is operating again, because that gap is where most DR plans actually fail.