SQL 2016 to 2022 AG migration on Azure VMs: how to keep the existing DNN listener name working for apps that cache DNS and can't be restarted?

Question

SQL 2016 to 2022 AG migration on Azure VMs: how to keep the existing DNN listener name working for apps that cache DNS and can't be restarted?

Abimbola Adeniran 106

Environment

Source: 2-node SQL Server 2016 AG on Azure VMs, using a DNN listener
Target: new 2-node SQL Server 2022 AG on Azure VMs,
Database: about 4 TB, to be migrated using a distributed AG
Clients: many applications and reports that use the existing listener name. We can't find every connection string, so the name must keep working after cutover.
The applications cache DNS records, use long-lived connection pools, and can't be restarted.

Question After cutover to the 2022 AG, what is the best way to keep the existing listener name working for these clients without restarting the applications? Since a DNN registers the node IPs, clients with cached records will still point at the old 2016 nodes. What approach would you recommend?

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

2 answers

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 2

Hi @Abimbola Adeniran

In this scenario, I would not recommend relying solely on a DNS change or attempting to reuse the existing DNN listener immediately after cutover.

The challenge is that DNN listeners publish the IP addresses of the cluster nodes in DNS. Applications that cache DNS responses or maintain long-lived connection pools may continue attempting connections to the old SQL Server 2016 AG nodes long after the cutover has occurred.

A common approach is:

Perform the cutover to the SQL Server 2022 AG using the Distributed AG.
Leave the SQL Server 2016 AG online temporarily.
Configure the old environment to forward or redirect client connections to the new SQL Server 2022 listener.
Allow cached DNS entries and existing connection pools to age out naturally.
Decommission the old AG only after confirming that client traffic has migrated successfully.

If preserving the original listener name is a hard requirement, a more predictable solution is to place a stable network endpoint in front of the AGs, such as:

an Azure Load Balancer,
a DNS alias (CNAME),
or another abstraction layer whose backend target can be changed during migration.

This avoids depending on client DNS cache expiration and reduces the impact of applications that cannot be restarted.

For environments where applications maintain long-lived pooled connections and connection strings cannot be fully inventoried, a phased migration strategy with temporary coexistence of the old and new AGs is generally the lowest-risk option. It provides a transition period during which existing sessions continue functioning while new connections are directed to the SQL Server 2022 environment.

Recommendation

Keep the SQL Server 2016 AG available for a transition period after cutover and use a redirection mechanism (DNS alias, load balancer, or network-level abstraction) rather than depending on clients promptly refreshing DNN listener records. This approach minimizes disruption for applications that cache DNS entries or maintain persistent connection pools.

Thanks.

Abimbola Adeniran 106 Reputation points

2026-10-01T07:12:51.61+00:00

Hi @Senthil kumar ,

Thank you so much for your response.

Because keeping the old listener name is a hard requirement, I take your point on keeping the SQL 2016 listener and AG online temporarily post-cutover, with a redirect mechanism (a load balancer, an alias/CNAME or something similar) that redirects connections to the new listener. Which of these do you think would work best for a DNN listener configuration?

The real problem is that the client doesn't have a full inventory of all the connection strings across applications, reports and so on, so we can't just switch to the new SQL 2022 listener post-cutover. Changing connection strings would require rebuilding the apps, which would take time and be complex, so the client isn't considering that either.

If I understand this solution right, some clients will connect to the new listener post-cutover, and any old pooled connections still referencing the old listener will be redirected to the new one. My concern is that a pool only moves to the new listener when the application resolves the listener name again and gets a different answer. If the old listener stays online and redirects, nothing fails, so nothing forces the apps to re-resolve. They keep using their cached records and the pools keep reconnecting to the old listener, which keeps redirecting them. In that case the old listener would have to stay online indefinitely. How would the pools eventually move to the new listener without an application restart?

Thanks.
Senthil kumar 2,580 Reputation points

2026-10-01T07:31:20.51+00:00

My recommendation would be:

Use the Distributed AG for migration and cutover.

Keep the SQL Server 2016 AG online temporarily as a fallback and transition mechanism.

Plan for the original listener name to point directly to the SQL Server 2022 AG as the final state.

Monitor incoming connections to identify clients that continue using the old path.

Remediate those applications over time as they are discovered.