Skip to content

Commit 4b0ec17

Browse files
duongauduongau
committed
review
1 parent 5355f3c commit 4b0ec17

File tree

1 file changed

+49
-47
lines changed

1 file changed

+49
-47
lines changed

‎articles/expressroute/gateway-migration.md

Lines changed: 49 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -7,88 +7,90 @@ author: duongau
77
ms.service: azure-expressroute
88
ms.custom: ignite-2023
99
ms.topic: concept-article
10-
ms.date: 04/26/2024
10+
ms.date: 03/31/2025
1111
ms.author: duau
1212
---
1313

1414
# About migrating to an availability zone-enabled ExpressRoute virtual network gateway
15+
When creating an ExpressRoute virtual network gateway, selecting the appropriate [gateway SKU](expressroute-about-virtual-network-gateways.md#gateway-types) is crucial. Higher-level SKUs allocate more CPUs and network bandwidth to the gateway, enabling higher network throughput and more reliable connections to the virtual network.
1516

16-
When you create an ExpressRoute virtual network gateway, you need to choose the [gateway SKU](expressroute-about-virtual-network-gateways.md#gateway-types). If you choose a higher-level SKU, more CPUs and network bandwidth are allocated to the gateway. As a result, the gateway can support higher network throughput and more dependable network connections to the virtual network.
17+
### Available SKUs for ExpressRoute Virtual Network Gateways
1718

18-
The following SKUs are available for ExpressRoute virtual network gateways:
19+
The following SKUs are available:
1920

20-
* Standard
21-
* HighPerformance
22-
* UltraPerformance
23-
* ErGw1Az
24-
* ErGw2Az
25-
* ErGw3Az
26-
* ErGwScale (Preview)
21+
- **Standard**
22+
- **HighPerformance**
23+
- **UltraPerformance**
24+
- **ErGw1Az**
25+
- **ErGw2Az**
26+
- **ErGw3Az**
27+
- **ErGwScale** (Preview)
2728

28-
## Availability zone enabled SKUs
29+
### Availability Zone-Enabled SKUs
2930

30-
The ErGw1Az, ErGw2Az, ErGw3Az, and ErGwScale (Preview) SKUs, also known as Az-Enabled SKUs, support Availability zone deployments. This feature provides high availability and resiliency to the gateway by distributing the gateway across multiple availability zones.
31+
The SKUs **ErGw1Az**, **ErGw2Az**, **ErGw3Az**, and **ErGwScale** (Preview) are referred to as Availability Zone (Az)-Enabled SKUs. These SKUs support deployment across multiple availability zones, providing enhanced resiliency and high availability by distributing the gateway infrastructure across zones.
3132

32-
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.
33+
In contrast, the **Standard**, **HighPerformance**, and **UltraPerformance** SKUs, also known as non-Az-enabled SKUs, are typically associated with Basic IPs and do not support distribution across availability zones.
3334

34-
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)
35+
### Recommendation for enhanced reliability
36+
37+
For improved reliability, we recommend using an Az-enabled virtual network gateway SKU. These SKUs support zone-redundant configurations and are associated with Standard IPs by default. A zone-redundant setup ensures that the gateway infrastructure remains operational even if one availability zone encounters an issue. To learn more about zone-redundant gateways, see [Availability Zone deployments](../reliability/availability-zones-overview.md).
3538

3639
## Gateway migration experience
3740

38-
Historically, users had to use the Resize-AzVirtualNetworkGateway PowerShell command or delete and recreate the virtual network gateway to migrate between SKUs.
41+
Previously, migrating between SKUs required using the `Resize-AzVirtualNetworkGateway` PowerShell command or manually deleting and recreating the virtual network gateway.
3942

40-
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.
43+
The guided gateway migration experience simplifies this process by allowing you to deploy a second virtual network gateway within the same GatewaySubnet. Azure automatically transfers the control plane and data path configurations from the old gateway to the new one. During the migration, both gateways operate simultaneously within the same GatewaySubnet. While this feature minimizes disruption, brief connectivity interruptions may still occur.
4144

42-
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.
45+
Once the migration is complete and the old gateway along with its connections are deleted, the newly created gateway will be tagged with `"CreatedBy : GatewaySKUMigration"`. This tag helps distinguish migrated gateways from others that haven't undergone migration and should not be deleted.
4346

4447

45-
### Steps to migrate to a new gateway
48+
### Steps to Migrate to a New Gateway
4649

47-
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.
48-
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.
49-
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.
50-
4. **Commit**: Finalize the migration by deleting the old gateway and connections.
50+
1. **Validate**: Confirm that all resources are in a succeeded state to ensure the gateway is ready for migration. If prerequisites are not met, the validation process will fail, and migration cannot proceed.
51+
2. **Prepare**: Create a new virtual network gateway, public IP, and connections. This step can take up to 45 minutes. You can specify a preferred name for the new gateway and connections. If no name is provided, the system appends the tag **_migrate** by default. During this step, the existing virtual network gateway is locked, preventing any creation or modification of connections.
52+
3. **Migrate**: Transfer traffic from the old gateway to the new one by selecting the new gateway. This operation may take up to 15 minutes and could result in brief connectivity interruptions.
53+
4. **Commit**: Finalize the migration by deleting the old gateway and its connections.
5154

5255
> [!IMPORTANT]
53-
> 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.
54-
56+
> After completing the migration, validate your connectivity to ensure everything is functioning as expected. If needed, you can revert to the old gateway by selecting **Abort** after the prepare step. This action will delete the new gateway and its connections.
5557
56-
| Migrate from Non-Az-enabled Gateway SKU | Migrate to Az-enabled Gateway SKU |
57-
|---------------------------------------------|------------------------------------------------|
58+
| Migration source (Non-Az-enabled gateway SKU) | Migration target (Az-enabled gateway SKU) |
59+
|--|--|
5860
| Standard, HighPerformance, UltraPerformance | ErGw1Az, ErGw2Az, ErGw3Az, ErGwScale (Preview) |
59-
| Basic IP | Standard IP |
61+
| Basic IP | Standard IP |
6062

61-
## Supported migration scenarios
63+
## Supported Migration Scenarios
6264

63-
### Azure portal & Azure PowerShell
65+
### Using Azure Portal and Azure PowerShell
6466

65-
The guided gateway migration experience supports:
67+
The guided gateway migration experience supports the following scenarios:
6668

67-
* Non-Az-enabled SKU on Basic IP to Non-az-enabled SKU on Standard IP.
68-
* Non-Az-enabled SKU on Basic IP to Az-enabled SKU on Standard IP.
69-
* Non-Az-enabled SKU on Standard IP to Az-enabled SKU on Standard IP.
69+
- Migrating from a non-Az-enabled SKU with a Basic IP to a non-Az-enabled SKU with a Standard IP.
70+
- Migrating from a non-Az-enabled SKU with a Basic IP to an Az-enabled SKU with a Standard IP.
71+
- Migrating from a non-Az-enabled SKU with a Standard IP to an Az-enabled SKU with a Standard IP.
7072

71-
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).
73+
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).
7274

