Reaching out to learn if anyone experienced any issues when migrating to new infrastructure using Distributed Availability Group (DAG) in SQL Server.

Back Story :

Our current infrastructure is on Windows 2016 and SQL 2019. We have traditional (failover cluster based) availability group set up between the replicas.

We are planning to migrate to Windows 2022 and SQL 2022. Because there is two version difference, we cannot add Windows 2022 nodes to the existing the cluster and migrate the databases to SQL 2022.

So, the plan is to set up Distributed Availability Group(DAG) between the current and new AG's and migrate the databases and cut over to the new AG.

Few things we learnt after reviewing the Microsoft docs :

  1. Distributed Availability Group (DAG) is all TSQL based setup.
  2. There is no UI based AG dashboard for DAGs unlike the normal AG dashboard.
  3. There is no reference to DAG in the WSFC. It is only a SQL Server construct.
  4. More work on the global primary to push the data to more replicas.
  5. Pause DB activity on the global primary when cutting over to the new AG and verify the LSNs are sycned.

We are planning to do this DAG migration process for each AG ( one DB in each AG) and the some dbs are multi terabyte ( > 20 TBs).

We are trying to find if anyone encountered any issues while failing over to the new AG in DAG or any other gotchas to keep in mind while doing the cut over.

1 Answer 1


We have successfully leveraged DAG for multiple critical environments. We performed several rounds of testing failing back and forth from legacy to new environment. The most important part of dealing with DAG is you have to stop as much application traffic as possible when failing over.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.