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

2 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Hoang Le 4,580 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?

  2. Abdur Rahman M 0 Reputation points
    2026-09-07T05:26:56.3833333+00:00

    Hi Hoang Le, Thank you for the clarification.

    Based on your recommendation, we plan to keep the existing WSFC Cluster IP in the 150.xx subnet and not move it to 152.xx.

    For the AG Listener, we plan to configure two virtual IPs—one in the 150.xx subnet and another in the 152.xx subnet—to support connectivity during the migration and failover from the existing production server to the new physical servers.

    Once the failover to the physical 152.xx servers is completed and the old 150.xx production server is removed from the AG, can we then remove the 150.xx Listener IP and retain only the 152.xx Listener IP?

    Please confirm if this is the recommended approach.

    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.