updating gateway docs

MekaylaMoore · MekaylaMoore · commit fc911cdf5ad0 · 2025-05-27T15:06:06.000-07:00
diff --git a/articles/expressroute/gateway-migration.md b/articles/expressroute/gateway-migration.md
@@ -12,56 +12,60 @@ ms.author: duau
 ---
 
 # About ExpressRoute Gateway Migration
-This article explains the ExpressRoute gateway migration process, enabling you to move from non-Availability Zone (non-Az)-enabled SKUs to Az-enabled SKUs, and from Basic IP to Standard IP. Migrating to Az-enabled SKUs and Standard IPs improves the reliability and high availability of your ExpressRoute virtual network gateways.
-
-## Supported Migration Scenarios
 
-### Using Azure portal and Azure PowerShell
+This article explains the ExpressRoute gateway migration process, enabling you to move from non-Availability Zone (non-Az)-enabled SKUs to Az-enabled SKUs, and from Basic IP to Standard IP. Migrating to Az-enabled SKUs and Standard IPs improves the reliability and high availability of your ExpressRoute virtual network gateways.
 
-The guided gateway migration experience supports the following scenarios:
+For guidance on upgrading Basic SKU public IP addresses for other networking services, see [Upgrading Basic to Standard SKU](../virtual-network/ip-services/public-ip-basic-upgrade-guidance.md#steps-to-complete-the-upgrade).
 
-- Migrating from a non-Az-enabled SKU with a Basic IP to a non-Az-enabled SKU with a Standard IP.
-- Migrating from a non-Az-enabled SKU with a Basic IP to an Az-enabled SKU with a Standard IP.
-
-For enhanced reliability and high availability, we recommend migrating to an Az-enabled SKU. For detailed steps, see [Migrate to an availability zone-enabled ExpressRoute virtual network gateway using PowerShell](expressroute-howto-gateway-migration-powershell.md).
->[!Important]
+> [!IMPORTANT]
 >On September 30, 2025, Basic SKU public IPs will be retired. For more information, see the [official announcement](https://azure.microsoft.com/updates/upgrade-to-standard-sku-public-ip-addresses-in-azure-by-30-september-2025-basic-sku-will-be-retired/). If you are currently using Basic SKU public IPs, make sure to upgrade to Standard SKU public IPs prior to the retirement date. 
 
-### Limitations
+## Gateway SKUs
+The **ErGw1Az**, **ErGw2Az**, **ErGw3Az**, and **ErGwScale** (Preview) SKUs are known as Availability Zone (Az)-enabled SKUs. These SKUs allow deployment across multiple availability zones, increasing resiliency and high availability by distributing gateway resources across zones.
 
-The guided gateway migration experience has the following limitations:
-
-- **ExpressRoute Only**: The migration tool is designed for **ExpressRoute virtual network gateways**. It does **not** support VPN gateways or other gateway types.
--**Same Virtual Network Requirement**: Migration is only supported within the same **virtual network**. Cross-subscription, cross-region, or cross-gateway-type migrations (for example, to/from VPN gateways) aren't supported.
-- **No Downgrades**: Downgrading from an **Az-enabled SKU** to a **non-Az-enabled SKU** is **not** supported.
-- **GatewaySubnet Size**: The GatewaySubnet must have a /27 prefix or longer to proceed with migration. For more information, see [Create multiple prefixes for a subnet](../virtual-network/virtual-network-manage-subnet.md) for more information.
-- **Private Endpoint Connectivity**: Private endpoints (PEs) connected via ExpressRoute private peering may experience **connectivity issues** during migration. Refer to guidance on mitigating these issues in the Private endpoint connectivity documentation. [Private endpoint connectivity](expressroute-about-virtual-network-gateways.md#private-endpoint-connectivity-and-planned-maintenance-events).
-- **Legacy Gateways**: ExpressRoute gateways created or connected to circuits in **2017 or earlier** aren't supported.
-- **Unsupported SKUs**: Gateways using the **"default" SKU** aren't eligible for migration. To check the migration eligibility of your Gateway, there should be an Advisor notification.
-
-For detailed troubleshooting errors and best practices, see [Troubleshooting Gateway Migration](gateway-migration-error-messaging.md).
+By comparison, the **Standard**, **HighPerformance**, and **UltraPerformance** SKUs are non-Az-enabled. They are typically used with Basic public IP addresses and do not support availability zone distribution.
 
 ## Gateway migration experience
 
 The gateway migration experience allows you to deploy a second virtual network gateway in the same GatewaySubnet. Azure migrates your configurations from the old gateway to the new one. Both gateways run simultaneously during migration, minimizing disruption – though brief connectivity interruptions may still occur.
 
 After migration, the old gateway and its connections are deleted, and the new gateway is tagged with **CreatedBy: GatewaySKUMigration** to identify it as a migrated resource and shouldn’t be deleted.
+## Supported Migration Scenarios
 
-### Steps to migrate to a new gateway
+The guided gateway migration experience supports the following scenarios:
+
+- Migrating from a non-Az-enabled SKU with a Basic IP to a non-Az-enabled SKU with a Standard IP.
+- Migrating from a non-Az-enabled SKU with a Basic IP to an Az-enabled SKU with a Standard IP.
+
+ Learn how to [migrate using the Azure portal](expressroute-howto-gateway-migration-portal.md).  
+Learn how to [migrate using PowerShell](expressroute-howto-gateway-migration-powershell.md).
+
+For enhanced reliability and high availability, we recommend migrating to an Az-enabled SKU.
+
+## Steps to migrate to a new gateway
 
 1. **Validate**: Check that all resources are in a succeeded state. If any prerequisites aren't met, validation fails and migration can't proceed.
-2. **Prepare**: Azure creates a new virtual network gateway, public IP, and connections. This step can take up to 45 minutes. You can specify a name for the new gateway, or Azure will add **_migrate** to the original name by default. During preparation, the existing gateway is locked to prevent changes. If you need to stop the migration, you can **abort** at this stage, which deletes the new gateway and connections.
+2. **Prepare**: Azure creates a new virtual network gateway, public IP, and connections. This step can take up to 45 minutes. You can specify a name for the new gateway, or Azure will add **_migrated** to the original name by default. During preparation, the existing gateway is locked to prevent changes. If you need to stop the migration, you can **abort** at this stage, which deletes the new gateway and connections.
     - **Note**: The new gateway is created in the same region as the existing one. To change regions, you must delete the current gateway and create a new one in the desired region.
 3. **Migrate**: Switch traffic from the old gateway to the new one. This step can take up to 15 minutes and may cause brief connectivity interruptions.
 4. **Commit**: Complete the migration by deleting the old gateway and its connections. If necessary, you can abort and revert to the old gateway before committing.
 
-
 > [!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.
 
-| Migration source (Non-Az-enabled gateway SKU) | Migration target (Az-enabled gateway SKU) |
-|--|--|
-| Basic IP | Standard IP |
+## Limitations
+
+The guided gateway migration experience has the following limitations:
+
+- **ExpressRoute Only**: The migration tool is designed for **ExpressRoute virtual network gateways**. It does **not** support VPN gateways or other gateway types.
+-**Same Virtual Network Requirement**: Migration is only supported within the same **virtual network**. Cross-subscription, cross-region, or cross-gateway-type migrations (for example, to/from VPN gateways) aren't supported.
+- **No Downgrades**: Downgrading from an **Az-enabled SKU** to a **non-Az-enabled SKU** is **not** supported.
+- **GatewaySubnet Size**: The GatewaySubnet must have a /27 prefix or longer to proceed with migration. For more information, see [Create multiple prefixes for a subnet](../virtual-network/virtual-network-manage-subnet.md) for more information.
+- **Private Endpoint Connectivity**: Private endpoints (PEs) connected via ExpressRoute private peering may experience **connectivity issues** during migration. Refer to guidance on mitigating these issues in the Private endpoint connectivity documentation. [Private endpoint connectivity](expressroute-about-virtual-network-gateways.md#private-endpoint-connectivity-and-planned-maintenance-events).
+- **Legacy Gateways**: ExpressRoute gateways created or connected to circuits in **2017 or earlier** aren't supported.
+- **Unsupported SKUs**: Gateways using the **"default" SKU** aren't eligible for migration. To check the migration eligibility of your Gateway, there should be an Advisor notification.
+
+For detailed troubleshooting errors and best practices, see [Troubleshooting Gateway Migration](gateway-migration-error-messaging.md).
 
 ## FAQ
 
@@ -85,10 +89,8 @@ You have up to 15 days to commit after migration preparation. Use this time to v
 
 Azure Advisor notifications will alert you if your gateway requires migration. Attempting to migrate an ineligible gateway will result in an error. For more details, see [Troubleshooting Gateway Migration](gateway-migration-error-messaging.md).
 
-
 ## Next Steps
 
 - Troubleshoot migration  issues with [Troubleshooting Gateway Migration](gateway-migration-error-messaging.md).
 - Learn how to [migrate using the Azure portal](expressroute-howto-gateway-migration-portal.md).
-- Learn how to [migrate using PowerShell](expressroute-howto-gateway-migration-powershell.md).
-- Explore best practices for [designing for high availability](designing-for-high-availability-with-expressroute.md).
+- Learn how to [migrate using PowerShell](expressroute-howto-gateway-migration-powershell.md).
