Can a SQLServer 2016 AG with one database be setup with two separate Managed Instance Links?

Question

Can a SQLServer 2016 AG with one database be setup with two separate Managed Instance Links?

Abimbola Adeniran 106

I’m planning a migration of a SQL Server 2016 Always On AG with a single 4TB database to Azure SQL Managed Instance. We already have one MI acting as a read‑replica for reporting and analytics.

As part of the migration, I’m considering deploying a second MI to become the new primary target, and then reseeding the existing read‑replica MI afterwards via CDC for ETLs, ADF, Fabric.

Before proceeding, I need to confirm:

Can a SQL Server 2016 AG with a single 4TB database establish two separate Managed Instance Links to two different Managed Instances at the same time?

If yes, what happens to the other MI Link and its target when one of the MI Links is promoted as the primary replica?

Answer accepted by question author

3 additional answers

Your answer

Answer 1

Manoj Kumar Boyini 9,180 Microsoft External Staff Moderator

Hi Abimbola Adeniran,

Yes, a SQL Server 2016 database can establish multiple Managed Instance Links at the same time, provided each link connects that database to a different Azure SQL Managed Instance. Each link is implemented as a separate distributed availability group, so multiple links can coexist for the same database when targeting different MIs.

However, for SQL Server 2016 sources, it’s important to understand the behavior during cutover. When you promote (fail over) to one Managed Instance, that MI becomes the new primary and the distributed availability group used for that link is removed. Because SQL Server is no longer acting as the source after cutover, any other Managed Instance links that depended on it will stop synchronizing. Those additional MIs must then be reseeded or reconfigured from the new primary.

Key points

Multiple links from one database to different Managed Instances are supported.

Cutover to a Managed Instance is a one-way migration event for SQL Server 2016.

After cutover, other replicas must be reseeded or linked from the new primary.

Helpful reference:
https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/managed-instance-link-feature-overview?view=azuresql
https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/managed-instance-link-configure-how-to-scripts?view=azuresql&tabs=sql-server
https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/managed-instance-link-failover-how-to?view=azuresql&tabs=tsql

Hope this helps, Please let us know if you have any questions and concerns.

Abimbola Adeniran 106 Reputation points

2026-02-14T13:32:18.71+00:00
Hi @Manoj Kumar Boyini

Thanks for the clarification, that makes sense regarding multiple MI Links and the behaviour during cutover.

I have a follow‑up question about the “reseed or reconfigure the other (reporting) MI from the new primary” part.

As I explained, the plan is to have two Managed instances

one MI dedicated to OLTP (this will become the new primary after cutover), and

a separate Reporting MI that must remain isolated from OLTP workloads but still needs access to OLTP data for analytics.

Right now (precutover), the Reporting MI receives CDC tables through MI Link from the on‑prem primary, and our ADF/Fabric pipelines read those CDC tables on the Reporting MI. After cutover, MI Link is removed and SQL Server is no longer the source, so the Reporting MI will stop receiving changes.

My question is: what does “reseed or reconfigure the Reporting MI from the new primary” typically look like in practice?

Specifically, what are the supported or recommended approaches for keeping OLTP and reporting workloads separate while still getting OLTP data onto the Reporting MI after cutover?

I’m trying to understand the cleanest way to rebuild the Reporting MI and re‑establish a CDC‑driven ingestion pattern (or an equivalent pattern) once the new MI becomes the primary.

Any guidance on the recommended approach for this scenario would be really helpful. Thanks as always!
Manoj Kumar Boyini 9,180 Reputation points Microsoft External Staff Moderator

2026-02-16T20:43:36.7466667+00:00

Hi Abimbola Adeniran,

Once you complete the cutover and your new OLTP Managed Instance becomes the primary, the original SQL Server–based Managed Instance Link is removed. At that point, SQL Server is no longer the source of changes, which means your Reporting MI will stop receiving updates. From there, the Reporting MI needs to be refreshed from the new primary and a new ongoing synchronization pattern needs to be established.

In practical terms, “reseed or reconfigure” usually means doing a one-time initialization followed by setting up a new change propagation method.

The first step is to reseed the Reporting MI. The supported way to do this between Managed Instances is to take a full backup of the new OLTP MI to Azure Blob Storage and restore that backup onto the Reporting MI. This ensures both environments start from a consistent state.

Once the Reporting MI is refreshed, you then need a supported way to keep it in sync while maintaining workload isolation.

If you require near real-time replication and want a clean separation between OLTP and reporting workloads, transactional replication is typically the most straightforward approach. In this model, the new OLTP Managed Instance acts as the Publisher and the Reporting MI acts as the Subscriber. This gives you controlled, continuous replication while keeping reporting traffic completely isolated from OLTP workloads. The official documentation for transactional replication on Managed Instance can be found here: https://learn.microsoft.com/azure/azure-sql/managed-instance/replication-transactional-overview

If your current design already relies on CDC and ADF or Fabric pipelines, you can continue using that pattern after cutover. You would enable CDC on the new OLTP MI and use ADF or Fabric to capture incremental changes and apply them to the Reporting MI. This approach works well when you want transformation flexibility or curated reporting layers. Documentation for CDC and incremental data movement is available here: https://learn.microsoft.com/sql/relational-databases/track-changes/about-change-data-capture-sql-server and https://learn.microsoft.com/azure/data-factory/tutorial-incremental-copy-overview

It’s important to note that Managed Instance Link does not automatically continue after cutover, and it is not designed for Managed Instance–to–Managed Instance replication. After the migration is complete, replication or CDC-based ingestion becomes the supported way to maintain your OLTP and reporting separation.

