You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/expressroute/gateway-migration.md
+56-43Lines changed: 56 additions & 43 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,81 +7,94 @@ author: duongau
7
7
ms.service: azure-expressroute
8
8
ms.custom: ignite-2023
9
9
ms.topic: concept-article
10
-
ms.date: 03/31/2025
10
+
ms.date: 05/19/2025
11
11
ms.author: duau
12
12
---
13
13
14
-
# About migrating to an availability zone-enabled ExpressRoute virtual network gateway
15
-
When you create 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.
14
+
# About ExpressRoute Gateway Migration
16
15
17
-
### Availability Zone-Enabled SKUs
16
+
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.
18
17
19
-
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.
18
+
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).
20
19
21
-
In contrast, the **Standard**, **HighPerformance**, and **UltraPerformance** SKUs, also known as non-Az-enabled SKUs, are typically associated with Basic IPs and don't support distribution across availability zones.
22
-
23
-
>[!Important]
20
+
> [!IMPORTANT]
24
21
>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.
25
22
26
-
This article will help guide you through the migration process of a Non-Az Gateway with Basic SKU Public IP Address to Az-enabled Gateway with Standard SKU Public IP Address.
23
+
## Gateway SKUs
24
+
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.
27
25
28
-
For other Networking services with Basic SKU Public IP Address, see [Upgrading Basic to Standard SKU](../virtual-network/ip-services/public-ip-basic-upgrade-guidance.md#steps-to-complete-the-upgrade)
26
+
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.
29
27
30
-
### Recommendation for enhanced reliability
28
+
##Gateway migration experience
31
29
32
-
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).
30
+
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.
33
31
34
-
## Gateway migration experience
32
+
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.
33
+
34
+
## Supported migration scenarios
35
+
36
+
The guided gateway migration experience supports the following scenarios:
37
+
38
+
- Migrating from a non-Az-enabled SKU with a Basic IP to a non-Az-enabled SKU with a Standard IP.
39
+
- Migrating from a non-Az-enabled SKU with a Basic IP to an Az-enabled SKU with a Standard IP.
35
40
36
-
Previously, migrating between SKUs required using the `Resize-AzVirtualNetworkGateway` PowerShell command or manually deleting and recreating the virtual network gateway.
41
+
Learn how to [migrate using the Azure portal](expressroute-howto-gateway-migration-portal.md).
42
+
Learn how to [migrate using PowerShell](expressroute-howto-gateway-migration-powershell.md).
37
43
38
-
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 might still occur.
44
+
For enhanced reliability and high availability, we recommend migrating to an Az-enabled SKU.
39
45
40
-
Once the migration is complete and the old gateway along with its connections are deleted, the newly created gateway is tagged with `"CreatedBy : GatewaySKUMigration"`. This tag helps distinguish migrated gateways from others that haven't undergone migration and shouldn't be deleted.
46
+
## Steps to migrate to a new gateway
41
47
42
-
### Steps to migrate to a new gateway
48
+
1.**Validate**: Check that all resources are in a succeeded state. If any prerequisites aren't met, validation fails and migration can't proceed.
49
+
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.
50
+
51
+
> [!Note]
52
+
> 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.
43
53
44
-
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.
45
-
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 creation or modification of connections.
46
-
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.
47
-
4.**Commit**: Finalize the migration by deleting the old gateway and connections.
54
+
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.
55
+
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.
48
56
49
57
> [!IMPORTANT]
50
58
> 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.
The guided gateway migration experience has the following limitations:
58
63
59
-
### Using Azure portal and Azure PowerShell
64
+
-**ExpressRoute Only**: The migration tool is designed for **ExpressRoute virtual network gateways**. It does **not** support VPN gateways or other gateway types.
65
+
-**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.
66
+
-**No Downgrades**: Downgrading from an **Az-enabled SKU** to a **non-Az-enabled SKU** is **not** supported.
67
+
-**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.
68
+
-**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).
69
+
-**Legacy Gateways**: ExpressRoute gateways created or connected to circuits in **2017 or earlier** aren't supported.
70
+
-**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.
60
71
61
-
The guided gateway migration experience supports the following scenarios:
72
+
For detailed troubleshooting errors and best practices, see [Troubleshooting Gateway Migration](gateway-migration-error-messaging.md).
62
73
63
-
- Migrating from a non-Az-enabled SKU with a Basic IP to a non-Az-enabled SKU with a Standard IP.
64
-
- Migrating from a non-Az-enabled SKU with a Basic IP to an Az-enabled SKU with a Standard IP.
74
+
## FAQ
65
75
66
-
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).
76
+
### How do I add a second prefix to the GatewaySubnet?
67
77
68
-
### Limitations
78
+
Adding multiple prefixes to the GatewaySubnet is currently in Public Preview and supported only via PowerShell. For instructions, see [Create multiple prefixes for a subnet](../virtual-network/virtual-network-manage-subnet.md).
69
79
70
-
The guided gateway migration experience has the following limitations:
80
+
### How do I monitor the health of the new gateway?
81
+
82
+
Monitoring for the new gateway is the same as for the old gateway. The new gateway is a separate resource with its own metrics. During migration, you can also observe traffic patterns using the migration tool.
83
+
84
+
### Will migration cause downtime?
85
+
86
+
Migration may cause a few minutes of downtime. Plan to perform the migration during a maintenance window to minimize impact.
87
+
88
+
### How long can I wait before committing to the new gateway?
89
+
90
+
You have up to 15 days to commit after migration preparation. Use this time to validate connectivity and ensure all requirements are met before finalizing the migration.
71
91
72
-
- The migration tool is exclusively designed for ExpressRoute virtual network gateways. It does not support migration for VPN gateways or other gateway types.
73
-
- The migration tool only supports gateway migration within the same virtual network. It does not allow migration across different subscriptions, regions, or gateway types such as VPN gateways.
74
-
- Downgrade scenarios, such as migrating from an Az-enabled SKU to a non-Az-enabled SKU, aren't supported.
75
-
- The GatewaySubnet must have a prefix of /27 or longer to proceed with the migration.
76
-
- Private endpoints (PEs) in the virtual network connected through ExpressRoute private peering can 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).
77
-
- ExpressRoute Gateways that were established or connected to circuits in 2017 or earlier.
78
-
- ExpressRoute Gateways with the SKU named "default" are not supported for migration.
92
+
### How do I check if my gateway SKU is eligible for migration?
79
93
80
-
For detailed troubleshooting errors and best practices, see [Troubleshooting Gateway Migration](gateway-migration-error-messaging.md)
94
+
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).
81
95
82
96
## Next Steps
83
97
98
+
- Troubleshoot migration issues with [Troubleshooting Gateway Migration](gateway-migration-error-messaging.md).
84
99
- Learn how to [migrate using the Azure portal](expressroute-howto-gateway-migration-portal.md).
85
100
- Learn how to [migrate using PowerShell](expressroute-howto-gateway-migration-powershell.md).
86
-
- Explore best practices for [designing for high availability](designing-for-high-availability-with-expressroute.md).
87
-
- 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