Acorlynx fixes

Author: jovanpop-msft

articles/sql-database/sql-database-managed-instance-migrate.md

@@ -1,6 +1,6 @@
 ---
-title: Migrate SQL Server instance to Azure SQL Database managed instance | Microsoft Docs
-description: Learn how to migrate a SQL Server instance to Azure SQL Database managed instance. 
+title: Migrate database from SQL Server instance to Azure SQL Database - Managed instance | Microsoft Docs
+description: Learn how to migrate a database from SQL Server instance to Azure SQL Database - Managed instance. 
 services: sql-database
 ms.service: sql-database
 ms.subservice: migration
@@ -68,9 +68,9 @@ As an outcome of this activity you should have documented average and peak value
 Managed instance is tailored for on-premises workloads that are planning to move to the cloud. It introduces a [new purchasing model](sql-database-service-tiers-vcore.md) that provides greater flexibility in selecting the right level of resources for your workloads. In the on-premises world, you are probably accustomed to sizing these workloads by using physical cores and IO bandwidth. The purchasing model for managed instance is based upon virtual cores, or “vCores,” with additional storage and IO available separately. The vCore model is a simpler way to understand your compute requirements in the cloud versus what you use on-premises today. This new model enables you to right-size your destination environment in the cloud. Some general guidelines that might help you to choose the right service tier and characteristics are described here:
 - [Monitor CPU usage on your SQL Server instance](https://techcommunity.microsoft.com/t5/Azure-SQL-Database/Monitor-CPU-usage-on-SQL-Server/ba-p/680777#M131) and check how much compute power you currently use (using Dynamic Management Views, SQL Server Management Studio, or other monitoring tools). You can provision a Managed Instance that matches the number of cores that you are using on SQL Server, having in mind that CPU characteristics might need to be scaled to match [VM characteristics where Managed Instance is installed](https://docs.microsoft.com/azure/sql-database/sql-database-managed-instance-resource-limits#hardware-generation-characteristics).
 - Check the amount of available memory on your SQL Server instance, and choose [the service tier that has matching memory](https://docs.microsoft.com/azure/sql-database/sql-database-managed-instance-resource-limits#hardware-generation-characteristics). It would be useful to measure page-life expectancy on your SQL Server instance to determine [do you need additional memory](https://techcommunity.microsoft.com/t5/Azure-SQL-Database/Do-you-need-more-memory-on-Azure-SQL-Managed-Instance/ba-p/563444).
-- Measure IO latency of the file sub-system to determine do you need General Purpose or Business Critical instance.
+- Measure IO latency of the file subsystem to choose between General Purpose and Business Critical service tiers.
 
-You can select compute and storage resources at deployment time and then change it afterwards without introducing downtime for your application using the [Azure portal](sql-database-scale-resources.md):
+You can choose compute and storage resources at deployment time and then change it afterwards without introducing downtime for your application using the [Azure portal](sql-database-scale-resources.md):
 
 ![managed instance sizing](./media/sql-database-managed-instance-migration/managed-instance-sizing.png)
 
@@ -132,7 +132,7 @@ For a quickstart showing how to restore a database backup to a managed instance
 ## Monitor applications
 
 Once you have completed the migration to Managed Instance, you should track the application behavior and performance of your workload. This process includes the following activities:
-- [Compare performance of the workload running on the Managed Instance](#compare-performance-with-baseline) with the [performance baseline that you created on the source SQL Server](#create-performance-baseline).
+- [Compare performance of the workload running on the Managed Instance](#compare-performance-with-the-baseline) with the [performance baseline that you created on the source SQL Server](#create-performance-baseline).
 - Continuously [monitor performance of your workload](#monitor-performance) to identify potential issues and improvement.
 
 ### Compare performance with the baseline
@@ -153,18 +153,18 @@ As a result, you should compare performance parameters with the baseline and ide
 > In many cases, you would not be able to get exactly matching performance on Managed Instance and SQL Server. Managed Instance is a SQL Server database engine but infrastructure and High-availability configuration on Managed Instance may introduce some difference. You might expect that some queries would be faster while some other might be slower. The goal of comparison is to verify that workload performance in Managed Instance matches the performance on SQL Server (in average), and identify are there any critical queries with the performance that don’t match your original performance.
 
 The outcome of the performance comparison might be:
-- Workload performance on Managed Instance are aligned or better that the workload performance on SQL Server. In this case you have successfully confirmed that migration is successful.
+- Workload performance on Managed Instance is aligned or better that the workload performance on SQL Server. In this case you have successfully confirmed that migration is successful.
 - Majority of the performance parameters and the queries in the workload work fine, with some exceptions with degraded performance. In this case, you would need to identify the differences and their importance. If there are some important queries with degraded performance, you should investigate are the underlying SQL plans changed or the queries are hitting some resource limits. Mitigation in this case could be to apply some hints on the critical queries (for example changed compatibility level, legacy cardinality estimator) either directly or using plan guides, rebuild or create statistics and indexes that might affect the plans. 
-- Most of the queries are slower on Managed Instance compared to your source SQL Server. In this case try to identify the root causes of the difference such as [reaching some resource limit]( sql-database-managed-instance-resource-limits.md#instance-level-resource-limits) like IO limits, memory limit, instance log rate limit, etc. If there are no resource limit that can cause the difference, try to change compatibility level of the database or change database settings like legacy cardinality estimation and re-start the test. Review the recommendations provided by Managed Instance or Query Store views to identify the queries that regressed performance.
+- Most of the queries are slower on Managed Instance compared to your source SQL Server. In this case try to identify the root causes of the difference such as [reaching some resource limit]( sql-database-managed-instance-resource-limits.md#instance-level-resource-limits) like IO limits, memory limit, instance log rate limit, etc. If there are no resource limits that can cause the difference, try to change compatibility level of the database or change database settings like legacy cardinality estimation and re-start the test. Review the recommendations provided by Managed Instance or Query Store views to identify the queries that regressed performance.
 
 > [!IMPORTANT]
 > Managed Instance has built-in automatic plan correction feature that is enabled by default. This feature ensures that queries that worked fine in the paste would not degrade in the future. Make sure that this feature is enabled and that you have executed the workload long enough with the old settings before you change new settings in order to enable Managed Instance to learn about the baseline performance and plans.
 
-Make the change of the parameters or upgrade service tiers to converge to the optimal configuration until you get the workload performance that fit your needs.
+Make the change of the parameters or upgrade service tiers to converge to the optimal configuration until you get the workload performance that fits your needs.
 
 ### Monitor performance
 
-Once you are on a fully managed platform and you have verified that workload performance are matching you SQL Server workload performance, take advantages that are provided automatically as part of the SQL Database service. 
+Once you are on a fully managed platform and you have verified that workload performances are matching you SQL Server workload performance, take advantages that are provided automatically as part of the SQL Database service. 
 
 Even if you don't make some changes in managed instance during the migration, there are high chances that you would turn on some of the new features while you are operating your instance to take an advantage of the latest database engine improvements. Some changes are only enabled once the [database compatibility level has been changed](https://docs.microsoft.com/sql/relational-databases/databases/view-or-change-the-compatibility-level-of-a-database).