Merge pull request #145205 from MicrosoftDocs/master

2/01 PM Publish

Author: huypub

azure-sql/migration-guides/database/sql-server-to-sql-database-guide.md

@@ -144,6 +144,18 @@ After you verify that data is same on both the source and the target, you can cu
 > [!IMPORTANT]
 > For details on the specific steps associated with performing a cutover as part of migrations using DMS, see [Performing migration cutover](../../../dms/tutorial-sql-server-azure-sql-online.md#perform-migration-cutover).
 
+## Migration recommendations
+
+To speed up migration to Azure SQL Database, you should consider the following recommendations:
+
+|  | Resource contention | Recommendation |
+|--|--|--|
+| **Source (typically on premises)** |Primary bottleneck during migration in source is DATA I/O and latency on DATA file which needs to be monitored carefully.  |Based on DATA IO and DATA file latency and depending on whether it’s a virtual machine or physical server, you will have to engage storage admin and explore options to mitigate the bottleneck. |
+|**Target (Azure SQL Database)**|Biggest limiting factor is the log generation rate and latency on log file. With Azure SQL Database, you can get a maximum of 96 MB/s log generation rate. | To speed up migration, scale up the target SQL DB to Business Critical Gen5 8 vcore to get the maximum log generation rate of 96 MB/s and also achieve low latency for log file. The [Hyperscale](https://docs.microsoft.com/azure/azure-sql/database/service-tier-hyperscale) service tier provides 100 MB/s log rate regardless of chosen service level |
+|**Network** |Network bandwidth needed is equal to max log ingestion rate 96 MB/s (768 Mb/s) |Depending on network connectivity from your on-premises data center to Azure, check your network bandwidth (typically [Azure ExpressRoute](https://docs.microsoft.com/azure/expressroute/expressroute-introduction#bandwidth-options)) to accommodate for the maximum log ingestion rate. |
+|**Virtual machine used for Data Migration Assistant (DMA)** |CPU is the primary bottleneck for the virtual machine running DMA |Things to consider to speed up data migration by using </br>- Azure compute intensive VMs </br>- Use at least F8s_v2 (8 vcore) VM for running DMA </br>- Ensure the VM is running in the same Azure region as target |
+|**Azure Database Migration Service (DMS)** |Compute resource contention and database objects consideration for DMS |Use Premium 4 vCore. DMS automatically takes care of database objects like foreign keys, triggers, constraints and non-clustered indexes and doesn’t need any manual intervention.  |
+
 
 ## Post-migration
 
@@ -191,4 +203,4 @@ To learn more, see [managing Azure SQL Database after migration](../../database/
    -  [Best practices for costing and sizing workloads migrate to Azure](/azure/cloud-adoption-framework/migrate/azure-best-practices/migrate-best-practices-costs) 
 
 - To assess the Application access layer, see [Data Access Migration Toolkit (Preview)](https://marketplace.visualstudio.com/items?itemName=ms-databasemigration.data-access-migration-toolkit)
-- For details on how to perform Data Access Layer A/B testing see [Database Experimentation Assistant](/sql/dea/database-experimentation-assistant-overview).
+- For details on how to perform Data Access Layer A/B testing see [Database Experimentation Assistant](/sql/dea/database-experimentation-assistant-overview).