In your scenario, since you already use CDC-driven ingestion and want strict workload isolation, the cleanest approach is usually to reseed the Reporting MI using backup/restore and then re-establish either transactional replication or your CDC + ADF/Fabric pattern from the new primary.

Hope this helps, Please let us know if you have any questions and concerns.

Answer 2

Mladen Andzic - Msft 11 Microsoft Employee

Yes, you can replicate a single database in AG from SQL Server 2016+ to multiple Azure SQL MIs using the link feature.

Step-by-step process is described in this video on the Azure SQL channel:

https://youtu.be/a3d6jDuM5RA

You promote your managed instance to primary by simply deleting its link, since there's no failover capability for MI link in SQL Server versions 2016 - 2019. It doesn't affect the other link in any way.

Note that database on the second (reporting) instance remains in read-only mode as long as it's linked to your SQL Server. You'll need to break that link before reseeding the second MI from your primary MI.

Manoj Kumar Boyini 9,180 Reputation points Microsoft External Staff Moderator

2026-02-23T11:54:36.04+00:00

Hi Abimbola Adeniran,

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Akhil Gajavelly 1,570 Reputation points Microsoft External Staff Moderator

2026-03-05T05:17:59.4033333+00:00

Hi @Abimbola Adeniran ,

Thank you everyone for the detailed explanation of your scenario and for continuing the discussion.

As mentioned by the community members, Managed Instance Link is built on Distributed Availability Groups. Since the documentation does not clearly describe a scenario where the same source database maintains multiple MI Links to different Managed Instances simultaneously, the best approach would be to validate this configuration in a non-production environment before relying on it for migration planning.

Testing the behavior with a smaller test database and separate Managed Instances can help confirm whether the configuration works as expected for your environment.

Please feel free to share the results or let us know if you have any additional questions.

Thanks,
Akhil.
Akhil Gajavelly 1,570 Reputation points Microsoft External Staff Moderator

2026-03-11T04:35:00.8433333+00:00

Hi @Abimbola Adeniran ,

As mentioned earlier, because Managed Instance Link relies on Distributed Availability Groups, the safest approach is to validate the configuration in a non-production environment using a small test database and separate Managed Instances before using it for migration planning.

If you still have questions or run into any issues during testing, please feel free to reply here and the community will be happy to assist.

Thanks,
Akhil.

Answer 3

Erland Sommarskog 133.1K MVP Volunteer Moderator

I found interesting that the AI answer said "no, you cannot do that" and Manoj gladly said "yes, you can do that!".

I had a hinch that the AI was right, but since this is not really an area where I can claim expertise, I reached out to some MVP friends how know this stuff well. And they confirmed what I thought: A database can only be part of one DAG (Distributed Availability Group), and an MI Link is built on a DAG.

However, what should work is to have an MI link to an MI with a readable secondary. That is, Abimbola would use the same MI link for both migration and the readable secondary. I don't have all steps, but I suspect that you may to stop the current MI link and start over. Also, I believe that to have a readable secondary, you need to have Business Critical, so if you are General Purpose today, this means that the cost will go up quite a bit.

Abimbola Adeniran 106 Reputation points

2026-02-17T17:14:02.7733333+00:00

Hi @Erland Sommarskog , thanks for adding your 2cent. There's no MS guidance out there that clearly speaks to the possibility or impossibility of having a db be part of more or two MI links. We have an MI lik to a read replica SQL MI using for reporting, but we're looking to move the application to MI using MI link for near-zero downtime. We would prefer to have no to little downtime for the OLTP environment and can arrange reasonable downtime for the reporting, just trying to work out how all of that comes together
Erland Sommarskog 133.1K Reputation points MVP Volunteer Moderator

2026-02-17T21:25:46.6666667+00:00

I'm looking at https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/distributed-availability-groups?view=sql-server-ver17 and it seems that a replica indeed can be part of two DAGs, but there are some special circumstances, so it may not fit in with you MI Link scenario.

Then again, you can test setting up a second MI link to see what happens. If you get an error message saying you can't, you have hit a brick wall. If it works, it looks promising, but just because there are no error message, does not mean that it is supported.

If you test, I recommend that you spin up two new MIs for the test and set up the MI links for a test database rather than testing with production.
Manoj Kumar Boyini 9,180 Reputation points Microsoft External Staff Moderator

2026-02-18T20:28:41.4+00:00

Hi Abimbola Adeniran,

Just checking in to see if the information provided earlier was helpful. Please let us know if you need any additional details or assistance, and we’ll gladly continue supporting you.

Answer 4

A SQL Server 2016 Always On Availability Group (AG) can establish multiple Managed Instance Links, but there are specific limitations to consider. Each Managed Instance Link is database scoped, meaning you can only have one link per database. However, you can create multiple links from a single SQL Server instance to different Azure SQL Managed Instances, provided that each link is configured for a separate database.

In your case, since you have a single 4TB database in the AG, you would not be able to set up two separate Managed Instance Links for that same database simultaneously. If you attempt to do so, the existing link would need to be removed before establishing a new one.

When one Managed Instance Link is promoted as the primary replica, the other link to the second Managed Instance would be affected as follows: the link that is not promoted would remain in its current state, but you would not be able to failover or promote both links simultaneously for the same database. Essentially, promoting one link would break the existing link to the other Managed Instance, as only one link can be active for a database at any given time.

Therefore, for your migration strategy, you would need to consider establishing the links sequentially rather than concurrently for the same database.

Share via

Can a SQLServer 2016 AG with one database be setup with two separate Managed Instance Links?

3 additional answers

Your answer