Merge pull request #276610 from abhims14/patch-9

Update sql-virtual-machines-limitations.md

Author: prmerger-automator[bot]

articles/dms/includes/sql-virtual-machines-limitations.md

@@ -22,7 +22,8 @@ ms.custom:
 - If you're using a VM with SQL Server 2012 or SQL Server 2014, you need to store your source database backup files on an Azure Storage Blob Container instead of using the network share option. Store the backup files as page blobs since block blobs are only supported in SQL 2016 and after.
 - You must make sure the SQL IaaS Agent Extension in the target Azure Virtual Machine is in **Full mode** instead of Lightweight mode.
 - SQL IaaS Agent Extension  only supports management of Default Server Instance or Single Named Instance.
-- The number of databases you can migrate to a SQL server Azure Virtual Machine depends on the hardware specification and workload, but there is no enforced limit. However, every migration operation (start migration, cutover) for each database will take few mins sequentially. For example, to migrate 100 databases, it may take approx. 200 (2 x 100) minutes to create the migration queue/s and approx. 100 (1 x 100) minutes to cutover all 100 databases (excluding backup and restore timing). Therefore, the migration will become slower as the number of databases increases. Microsoft advises either scheduling a longer migration window in advance based on rigorous migration testing or partitioning large number of databases into batches when migrating them to a SQL server Azure VM.
+<!-- The number of databases you can migrate to a SQL server Azure Virtual Machine depends on the hardware specification and workload, but there is no enforced limit. -->
+- You can migrate a maximum of 100 databases to the same Azure SQL Server Virtual Machine as the target using one or more migrations simultaneously. Moreover, once a migration(s) with 100 databases finishes, wait for at least 30 minutes before starting a new migration to the same Azure SQL Server Virtual Machine as the Target. Also, every migration operation (start migration, cutover) for each database will take few mins sequentially. For example, to migrate 100 databases, it may take approx. 200 (2 x 100) minutes to create the migration queue/s and approx. 100 (1 x 100) minutes to cutover all 100 databases (excluding backup and restore timing). Therefore, the migration will become slower as the number of databases increases. Microsoft advises either scheduling a longer migration window in advance based on rigorous migration testing or partitioning large number of databases into batches when migrating them to a SQL server Azure VM.
 - Apart from configuring the Networking/Firewall of your Azure Storage Account to allow your VM to access backup files. You also need to configure the Networking/Firewall of your SQL Server on Azure VM to allow outbound connection to your storage account.
 - You need to keep the target SQL Server on Azure VM **power ON** while the SQL Migration is in progress. Also, when creating a new migration, failover or cancel the migration.
 - **Error**: `Login failed for user 'NT Service\SQLIaaSExtensionQuery`.