review with Aditya AWS Iaas and te rest of the files exept single server

Author: markingmyname

articles/postgresql/.openpublishing.redirection.postgresql.json

@@ -1629,6 +1629,11 @@
         "source_path_from_root": "/articles/postgresql/migrate/migration-service/tutorial-migration-service-iaas.md",
         "redirect_url": "/azure/postgresql/migrate/migration-service/tutorial-migration-service-iaas-offline",
         "redirect_document_id": true
+    },
+    {
+        "source_path_from_root": "/articles/postgresql/migrate/migration-service/concepts-migration-service-postgresql.md",
+        "redirect_url": "/azure/postgresql/migrate/migration-service/overview-migration-service-postgresql",
+        "redirect_document_id": true
     }
     ]
 }

articles/postgresql/TOC.yml

@@ -574,7 +574,7 @@
         href: migrate/migration-service/how-to-network-setup-migration-service.md
     - name: Troubleshoot
       items:
-      - name: Premigration error codes
+      - name: Known errors
         href: migrate/migration-service/troubleshoot-error-codes-premigration.md
   - name: Migrate data with pg_dump
     href: migrate/how-to-migrate-using-dump-and-restore.md

articles/postgresql/migrate/migration-service/concepts-known-issues-migration-service.md

@@ -53,6 +53,8 @@ Here are common limitations that apply to migration scenarios:
 
 - Migration to burstable SKUs isn't supported; databases must first be migrated to a non-burstable SKU and then scaled down if needed.
 
+- The Migration Runtime Server is specifically designed to operate with the default DNS servers/private DNS zones i.e., **privatelink.postgres.database.azure.com**. Custom DNS names/DNS servers are not supported by the migration service when utilizing the migration runtime server feature. When configuring private endpoints for both the source and target databases, it is imperative to use the default private DNS zone provided by Azure for the private link service. The use of custom DNS configurations is not yet supported and may lead to connectivity issues during the migration process.
+
 ## Limitations migrating from Azure Database for PostgreSQL single server
 
 - It's required that both the Azure Database for PostgreSQL single server and the Azure Database for PostgreSQL flexible server are in the same Azure region. Exceptions to this limitation are made for Azure Database for PostgreSQL flexible server situated in India, China, and UAE, where cross-region migrations are permitted.

articles/postgresql/migrate/migration-service/concepts-migration-service-runtime-server.md

@@ -30,7 +30,7 @@ The migration runtime server is essential for transferring data between differen
 
 To use the Migration Runtime Server feature within the migration service in Azure Database for PostgreSQL, follow these steps in the Azure portal:
 
-- Sign in to the Azure portal and access the migration service in the Azure Database for PostgreSQL.
+- Sign in to the Azure portal and access the migration service (from the target server) in the Azure Database for PostgreSQL instance.
 - Begin a new migration workflow within the service.
 - When you reach the "Select runtime server" tab, use the Migration Runtime Server by selecting "Yes."
 Choose your Azure subscription and resource group and the location of the VNet-integrated Azure Database for PostgreSQL—Flexible server.

articles/postgresql/migrate/migration-service/how-to-network-setup-migration-service.md

@@ -27,9 +27,9 @@ The table below summarizes the scenarios for connecting a source database to an
 | PostgreSQL installed Azure VM in same/different virtual network | VNet-integrated Azure Database for PostgreSQL - Flexible Server in same/different virtual network | Yes |
 | Azure Database for PostgreSQL - Single Server with public access | VNet-integrated Azure Database for PostgreSQL - Flexible Server | Yes |
 | Azure Database for PostgreSQL - Single Server with private endpoint | VNet-integrated Azure Database for PostgreSQL - Flexible Server | Yes |