7375
### Limitations
7476

75-
The guided gateway migration experience doesn't support downgrade scenarios, Az-enabled Gateway SKU to non-Az-enabled Gateway SKU.
76-
77-
To proceed with migration, a /27 prefix or longer is required in the GatewaySubnet.
77+
The guided gateway migration experience has the following limitations:
7878

79-
Private endpoints (PEs) in the virtual network, connected over ExpressRoute private peering, might have connectivity problems during the migration. To understand and reduce this issue, see [Private endpoint connectivity](expressroute-about-virtual-network-gateways.md#private-endpoint-connectivity-and-planned-maintenance-events).
79+
- Downgrade scenarios, such as migrating from an Az-enabled SKU to a non-Az-enabled SKU, are not supported.
80+
- The GatewaySubnet must have a prefix of /27 or longer to proceed with the migration.
81+
- Private endpoints (PEs) in the virtual network connected via ExpressRoute private peering may experience connectivity issues during migration. For guidance on mitigating these issues, see [Private endpoint connectivity](expressroute-about-virtual-network-gateways.md#private-endpoint-connectivity-and-planned-maintenance-events).
8082

81-
## Common validation errors
83+
## Common Validation Errors
8284

83-
In the gateway migration experience, you need to validate if your resource is capable of migration. Here are some Common migration errors:
85+
During the gateway migration process, it is essential to validate whether your resources are ready for migration. Below are some common validation errors you may encounter:
8486

85-
### Virtual network
87+
### Virtual Network
8688

87-
MaxGatewayCountInVnetReached – Reached maximum number of gateways that can be created in a Virtual Network.
89+
- **MaxGatewayCountInVnetReached**: This error indicates that the maximum number of gateways allowed in the virtual network has been reached.
8890

89-
## Next steps
91+
## Next Steps
9092

91-
* Learn how to [Migrate using the Azure portal](expressroute-howto-gateway-migration-portal.md).
92-
* Learn how to [Migrate using PowerShell](expressroute-howto-gateway-migration-powershell.md).
93-
* Learn more about [Designing for high availability](designing-for-high-availability-with-expressroute.md).
94-
* Plan for [Disaster recovery](designing-for-disaster-recovery-with-expressroute-privatepeering.md) and [using VPN as a backup](use-s2s-vpn-as-backup-for-expressroute-privatepeering.md).
93+
- Learn how to [migrate using the Azure portal](expressroute-howto-gateway-migration-portal.md).
94+
- Learn how to [migrate using PowerShell](expressroute-howto-gateway-migration-powershell.md).
95+
- Explore best practices for [designing for high availability](designing-for-high-availability-with-expressroute.md).
96+
- Plan for [disaster recovery](designing-for-disaster-recovery-with-expressroute-privatepeering.md) and [using VPN as a backup](use-s2s-vpn-as-backup-for-expressroute-privatepeering.md).

0 commit comments

Comments
 (0)