fix(rdb): review hugo

Author: ldecarvalho-doc

pages/managed-databases-for-postgresql-and-mysql/how-to/upgrade-version.mdx

@@ -34,11 +34,11 @@ The version upgrade is only available for:
 
 ## How to remove incompatible data types
 
-Before upgrading to a newer major PostgreSQL version, you must remove any data types incompatible with `pg_upgrade`.
+Before upgrading to a newer major PostgreSQL version, you must remove any data types incompatible with the `pg_upgrade` tool.
 
 The `reg*` data type, for example, cannot be persisted by `pg_upgrade`.
 
-Run the following command in your Database Instance to remove all instances of the `reg*` data type:
+Run the following command in your Database Instance to identify all instances of the `reg*` data type:
 
 ```sql
 SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a
@@ -54,6 +54,8 @@ SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalo
       AND n.nspname NOT IN ('pg_catalog', 'information_schema'); 
 ```
 
+We recommend you remove the identified instances before continuing.
+
 ## How to upgrade the engine version
 
 1. Click **PostgreSQL and MySQL** under **Managed Databases** on the side menu. A list of your Database Instances displays.
@@ -67,19 +69,19 @@ SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalo
     <Message type="important">
       When you upgrade to a new version:
         - There is no synchronization between the source and target Database Instances. To avoid data loss, we recommend you stop any write operations running on your applications during the upgrade. If you let them run during the process, the data will be stored only in the source Database Instance.
-        - Your Database Instances in [High Availability (HA)](/managed-databases-for-postgresql-and-mysql/concepts/#high-availability) mode will migrate to a standalone Instance. To maintain your HA mode, you must manually [enable HA](/managed-databases-for-postgresql-and-mysql/how-to/enable-high-availability) after the upgrade is complete.
+        - Your Database Instances in [High Availability (HA)](/managed-databases-for-postgresql-and-mysql/concepts/#high-availability) mode will migrate to a standalone Instance. To maintain your HA mode, you must manually [enable HA](/managed-databases-for-postgresql-and-mysql/how-to/enable-high-availability) after the upgrade is complete. The same applies when upgrading [Read Replicas](/managed-databases-for-postgresql-and-mysql/how-to/create-read-replica).
         - Database Instance [advanced settings](/managed-databases-for-postgresql-and-mysql/how-to/configure-advanced-settings) are synced as long as they are still available on the new database engine version.
     </Message>
 
     <Message type="tip">
-      Follow the [migrating endpoints via the CLI](/managed-databases-for-postgresql-and-mysql/api-cli/migrating-endpoints/) procedure to quickly migrate your endpoints. Before doing so, we recommend running a dry-run of the Database Instance upgrade to validate the process.<br /><br />
-      You can use the same CLI command to revert the endpoint migration anytime. <br /><br />
-      Keep in mind that reverting the endpoint will not affect the data stored on the databases. This means that if some entries were added to the upgraded database, they will not be added back to the old version when you change the endpoints.
+      Before performing an engine upgrade migration, we recommend testing the process in a "dry-run". This allows you to estimate the migration time and verify its success without affecting your source instance. To do so:
+        - Run the migration without checking the "migration endpoint" flag. This will simulate the migration process. If the test is successful, you can then proceed with the actual migration. Follow the [migrating endpoints via the CLI](/managed-databases-for-postgresql-and-mysql/api-cli/migrating-endpoints/) procedure to migrate your endpoints after the upgrade. You can use the same CLI command to revert the endpoint migration anytime.
+        - Keep in mind that reverting the endpoint will not affect the data stored on the databases. This means that if some entries were added to the upgraded database, they will not be added back to the old version when you change the endpoints.
     </Message>
 4. Click **Upgrade version**. A new Database Instance is created.
 
     <Message type="important">
-      - In PostgreSQL major upgrades, the `pgaudit` and `pg_stat_statements` [engine extensions](/managed-databases-for-postgresql-and-mysql/reference-content/postgresql-extensions) will be removed. You must reinstall these extensions once the upgrade is complete.
-      - If you are upgrading to PG16, we recommend you [reset your user passwords](/managed-databases-for-postgresql-and-mysql/how-to/add-users) from the console or using `psql`, [PostrgreSQL's CLI](https://docs.postgresql.fr/13/app-psql.html). You must create a new password that follows the **SCRAM-SHA-256** format. The previous versions' password format is no longer supported in PG16.
+      - In PostgreSQL major upgrades, the `pgaudit` and `pg_stat_statements` [engine extensions](/managed-databases-for-postgresql-and-mysql/reference-content/postgresql-extensions) will be removed. You must reinstall these extensions on each database they are installed once the upgrade is complete.
+      - If you are upgrading to PG16, we recommend you [reset your user passwords](/managed-databases-for-postgresql-and-mysql/how-to/add-users) from the console or using `psql`, [PostrgreSQL's CLI](https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-META-COMMAND-PASSWORD). PG16 uses the **SCRAM-SHA-256** format to store passwords. The previous versions' password format is no longer supported in PG16. You can re-save your passwords after the upgrade and they will be stored in the correct format automatically.
     </Message>