-| Azure Database for PostgreSQL - Single Server with private endpoint | Azure Database for PostgreSQL - Flexible Server with private endpoint | Planned for future release |
-| On-premises/Azure VM/AWS with private access | Azure Database for PostgreSQL - Flexible Server with private endpoint | Planned for future release |
-| On-premises/Azure VM/AWS with private access | Azure Database for PostgreSQL - Flexible Server with public access | Planned for future release |
+| Azure Database for PostgreSQL - Single Server with private endpoint | Azure Database for PostgreSQL - Flexible Server with private endpoint | Yes |
+| On-premises/Azure VM/AWS with private access | Azure Database for PostgreSQL - Flexible Server with private endpoint | Yes |
+| On-premises/Azure VM/AWS with private access | Azure Database for PostgreSQL - Flexible Server with public access | No |
 
 ## Scenario 1: On-premises source to Azure Database for PostgreSQL with public access
 
@@ -212,17 +212,6 @@ Below are the networking steps for migrating a PostgreSQL database from an on-pr
     - Attach a private DNS zone to the Flexible Server's private endpoint if not already configured.
     - Add virtual network links for the Flexible Server and Migration Runtime Server to the private DNS zone.
 
-## Scenario 10: Custom private DNS Zone attached to the private endpoint
-
-This scenario addresses the networking challenge when migrating databases to Azure PostgreSQL, which requires using Azure's default private DNS zone. Custom DNS configurations are incompatible with the Migration Runtime Server, necessitating the temporary use of Azure's default private DNS zone.
-
-- Check if the source and target databases use custom DNS zones with private endpoints.
-- For both the source and target databases, set up new private endpoints that are linked to Azure's default private DNS zone.
-- Connect the new private endpoints to the **privatelink.postgres.database.azure.com** DNS zone for proper name resolution.
-- Ensure the Migration Runtime Server can resolve and communicate with both databases using the new private endpoints.
-- Carry out the database migration through the secondary endpoints that use the default private DNS zone.
-- Remove the secondary private endpoints after successful migration and restore any custom DNS configurations if needed.
-
 ## Resources for network setup
 
 - To establish an **ExpressRoute** connection, refer to the [What is Azure ExpressRoute?](../../../expressroute/expressroute-introduction.md).

articles/postgresql/migrate/migration-service/how-to-setup-azure-cli-commands-postgresql.md

@@ -84,6 +84,25 @@ If the cutover isn't successful, the migration moves to the `Failed` state.
 
 For more information about this command, use the `help` parameter.
 
+## Cancel the migration
+
+To cancel the migration task, use the following command:
+
+```azurecli
+az postgres flexible-server migration update cancel [--subscription]
+                                            [--resource-group]
+                                            [--name]
+                                            [--migration-name]
+```
+
+## The --help command
+
+For more information about this command, use the `help` parameter:
+
+```azurecli-interactive
+az postgres flexible-server migration update cancel -- help
+```
+
 ## Related content
 
 - [Migration service in Azure Database for PostgreSQL](concepts-migration-service-postgresql.md)

articles/postgresql/migrate/migration-service/includes/aws/prerequisites-migration-service-postgresql-offline-aws.md

@@ -33,34 +33,9 @@ The SKU chosen for the Azure Database for PostgreSQL should correspond with the
 
 ### Configure network setup
 
-Proper networking setup is essential to ensure successful migration connectivity between the source and target. Here's a guide to help you establish the network connection for different scenarios:
+Network setup is crucial for the migration service to function correctly. Ensure that the source PostgreSQL server can communicate with the target Azure Database for PostgreSQL server. The following network configurations are essential for a successful migration.
 
