SQL Server 2017 – Distributed Availability Groups on Standard Edition

I believe it is possible to restore with same old answer that subject to condition you are not using any "enterprise specific" features. This you can get from

select * from sys.dm_db_persisted_sku_features.

If you are using any such feature you would have to stop using it, take fresh backup and then restore. I know its hard to tell because starting from SQL Server 2016 Sp1 standard provides far more features support. So at the last the answer would be you need to restore and test.

Good news is SQL Server 2017 RTM Evaluation Edition is released so you have the Eval edition for your testing.

It is feasible? Can I mix 2016 and 2017 AGs in a Distributed AG?

I have confirmed from Allan Hirt SQL Server MVP and HA/DR Guru that this is indeed possible and supported. So please go ahead, the confusion may arise because in BOL two different things are mentioned. I will highlight both

Quoting from Distributed Availability groups document

A distributed availability group spans multiple availability groups, each on its own underlying WSFC cluster, and a distributed availability group is a SQL Server-only construct. This means the WSFC clusters that house the individual availability groups can have different major versions of Windows Server. The major versions of SQL Server must be the same

So while you can have different Windows server version in DAG but you cannot have different SQL Server version in DAG. From here it seems like the versions should be same but if you again look at Upgrading Availability group instances it says

To migrate to a new version of the SQL Server instance using AGs, the only supported method is a distributed AG, which is in SQL Server 2016 Enterprise Edition or later.

Now you should believe this one not the the previous one.

Or there is (obviously!) something that I'm missing and there's a simpler or more proper way to make it?

Apart from distributed AG, I would consider 2 approaches here

1. Side By side upgrade

I believe transaction logshipping should help here.

• Create new WSFC with SQL Server 2017 installed--No downtime

• Do not create AG as of now

• Logship database from SQL Server 2016 to SQL Server 2017. --No downtime

• During "cutover" stop logshipping and bring database on SQL Server 2017 online.--small downtime

• Now point application to this new database.

• Go ahead and configure AG on new SQL Server 2017.

I know there is bit of pain involved in configuring logshipping if you have big databases but this is best I see.

2. In-place upgrade

Do the rolling upgrade of Availability groups. Upgrading Availability group instances