Updated best practices with minor corrections

Author: hariramt

articles/postgresql/migrate/migration-service/best-practices-migration-service-postgresql.md

@@ -54,7 +54,7 @@ The following phases are considered for calculating the total downtime to perfor
    - Comparing maximum or minimum IDs of key application-related columns.
 
     > [!NOTE]
-    > The size of databases needs to be the right metric for validation. The source instance might have bloats or dead tuples, which can bump up the size of the source instance. It's normal to have size differences between source instances and target servers. An issue in the first three steps of validation indicates a problem with the migration.
+    > The comparative size of databases is not the right metric for validation. The source instance might have bloats or dead tuples, which can bump up the size of the source instance. It's normal to have size differences between source instances and target servers. An issue in the preceding three steps of validation indicates a problem with the migration.
 
 - **Migration of server settings**: Any custom server parameters, firewall rules (if applicable), tags, and alerts must be manually copied from the source instance to the target.
 - **Changing connection strings**: The application should change its connection strings to a flexible server after successful validation. This activity is coordinated with the application team to change all the references of connection strings pointing to the source instance. In the flexible server, the user parameter can be used in the **user=username** format in the connection string.
@@ -86,7 +86,7 @@ The preceding numbers give you an approximation of the time taken to complete th
 
 We recommend a powerful SKU for the target because the PostgreSQL migration service runs out of a container on the flexible server. A powerful SKU enables more tables to be migrated in parallel. You can scale the SKU back to your preferred configuration after the migration. This section contains steps to improve the migration speed if the data distribution among the tables needs to be more balanced or a more powerful SKU doesn't significantly affect the migration speed.
 
-If the data distribution on the source is highly skewed, with most of the data present in one table, the allocated compute for migration needs to be fully utilized, which creates a bottleneck. So, split large tables into smaller chunks, which are then migrated in parallel. This feature applies to tables with more than 10,000,000 (10 m) tuples. Splitting the table into smaller chunks is possible if one of the following conditions is satisfied:
+If the data distribution on the source is highly skewed, with most of the data present in one table, the allocated compute for migration needs to be fully utilized, which creates a bottleneck. So, split large tables into smaller chunks, which are then migrated in parallel. This feature applies to tables with more than 1,000,000 (1 m) tuples. Splitting the table into smaller chunks is possible if one of the following conditions is satisfied:
 
 - The table must have a column with a simple (not composite) primary key or unique index of type `int` or `significant int`.
 
@@ -110,12 +110,12 @@ If any of the preceding conditions are satisfied, the table is migrated in multi
 #### How it works
 
 - The migration service looks up the maximum and minimum integer value of the table's primary key/unique index that must be split up and migrated in parallel.
-- If the difference between the minimum and maximum value is more than 10,000,000 (10 m), the table is split into multiple parts and each part is migrated in parallel.
+- If the difference between the minimum and maximum value is more than 1,000,000 (1 m), the table is split into multiple parts and each part is migrated in parallel.
 
 In summary, the PostgreSQL migration service migrates a table in parallel threads and reduces the migration time if:
 
 - The table has a column with a simple primary key or unique index of type int or significant int.
-- The table has at least 10,000,000 (10 m) rows so that the difference between the minimum and maximum value of the primary key is more than 10,000,000 (10 m).
+- The table has at least 1,000,000 (1 m) rows so that the difference between the minimum and maximum value of the primary key is more than 1,000,000 (1 m).
 - The SKU used has idle cores, which can be used for migrating the table in parallel.
 
 ## Vacuum bloat in the PostgreSQL database