-- **Networking requirements for migration:**
-
-  - **ExpressRoute/IPsec VPN/VPN tunneling**: When connecting your on-premises/AWS source to Azure, you might need to set up an ExpressRoute, IPsec VPN, or VPN tunneling to facilitate secure data transfer.
-
-  - **VNET peering**: Establish virtual network peering between the two distinct VNets to enable direct network connectivity, a prerequisite for migration between the Azure VM and the Azure Database for PostgreSQL.
-
-- **Connectivity Scenarios:**
-
-The following table can help set up the network between the source and target.
-
-| Source | Target | Connectivity Tips |
-| --- | --- | --- |
-| Public | Public | No other action is required if the source is whitelisted in the target's firewall rules. |
-| Private | Public | This configuration isn't supported; use pg_dump/pg_restore for data transfer. |
-| Public | Private | No other action is required if the source is whitelisted in the target's firewall rules. |
-| Private | Private | Establish an ExpressRoute, IPsec VPN, VPN Tunneling, or virtual network Peering between the source and target. |
-| Private | Private Endpoint | This configuration isn't supported; contact [Microsoft support](https://support.microsoft.com/en-US). |
-
-- **Additional networking considerations:**
-
-pg_hba.conf Configuration: To facilitate connectivity between the source and target PostgreSQL instances, it's essential to verify and potentially modify the pg_hba.conf file. This file includes client authentication and must be configured to allow the target PostgreSQL to connect to the source. Changes to the pg_hba.conf file typically require a restart of the source PostgreSQL instance to take effect.
-
-> [!NOTE]  
-> The pg_hba.conf file is located in the data directory of the PostgreSQL installation. This file should be checked and configured if the source database is an on-premises PostgreSQL server or a PostgreSQL server hosted on an Azure VM. For PostgreSQL instances on AWS RDS or similar managed services, the pg_hba.conf file is not directly accessible or applicable. Instead, access is controlled through the service's security and network access configurations.
-
-For more information about network setup, visit [Network guide for migration service](../../how-to-network-setup-migration-service.md).
+For information about network setup, visit [Network guide for migration service](../../how-to-network-setup-migration-service.md).
 
 ### Enable extensions
 

articles/postgresql/migrate/migration-service/includes/aws/prerequisites-migration-service-postgresql-online-aws.md

@@ -49,11 +49,9 @@ If the source PostgreSQL version is less than 9.5, upgrade it to 9.5 or higher b
 
 ### Configure network setup
 
-Networking is required to establish a successful connectivity between the source and target.
+Network setup is crucial for the migration service to function correctly. Ensure that the source PostgreSQL server can communicate with the target Azure Database for PostgreSQL server. The following network configurations are essential for a successful migration.
 
-- You need to set up Express route/ IP Sec VPN/ VPN tunneling while connecting your source from AWS RDS to Azure.
-
-For more information on network setup, visit [Network guide for migration service](../../how-to-network-setup-migration-service.md)
+For information about network setup, visit [Network guide for migration service](../../how-to-network-setup-migration-service.md).
 
 ### Enable extensions
 
@@ -76,9 +74,28 @@ If yes, search the server parameters page for the shared_preload_libraries param
 
 ### Check server parameters
 
-- You need to manually configure the server parameter values in the Azure Database for PostgreSQL – Flexible server based on the server parameter values configured in the source.
+These parameters aren't automatically migrated to the target environment and must be manually configured.
+
+- Match server parameter values from the source PostgreSQL database to the Azure Database for PostgreSQL by accessing the "Server parameters" section in the Azure portal and manually updating the values accordingly.
+
+- Save the parameter changes and restart the Azure Database for PostgreSQL to apply the new configuration if necessary.
 
 ### Check users and roles
 
