We are planning to migrate our existing SQL Server production environment from a Windows Server 2019 production VM to two physical Windows Server 2022 nodes there any issue during failover

Abdur Rahman M 0 Reputation points
2026-09-03T12:28:29.4333333+00:00

I have successfully set up the wsfc cluster in windows server 2019 VM machine(150.10) by creating the cluster name with IP address 150.xx and add the two secondary node physical machines windows server 2022 (152.11 &152.12) shows up and running and we enable the always on Ha features by restarting the sql service in production VM. our migration plan is failover to new physiacal machine 2022 to make as primary and cut over the old production from always on HA group once application team confirmed accessing without any issues.

-
We still need to create the SQL listener, and as planned, it should be in subnet 152.xx As the cluster is in subnet 150.xx, should this one also be changed?

  • What about once we remove the production DB(win 2019 vm 150.xx) from the cluster? The node will remain, but the nodes are in subnet 192.168.152.x/xx, while the cluster will stay in subnet 192.168.150.x/xx Should we take any action here?
    Need solutions for how to proceed?

 

Windows for business | Windows Server | Storage high availability | Clustering and high availability
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Hoang Le 3,935 Reputation points Independent Advisor
    2026-09-03T13:12:01.03+00:00

    Hello Abdur Rahman M,

    In your current Always On migration plan, the SQL listener must be created in the same subnet where the client applications will connect. Since your new physical nodes are in the 152.x subnet, the listener’s virtual network name and IP should also be provisioned in that subnet. The cluster itself can remain with its core IP in 150.x, but the listener is independent and can be assigned to a different subnet as long as the cluster has a network interface in that range. You simply need to ensure that the Windows Server Failover Cluster has a network resource in 152.x and then add the listener with an IP from that subnet.

    Once you remove the old 2019 VM node in 150.x from the availability group, the cluster will still retain its original 150.x network, but that does not affect the listener or database connectivity. No additional action is required unless you want to fully decommission the 150.x subnet from the cluster, in which case you can safely remove that cluster network resource after the cutover. The critical point is that the listener IP must align with the subnet where the new primary nodes reside, so clients can resolve and connect without routing issues.

    If my answer is useful for you, please hit Accept the answer to support me.

    Thank you,

    HL.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.