The guide attempts to details the steps involved in site failover and failback.
Number of factors needs to be considered before site failover,
Active CMS location
During a pool failover that involves the pool hosting the Central Management store, you must fail over the Central Management store before you fail over the Front End pool.
Edge Federation Route
For federation relationships with other organizations running Lync Server, inbound federation requests will continue to work as long as you have configured each Edge pool to have a different priority in your SRV records. Any federation requests that come to an Edge pool that is down will fail back and then connect to an Edge pool which is running.
Outbound federation is always set up through one published Edge pool or Edge Server in the organization. If this Edge pool has gone down, you must use Topology Builder to change the outbound federation route to use an Edge pool which is still running
To configure DNS to redirect Skype for Business Server 2015 web traffic to your disaster recover (DR) and failover sites, you need to use a DNS provider that supports GeoDNS. You can set up your DNS records to support disaster recover, so that features that use web services continue even if one entire Front End pool goes down. This DR feature supports the Autodiscover, Meet and Dial-in simple URLs.
Assuming the LAB environment does not have GeoDNS in place and the web services are pointing to source pool “sgpool”, you will need to manually reconfigure the DNS to point the web services to destination pool “klpool”, both internal & external DNS records needs to be considered.
Response groups does not failover during pool failover. Perform regular backup of response group configuration. Restore them on the destination pool only after failover.
PSTN Gateway Configuration
Once your front end pool is fail-over, all SfB services are shut down for the source pool. Ensure the PSTN gateway can fail-over calls to destination pool.