A planned failover is something that you perform when you know in advance you are going to need a failover. This could be a hurricane coming your way and you want to be proactive, or maybe you just need to do some maintenance on the primary server. The nice thing about this failover type is that you won’t have noticeable downtime or data loss, so this procedure can also be used as a test of your disaster recovery procedures (note that this can be done with Test Failover as well).
Follow this procedure:
Shut down the production VM. Planned failover will give you an error notification when it is still running. You do need to do this manually since the wizard won’t do it for you.
Right-click on the production VM that runs on the primary server and choose Planned Failover...as shown in Figure 22.
By default, the checkbox for Reverse the replication direction after failover is not selected. It is advised to select this checkbox as shown in Figure 23, so that the production VM will receive the changes back with no data loss when the planned failover procedure is finished. One note of caution here: At that moment, the primary server also becomes a replica server, so the host must be configured to allow replication (see the section on enabling a host as replica server).
You will see the planned failover happening (Figure 24) and if all goes well, you will finally get a message that the failover has succeeded. At that time, the replica VM is running rather than the production VM.
A few words of caution are needed here. If you have configured alternative network settings, then they are working now. Imagine that your replica VMs are in another data center and you are not using stretched VLANs—at that moment your network config probably is different. That also means that you need to redirect your users who connect to that server accordingly. DNS updates are not done automatically by the planned failover wizard, so it might be that additional manual work is needed from your side.
And of course, you can do this entirely by using PowerShell.
On the primary server (“core” is the name of my VM):
$PrimaryVM1 = “Core”
Start-VMFailover -VMName $PrimaryVM1 –prepare
Then jump to the replica server:
$ReplicaVM1 = “Core”
Start-VMFailover -VMName $ReplicaVM1
And finally, when you also want to reverse the replication:
Set-VMReplication -reverse -VMName $ReplicaVM1
The replica VM up and running, there is no data loss and we have reversed the direction. Now let’s assume that whatever happened or needed to happen at the primary server is done, and we want to start the procedure again. To be able to do that, we are going to perform another planned failover, but this time it will start from the replica server. So we will shut down the VM again (downtime!) and follow the same procedure as above.
The failover will happen again, and you will reverse the replication back to your starting point (see Figure 25).
If you are using extended replication, note that you will have more options here. In this example, you can fail over from A to B and reverse the replication to A. But in an A,B,C scenario, you might want to fail over to B and use C as the new replica or fail over completely to C—all new scenarios that you can use.
 When this is done on a failover cluster, these PowerShell commands should be run against the server that is the current owner of that VM