Merge pull request #36818 from MicrosoftDocs/main

Auto Publish – main to live - 2026-03-10 22:30 UTC

Author: learn-build-service-prod[bot]

azure-sql/includes/sql-managed-instance/known-issues-after-migration.md

@@ -0,0 +1,29 @@
+---
+author: MashaMSFT
+ms.author: mathoma
+ms.reviewer: randolphwest
+ms.date: 03/06/2026
+ms.service: azure-sql-managed-instance
+ms.topic: include
+---
+
+### Restore operation failures after migrating to SQL Managed Instance
+
+If you migrate a database to Azure SQL Managed Instance from SQL Server 2019 and later versions with [accelerated database recovery](/sql/relational-databases/accelerated-database-recovery-concepts) enabled, but configured with the persistent version store (PVS) set to something other than the `PRIMARY` file group, you can experience restore operation failures on the target SQL managed instance. 
+
+To work around this issue, make sure you set the [persistent version store (PVS) to PRIMARY](/sql/relational-databases/accelerated-database-recovery-management#change-the-pvs-filegroup) on the source SQL Server database before you migrate it to SQL Managed Instance. If you already migrated the database without setting the PVS to `PRIMARY`, you can set it on the source SQL Server database, and then re-migrate the database to SQL Managed Instance.
+
+### Unable to use accelerated database recovery after migrating to SQL Managed Instance
+
+Starting with SQL Server 2019, if you migrate a database to Azure SQL Managed Instance, and the source database has [accelerated database recovery](/sql/relational-databases/accelerated-database-recovery-concepts) disabled, you can't use accelerated database recovery on the target SQL managed instance. 
+
+To work around this issue, make sure you [enable accelerated database recovery](/sql/relational-databases/accelerated-database-recovery-management#enable-accelerated-database-recovery) on the source SQL Server database before you migrate it to SQL Managed Instance. If you already migrated the database without enabling accelerated database recovery, you can enable it on the source SQL Server database, and then re-migrate the database to SQL managed instance.
+
+SQL Server 2017 and earlier versions don't support accelerated database recovery, so this issue doesn't apply to databases migrated from those versions of SQL Server.
+
+### Unable to use Service Broker after migrating to SQL Managed Instance
+
+If you migrate a database to Azure SQL Managed Instance, and [Service Broker is disabled on the source database](/sql/database-engine/service-broker/how-to-activate-service-broker-message-delivery-in-databases-transact-sql), you can't use Service Broker on the target SQL managed instance.
+
+To work around this issue, make sure you enable Service Broker on the source SQL Server database before you migrate it to SQL Managed Instance. If you already migrated the database without enabling Service Broker, you can enable it on the source SQL Server database, and then re-migrate the database to SQL Managed Instance.
+

azure-sql/includes/sql-managed-instance/prepare-database-for-migration.md

@@ -0,0 +1,47 @@
+---
+author: MashaMSFT
+ms.author: mathoma
+ms.reviewer: randolphwest
+ms.date: 03/06/2026
+ms.service: azure-sql-managed-instance
+ms.topic: include
+---
+
+### Enable accelerated database recovery
+
+For SQL Server 2019 and later versions, enable [accelerated database recovery](/sql/relational-databases/accelerated-database-recovery-concepts), and ensure the persistent version store (PVS) is set to `PRIMARY`. If accelerated database recovery isn't enabled on the source SQL Server database, you can't enable it on the target SQL managed instance after the database is migrated. If the persistent version store (PVS) isn't set to `PRIMARY`, you can experience issues with restore operations on the target SQL managed instance.
+
+For SQL Server 2017 and earlier versions, accelerated database recovery isn't supported, so this step isn't necessary.
+
+To configure accelerated database recovery properly on the source SQL Server database, follow these steps:
+
+1. Enable accelerated database recovery by running the following Transact-SQL script on SQL Server:
+
+   ```sql
+   ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
+   ```
+1. The persistent version store (PVS) must be set to `PRIMARY` on the source database, which is the default configuration. If this was changed previously, you must [change it back to PRIMARY](/sql/relational-databases/accelerated-database-recovery-management#change-the-pvs-filegroup) before starting the migration.
+
+### Enable Service Broker
+
+[Service Broker](/sql/database-engine/configure-windows/sql-server-service-broker) is enabled by default for all versions of SQL Server. If Service Broker was disabled and you plan to use it on SQL Managed Instance, enable Service Broker on the source SQL Server database before you migrate to SQL Managed Instance. If Service Broker isn't enabled on the source SQL Server database, you can't use it on the target SQL managed instance.
+
+To check if Service Broker is enabled, run the following Transact-SQL script on SQL Server instance:
+
+```sql
+SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
+FROM sys.databases
+WHERE name = '<database name>';
+```
+
+If Service Broker is disabled, enable it by running the following Transact-SQL script on the source SQL Server database:
+
+```sql
+USE master;
+GO
+
+ALTER DATABASE [<database name>]
+    SET ENABLE_BROKER;
+GO
+```
+

azure-sql/managed-instance/doc-changes-updates-known-issues.md

@@ -22,7 +22,10 @@ This article lists the currently known issues with [Azure SQL Managed Instance](
 
 | Issue | Date discovered | Status | Date resolved |
 | --- | --- | --- | --- |
-| [Misleading error message when connecting to a read replica using invalid credentials](#misleading-error-message-when-connecting-to-a-read-replica-using-invalid-credentials) | February 2026 |
+| [Restore operation failures after migrating to SQL Managed Instance](#restore-operation-failures-after-migrating-to-sql-managed-instance) | March 2026 | Has workaround | |
+| [Unable to use Service Broker after migrating to SQL Managed Instance](#unable-to-use-service-broker-after-migrating-to-sql-managed-instance) | March 2026 | Has workaround | |
+| [Unable to use accelerated database recovery after migrating to SQL Managed Instance](#unable-to-use-accelerated-database-recovery-after-migrating-to-sql-managed-instance) | March 2026 | Has workaround | |
+| [Misleading error message when connecting to a read replica using invalid credentials](#misleading-error-message-when-connecting-to-a-read-replica-using-invalid-credentials) | February 2026 |No resolution| |
 | [Modifying backup retention period for the free offer](#modifying-backup-retention-period-for-the-free-offer) | June 2025 | Has workaround | |
 | [Login to read-secondary failed due to long wait on "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"](#login-to-read-secondary-failed-due-to-long-wait-on-hadr_database_wait_for_transition_to_versioning) | April 2025 | Has workaround | |
 | [Interim guidance on 2024 time zone updates for Paraguay](#interim-guidance-on-2024-time-zone-updates-for-paraguay) | March 2025 | Resolved | February 2026 |
@@ -60,6 +63,9 @@ This article lists the currently known issues with [Azure SQL Managed Instance](
 
 ## Has workaround
 
+[!INCLUDE [known-issues-after-migration](../includes/sql-managed-instance/known-issues-after-migration.md)]
+
+
 ### Modifying backup retention period for the free offer
 
 You can only modify the backup retention policy of your databases in the free SQL managed instance by using [REST API](/rest/api/sql/managed-backup-short-term-retention-policies), [PowerShell](/powershell/module/az.sql/set-azsqlinstancedatabasebackupshorttermretentionpolicy), and [Azure CLI](/cli/azure/sql/midb/short-term-retention-policy) commands. You can't modify the backup retention policy through the [Azure portal](https://portal.azure.com).

azure-sql/managed-instance/log-replay-service-migrate.md

@@ -58,6 +58,8 @@ Make sure that you meet the following requirements for SQL Server:
 - For SQL Server 2016 and later, you can [take your backup directly](#take-backups-directly-to-your-blob-storage-account) to your Azure Blob Storage account.
 - Although having `CHECKSUM` enabled for backups isn't required, it's highly recommended to prevent unintentionally migrating a corrupt database, and for faster restore operations.
 - Any version of Windows Server is supported based on the SQL Server version supportability.
+- For SQL Server 2019 and later, accelerated database recovery should be enabled, with the persistent version store set to `PRIMARY`. For more information, see [Known issues after migrating to SQL Managed Instance](#known-issues-after-migrating-to-sql-managed-instance) in this article.
+- To use Service Broker on a database migrated to Azure SQL Managed Instance, Service Broker must be enabled on the source database before migration. For more information, see [Known issues after migrating to SQL Managed Instance](#known-issues-after-migrating-to-sql-managed-instance) in this article.
 
 ### Azure
 
@@ -630,6 +632,9 @@ Consider the following limitations when migrating with LRS:
 - There are two scenarios, at the beginning and end of the migration process, where a migration is aborted if a failover occurs, and the migration job must be manually restarted from the beginning as the database is dropped from SQL Managed Instance:
   - If a failover occurs when the first full database backup is in the process of being restored to SQL Managed Instance when the migration job is first started, then the migration job must be manually restarted from the beginning.
   - If a failover occurs after migration cutover is initiated, the migration job must be manually restarted from the beginning. Ensure the last backup file is as small as possible to minimize cutover time and reduce the risk of a failover during the cutover process.
+- If [accelerated database recovery](/sql/relational-databases/accelerated-database-recovery-concepts) is disabled on your source SQL Server 2019 and later instances, you can no longer enable it after migrating to Azure SQL Managed Instance. Additionally, if the persistent version store (PVS) isn't set to `PRIMARY`, you can experience issues with restore operations on the target SQL managed instance.
+- If [Service Broker](/sql/database-engine/configure-windows/sql-server-service-broker) is disabled on the source SQL Server instance, you can't use Service Broker on the target SQL managed instance after migration.
+
 
 > [!NOTE]  
 > If you require a database to be read-only accessible during the migration, with a much longer time frame for performing the migration and with minimal downtime, consider using the [Overview of the Managed Instance link](managed-instance-link-feature-overview.md) feature as a recommended migration solution.
@@ -655,6 +660,12 @@ If it's important that databases are available as soon as cutover completes, the
 - Migrate to the General Purpose service tier first, and then upgrade to the **Business Critical** service tier. Upgrading your service tier is an online operation that keeps your databases online until a short failover as the final step of the upgrade operation.
 - Use the [Managed Instance link](managed-instance-link-migrate.md) for an online migration to a **Business Critical** instance without having to wait for databases to be available after the cutover.
 
+## Known issues after migrating to SQL Managed Instance
+
+Consider the following known issues after migrating to Azure SQL Managed Instance:
+
+[!INCLUDE [known-issues-after-migration](../includes/sql-managed-instance/known-issues-after-migration.md)]
+
 ## Troubleshoot LRS issues
 
 After you start LRS, use either of the following monitoring cmdlets to see the status of the ongoing operation:

azure-sql/managed-instance/managed-instance-link-feature-overview.md

@@ -5,7 +5,7 @@ description: This article describes the Managed Instance link, which you can use
 author: djordje-jeremic
 ms.author: djjeremi
 ms.reviewer: mathoma, randolphwest
-ms.date: 01/28/2026
+ms.date: 03/06/2026
 ms.service: azure-sql-managed-instance
 ms.subservice: data-movement
 ms.topic: concept-article
@@ -125,8 +125,6 @@ When failing back to SQL Server, you can choose to fail back:
 
 :::image type="content" source="media/managed-instance-link-feature-overview/disaster-recovery-scenario.png" alt-text="Diagram showing the disaster recovery scenario.":::
 
-
-
 ## Use Azure services
 
 Use the link feature to take advantage of Azure services by using SQL Server data without migrating it to the cloud. Examples include reporting, analytics, backups, machine learning, and other jobs that send data to Azure. 
@@ -199,20 +197,19 @@ Data replication limitations include:
 
 Configuration limitations include: 
 
-  - If there are multiple SQL Server instances on a server, you can configure a link for each instance, but you must configure each instance to use a separate database mirroring endpoint, with a dedicated port per instance. Only the default instance should use port 5022 for the database mirroring endpoint. 
-  - You can place only one database into a single availability group for one Managed Instance link. However, you can replicate multiple databases in a single SQL Server instance by establishing multiple links. 
+- If there are multiple SQL Server instances on a server, you can configure a link for each instance, but you must configure each instance to use a separate database mirroring endpoint, with a dedicated port per instance. Only the default instance should use port 5022 for the database mirroring endpoint. 
+- You can place only one database into a single availability group for one Managed Instance link. However, you can replicate multiple databases in a single SQL Server instance by establishing multiple links. 
 
    > [!NOTE]
    > If you're interested in participating in a limited preview of a change to this behavior, please fill out the following [form](https://aka.ms/milink-multidb-prpr).
 
-  - You can create a link with an existing availability group with a single database. If your existing availability group has multiple databases, you can create a link with the availability group only if you remove all databases except one from the availability group.
-  - A single General Purpose or Business Critical SQL Managed Instance supports up to 100 links, and a single Next-gen General Purpose SQL Managed Instance supports up to 500 links, from the same, or from multiple SQL Server sources.
-  - A Managed Instance link can replicate a database of any size if it fits into the chosen storage size of the target SQL Managed Instance deployment.
-  - Managed Instance link authentication between SQL Server and SQL Managed Instance is certificate-based and available only through an exchange of certificates. You can't use Windows authentication to establish the link between the SQL Server instance and the SQL managed instance.
-  - You can establish a link with only s [VNet-local endpoint](connectivity-architecture-overview.md#vnet-local-endpoint) to SQL Managed Instance. 
-  - You can't use public endpoint or private endpoints to establish the link with the managed instance.
-  - You can't replicate databases with multiple log files, because SQL Managed Instance doesn't support multiple log files.
-
+- You can create a link with an existing availability group with a single database. If your existing availability group has multiple databases, you can create a link with the availability group only if you remove all databases except one from the availability group.
+- A single General Purpose or Business Critical SQL Managed Instance supports up to 100 links, and a single Next-gen General Purpose SQL Managed Instance supports up to 500 links, from the same, or from multiple SQL Server sources.
+- A Managed Instance link can replicate a database of any size if it fits into the chosen storage size of the target SQL Managed Instance deployment.
+- Managed Instance link authentication between SQL Server and SQL Managed Instance is certificate-based and available only through an exchange of certificates. You can't use Windows authentication to establish the link between the SQL Server instance and the SQL managed instance.
+- You can establish a link with only a [VNet-local endpoint](connectivity-architecture-overview.md#vnet-local-endpoint) to SQL Managed Instance. 
+- You can't use public endpoint or private endpoints to establish the link with the managed instance.
+- You can't replicate databases with multiple log files, because SQL Managed Instance doesn't support multiple log files.
 
 Feature limitations include:
 
@@ -223,6 +220,8 @@ Feature limitations include:
    - If you're migrating a database that is configured as a Publisher in a transactional replication topology by using the link, you must reconfigure the database as a Publisher on the target instance after the migration is complete.
 - If you're using distributed transactions with a database that's replicated from the SQL Server instance and, in a migration scenario, on the cutover to the cloud, Distributed Transaction Coordinator capabilities won't be transferred. It's not possible for the migrated database to get involved in distributed transactions with the SQL Server instance, because the SQL Managed Instance deployment doesn't support distributed transactions with SQL Server at this time. For reference, SQL Managed Instance today supports distributed transactions only between other managed instances. For more information, see [Distributed transactions across cloud databases](../database/elastic-transactions-overview.md#transactions-for-sql-managed-instance).
 - If you're using Transparent Data Encryption (TDE) to encrypt SQL Server databases, you need to export the database encryption key from SQL Server and upload it to Azure Key Vault, and you need to also configure the BYOK TDE option on SQL Managed Instance before creating the link.
+- If [accelerated database recovery](/sql/relational-databases/accelerated-database-recovery-concepts) is disabled on your source SQL Server 2019 and later instances, you can no longer enable it after migrating to Azure SQL Managed Instance. Additionally, if the persistent version store (PVS) isn't set to `PRIMARY`, you can experience issues with restore operations on the target SQL managed instance.
+- If [Service Broker](/sql/database-engine/configure-windows/sql-server-service-broker) is disabled on the source SQL Server instance, you can't use Service Broker on the target SQL managed instance after migration.
 - You can't link SQL Managed Instance databases that are encrypted with service-managed TDE keys to SQL Server. You can link an encrypted database to SQL Server only if you encrypted it with a customer-managed key and the destination server has access to the same key that's used to encrypt the database. For more information, see [Set up SQL Server TDE with Azure Key Vault](/sql/relational-databases/security/encryption/setup-steps-for-extensible-key-management-using-the-azure-key-vault). 
 - You can't establish a link between SQL Server and SQL Managed Instance if the functionality that you use on the SQL Server instance isn't supported on the SQL managed instance. For example: 
     - You can't replicate databases with file tables and file streams, because SQL Managed Instance doesn't support file tables or file streams.