Assign Failover Cluster and High Availability Always On from Old to New Domain
An important note is to ensure you have databases fully backed up before beginning any migration path, particularly when moving between domains. File permissions, and other problems could result in data loss &amp; require reverting to those backups.
If you are using Windows Server 2019
With Windows Server 2019, migrating a cluster to a new domain is supported via a straightforward process documented here.
Given most folks are still on 2016 and older
With Windows Server 2016 &amp; older, the migration process involves destroying the cluster, and rebuilding it on the new domain. Given the need to destroy &amp; re-create the cluster, I recommend uninstalling before &amp; reinstalling after the SQL Server installation. You will want to have good backups before the migration as well.
The instructions to move a Windows Server Failover Cluster to a new domain are included in the docs, and quoted below.
Build a fresh cluster
Building a fresh cluster &amp; migrating to it is going to be your best option. (And moving to an Availability Group at the time would be my preferred path, too!)
If you don't have new or extra hardware to build new, you can do something like this to reuse existing servers:

Evict a node from your existing FCI.
Uninstall SQL Server from that node.
Remove the server from the domain &amp; add it to the new domain.
Build the new single-node Windows cluster on the new domain.
Install the FCI on the single-node cluster.
Unmount storage from cluster in the old domain.
Mount storage to the cluster in the new domain.

Note: Be prepared to encounter NTFS permissions issues on your disks. Permissions will be assigned to users/groups on the old domain.
Alternatively, you could assign fresh storage on the new domain &amp; move databases via backup/restore or log shipping.


Attach your databases.
Repeat steps 1-3 for remaining nodes.
Add remaining nodes to the FCI on the new node.


Documented Cluster Migration steps:

The steps in this article enable the Cluster service to start in the new domain. However, you may be unable to bring the resources online in the new domain, and the resources that can be brought online may not work correctly.
To move the cluster:

Create a user account for the Cluster service in the new domain. You must make sure that no Group Policy objects (GPOs) or security template requirements remove any of these rights. The user account must have the following rights:

Lock pages in memory.
Log on as a service.
Act as part of the operating system. (Windows 2000 and Windows Server 2003)
Back up files and directories.
Increase quotas.
Increase scheduling priority.
Load and unload device drivers.
Restore files and directories.
Adjust memory quotas for a process (Windows Server 2003).
For more information about the Cluster service account, click the following article number to view the article in the Microsoft Knowledge Base:



269229 How to manually re-create the Cluster service account
In addition, the Cluster service account must have administrative permissions on all nodes in the cluster.

Set the Startup value for the Cluster service to Manual on all nodes in the cluster:
a. Click Start, point to Settings, click Control Panel, and then double-click Services.
b. Click Cluster Service, and then click Startup.
c. Change the Startup Type from Automatic to Manual.
d. Click OK.

Stop the Cluster service on all cluster nodes:

Click Start, point to Settings, click Control Panel, and then double-click Services.

Click Cluster Service, and then click Stop.

Turn off all nodes except one.

Move the node into the new domain by using procedures that are appropriate to your operating system. Complete the process, and then restart the node.

On the node, change the service account that is used by the Cluster service to log on to the domain to the user account that you created.

Start the Cluster service on that node.


10.Use Cluster Administrator to verify that there are no issues. Try to bring all resources online. Test the functionality of all resources from client computers, and then check the Event Viewer System log for error messages.

⚠ Note
At this point, you can still cancel the move by moving this node back into the old domain and starting the nodes that are not moved.


If the first node move is successful, continue to migrate the other nodes in the cluster to the new domain starting with step 5 for each node.