Answer
There's no universal one-size-fits-all DR-test procedure, since the specific steps needed depend entirely on which parts of your own IFS solution are actually in use and being tested. Regardless of your specific solution mix, plan for two broad categories of change: (1) amending direct database-connection references so all relevant components correctly point at the restored database on the new server rather than the original production server, and (2) switching off or redirecting any external messages/integrations that could get triggered once the Middleware is reconfigured and started up against the restored database, specifically to avoid inadvertently sending real production-looking messages or data out to external systems during what's meant to be an isolated DR test. Beyond the core database/Middleware reconfiguration itself, specifically check and account for: PL/SQL Access Provider connections, System Parameters that may reference environment-specific values, BI Services, Document Management, especially if documents are stored externally to the database, Constraint Based Scheduling, Demand Planner, PSO setup and connectivity, and the full IFS Connect integration layer, routing rules, routing addresses, and the overall Connect setup — each of these needs to be reviewed for whether it would inadvertently reach out to production systems or external parties during the DR test.