PR review: Update wording and grammar in gateway migration doc

Implement Acrolinx suggestions to raise file's overall Acrolinx score to at least 80.

Author: AnnaMHuff

articles/expressroute/gateway-migration.md

@@ -31,29 +31,29 @@ The ErGw1Az, ErGw2Az, ErGw3Az, and ErGwScale (Preview) SKUs, also known as Az-En
 
 The Standard, HighPerformance, and UltraPerformance SKUs, which are also known as nonavailability zone enabled SKUs are historically associated with Basic IPs, don't support the distribution of the gateway across multiple availability zones.  
 
-For enhanced reliability, it's recommended to use an Availability-Zone Enabled virtual network gateway SKU. These SKUs support a zone-redundant setup and are, by default, associated with Standard IPs. This setup ensures that even if one zone experiences an issue, the virtual network gateway infrastructure remains operational due to the distribution across multiple zones. For a deeper understanding of zone redundant gateways, please refer to [Availability Zone deployments.](../reliability/availability-zones-overview.md)
+For enhanced reliability, we recommend using an Availability-Zone Enabled virtual network gateway SKU. These SKUs support a zone-redundant setup and are, by default, associated with Standard IPs. This setup ensures that even if one zone experiences an issue, the virtual network gateway infrastructure remains operational due to the distribution across multiple zones. For a deeper understanding of zone redundant gateways, refer to [Availability Zone deployments.](../reliability/availability-zones-overview.md)
 
 ## Gateway migration experience
 
 Historically, users had to use the Resize-AzVirtualNetworkGateway PowerShell command or delete and recreate the virtual network gateway to migrate between SKUs.
 
 With the guided gateway migration experience you can deploy a second virtual network gateway in the same GatewaySubnet and Azure automatically transfers the control plane and data path configuration from the old gateway to the new one. During the migration process, there will be two virtual network gateways in operation within the same GatewaySubnet. This feature is designed to support migrations without disruption. However, users may experience brief connectivity issues or interruptions during the migration process.
 
-After completing the gateway migration and deleting the older gateway and its connections, the newly created gateway will be tagged with "CreatedBy : GatewaySKUMigration". This tag will serve as a key differentiator from your other gateways that have not been migrated and should not be deleted.
+After completing the gateway migration and deleting the older gateway and its connections, the newly created gateway will be tagged with "CreatedBy : GatewaySKUMigration". This tag serves as a key differentiator from your other gateways that haven't been migrated and shouldn't be deleted.
 
 
 ### Steps to migrate to a new gateway
 
 1. **Validate**: Ensure all resources are in a succeeded state to confirm the gateway is ready for migration. If prerequisites aren't met, validation fails, and you can't proceed.
-2. **Prepare**: Create a new Virtual Network gateway, Public IP, and connections. This operation can take up to 45 minutes. You can choose a preferred name for the new gateway and connections. If you don't change the name, the tag **_migrate** will be appended by default. During this process, the existing Virtual Network gateway will be locked, preventing any crgeation or modification of connections.
+2. **Prepare**: Create a new Virtual Network gateway, Public IP, and connections. This operation can take up to 45 minutes. You can choose a preferred name for the new gateway and connections. If you don't change the name, the tag **_migrate** is appended by default. During this process, the existing Virtual Network gateway is locked, preventing any creation or modification of connections.
 3. **Migrate**: Select the new gateway to transfer traffic from the old gateway to the new one. This operation can take up to 15 minutes and may cause brief interruptions.
 4. **Commit**: Finalize the migration by deleting the old gateway and connections.
 
 > [!IMPORTANT]
 > After migration, validate your connectivity to ensure everything is functioning as expected. You can revert to the old gateway by selecting **Abort** after the prepare step, which will delete the new gateway and connections.
 
 
-| Migrate from Non-Az enabled Gateway SKU     | Migrate to Az-enabled Gateway SKU              |
+| Migrate from Non-Az-enabled Gateway SKU     | Migrate to Az-enabled Gateway SKU              |
 |---------------------------------------------|------------------------------------------------|
 | Standard, HighPerformance, UltraPerformance | ErGw1Az, ErGw2Az, ErGw3Az, ErGwScale (Preview) |
 | Basic IP                                    | Standard IP                                    |
@@ -64,11 +64,11 @@ After completing the gateway migration and deleting the older gateway and its co
 
 The guided gateway migration experience supports:
 
-* Non-Az-enabled SKU on Basic IP to Non-az enabled SKU on Standard IP.
+* Non-Az-enabled SKU on Basic IP to Non-az-enabled SKU on Standard IP.
 * Non-Az-enabled SKU on Basic IP to Az-enabled SKU on Standard IP.
 * Non-Az-enabled SKU on Standard IP to Az-enabled SKU on Standard IP.
 
-It's recommended to migrate to an Az-enabled SKU for enhanced reliability and high availability. To learn more, see [Migrate to an availability zone-enabled ExpressRoute virtual network gateway using PowerShell](expressroute-howto-gateway-migration-powershell.md).
+We recommend migrating to an Az-enabled SKU for enhanced reliability and high availability. To learn more, see [Migrate to an availability zone-enabled ExpressRoute virtual network gateway using PowerShell](expressroute-howto-gateway-migration-powershell.md).
 
 ### Limitations