-- The users and different roles must be migrated manually to the Azure Database for PostgreSQL – Flexible server. For migrating users and roles, you can use `pg_dumpall --globals-only -U <<username> -f <<filename>>.sql`.
-- Azure Database for PostgreSQL – The flexible server doesn't support any superuser; users having roles of superuser need to be removed before migration.
+When migrating to Azure Database for PostgreSQL, it's essential to address the migration of users and roles separately, as they require manual intervention:
+
+- **Manual Migration of Users and Roles**: Users and their associated roles must be manually migrated to the Azure   Database for PostgreSQL. To facilitate this process, you can use the `pg_dumpall` utility with the `--globals-only` flag to export global objects such as roles and user accounts. Execute the following command, replacing `<<username>>` with the actual username and `<<filename>>` with your desired output file name:
+
+  ```sql
+  pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
+  ```
+
+- **Restriction on Superuser Roles**: Azure Database for PostgreSQL doesn't support superuser roles. Therefore, users with superuser privileges must have those privileges removed before migration. Ensure that you adjust the permissions and roles accordingly.
+
+By following these steps, you can ensure that user accounts and roles are correctly migrated to the Azure Database for PostgreSQL without encountering issues related to superuser restrictions.
+
+### Disable high availability (reliability) and read replicas in the target
+
+- Disabling high availability (reliability) and reading replicas in the target environment is essential. These features should be enabled only after the migration has been completed.
+
+- By following these guidelines, you can help ensure a smooth migration process without the added variables introduced by HA and Read Replicas. Once the migration is complete and the database is stable, you can proceed to enable these features to enhance the availability and scalability of your database environment in Azure.

articles/postgresql/migrate/migration-service/includes/iaas/prerequisites-migration-service-postgresql-offline-iaas.md

@@ -33,34 +33,15 @@ The SKU chosen for the Azure Database for PostgreSQL should correspond with the
 
 ### Configure network setup
 
-Proper networking setup is essential to ensure successful migration connectivity between the source and target. Here's a guide to help you establish the network connection for different scenarios:
+Network setup is crucial for the migration service to function correctly. Ensure that the source PostgreSQL server can communicate with the target Azure Database for PostgreSQL server. The following network configurations are essential for a successful migration.
 
-- **Networking requirements for migration:**
-
-  - **ExpressRoute/IPsec VPN/VPN tunneling**: When connecting your on-premises/AWS source to Azure, you might need to set up an ExpressRoute, IPsec VPN, or VPN tunneling to facilitate secure data transfer.
-
-  - **VNET peering**: Establish virtual network peering between the two distinct VNets to enable direct network connectivity, a prerequisite for migration between the Azure VM and the Azure Database for PostgreSQL.
-
-- **Connectivity Scenarios:**
-
-The following table can help set up the network between the source and target.
-
-| Source | Target | Connectivity Tips |
-| --- | --- | --- |
-| Public | Public | No other action is required if the source is whitelisted in the target's firewall rules. |
-| Private | Public | This configuration isn't supported; use pg_dump/pg_restore for data transfer. |
-| Public | Private | No other action is required if the source is whitelisted in the target's firewall rules. |
-| Private | Private | Establish an ExpressRoute, IPsec VPN, VPN Tunneling, or virtual network Peering between the source and target. |
-| Private | Private Endpoint | This configuration isn't supported; contact [Microsoft support](https://support.microsoft.com/en-US). |
+For information about network setup, visit [Network guide for migration service](../../how-to-network-setup-migration-service.md).
 
 - **Additional networking considerations:**
 
 pg_hba.conf Configuration: To facilitate connectivity between the source and target PostgreSQL instances, it's essential to verify and potentially modify the pg_hba.conf file. This file includes client authentication and must be configured to allow the target PostgreSQL to connect to the source. Changes to the pg_hba.conf file typically require a restart of the source PostgreSQL instance to take effect.
 
-> [!NOTE]  
-> The pg_hba.conf file is located in the data directory of the PostgreSQL installation. This file should be checked and configured if the source database is an on-premises PostgreSQL server or a PostgreSQL server hosted on an Azure VM. For PostgreSQL instances on AWS RDS or similar managed services, the pg_hba.conf file is not directly accessible or applicable. Instead, access is controlled through the service's security and network access configurations.
-
-For more information about network setup, visit [Network guide for migration service](../../how-to-network-setup-migration-service.md).
+The pg_hba.conf file is located in the data directory of the PostgreSQL installation. This file should be checked and configured if the source database is an on-premises PostgreSQL server or a PostgreSQL server hosted on an Azure VM. 
 
 ### Enable extensions