New AD Domain: Moving an AlwaysOn Availability Group Node by Node

Moving an AlwaysOn availability group to a new AD domain takes twelve steps, one node at a time. As part of my independent consulting, I also give a high-level overview of a migration strategy. In this engagement, my client wanted the steps to move an AlwaysOn availability group from DomainOld to DomainNew. Another company had acquired them, and they needed to migrate all assets to a new domain. Here are the steps I shared.

Topology

The cluster has three nodes. Node-01 sits behind the listener. Node-02 is synchronous with automatic failover, and Node-03 is asynchronous with manual failover.

The Steps

1. Remove replica Node-03 from the availability group.
2. Evict Node-03 from the Windows cluster.
3. Node-03 is now out of the AG, so rebuild Node-03 in DomainNew.
4. Create a new Windows cluster with one node, Node-03.
5. Use scripts to migrate all server-level objects (logins, jobs, operators) from Node-01 to Node-03.
6. Node-02 needs the same steps as Node-03, with one difference: it joins the same cluster as Node-03 instead of a new cluster.
7. Configure database mirroring for the user databases from Node-01 to Node-03.
8. OUTAGE: fail over the mirrored databases to Node-03, break the mirror and point the application to Node-03.
9. Test, test and test.
10. Evict Node-01 and decommission the original cluster.
11. Rebuild Node-01 in the new domain and add it to the cluster.
12. Back up and restore the databases from Node-03 to the two new nodes. Then implement the AG across all three new nodes.

After getting this high-level guidance, they executed the project, and it went fine. I hope these steps help others who need to move an AlwaysOn availability group.

A domain move is not a rebuild from scratch, it is a series of small, safe steps.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.