|
| 1 | +--- |
| 2 | +title: Migrate to an availability zone-enabled ExpressRoute virtual network gateway in Azure portal |
| 3 | +titleSuffix: Azure ExpressRoute |
| 4 | +description: This article explains how to seamlessly migrate from Standard/HighPerf/UltraPerf SKUs to ErGw1/2/3AZ SKUs in Azure portal. |
| 5 | +services: expressroute |
| 6 | +author: duongau |
| 7 | +ms.service: expressroute |
| 8 | +ms.custom: ignite-2023, devx-track-azurepowershell |
| 9 | +ms.topic: how-to |
| 10 | +ms.date: 04/26/2024 |
| 11 | +ms.author: duau |
| 12 | +--- |
| 13 | + |
| 14 | +# Migrate to an availability zone-enabled ExpressRoute virtual network gateway in Azure portal |
| 15 | + |
| 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 | + |
| 18 | +The following SKUs are available for ExpressRoute virtual network gateways: |
| 19 | + |
| 20 | +* Standard |
| 21 | +* HighPerformance |
| 22 | +* UltraPerformance |
| 23 | +* ErGw1Az |
| 24 | +* ErGw2Az |
| 25 | +* ErGw3Az |
| 26 | +* ErGwScale (Preview) |
| 27 | + |
| 28 | +## Prerequisites |
| 29 | + |
| 30 | +- Review the [Gateway migration](gateway-migration.md) article before you begin. |
| 31 | +- You must have an existing [ExpressRoute Virtual network gateway](expressroute-howto-add-gateway-portal-resource-manager.md) in your Azure subscription. |
| 32 | +- A second prefix is required for the gateway subnet. If you have only one prefix, you can add a second prefix by following the steps in the [Add a second prefix to the gateway subnet](#add-a-second-prefix-to-the-gateway-subnet) section. |
| 33 | + |
| 34 | +## Add a second prefix to the gateway subnet |
| 35 | + |
| 36 | +The gateway subnet needs two or more address prefixes for migration. If you have only one prefix, you can add a second prefix by following these steps. |
| 37 | + |
| 38 | +1. First, update the `Az.Network` module to the latest version by running this PowerShell command: |
| 39 | + |
| 40 | + ```powershell-interactive |
| 41 | + Update-Module -Name Az.Network -Force |
| 42 | + ``` |
| 43 | +
|
| 44 | +1. Then, add a second prefix to the **GatewaySubnet** by running these PowerShell commands: |
| 45 | +
|
| 46 | + ```powershell-interactive |
| 47 | + $vnet = Get-AzVirtualNetwork -Name $vnetName -ResourceGroupName $resourceGroup |
| 48 | + $subnet = Get-AzVirtualNetworkSubnetConfig -Name GatewaySubnet -VirtualNetwork $vnet |
| 49 | + $prefix = "Enter new prefix" |
| 50 | + $subnet.AddressPrefix.Add($prefix) |
| 51 | + Set-AzVirtualNetworkSubnetConfig -Name GatewaySubnet -VirtualNetwork $vnet -AddressPrefix $subnet.AddressPrefix |
| 52 | + Set-AzVirtualNetwork -VirtualNetwork $vnet |
| 53 | + ``` |
| 54 | +
|
| 55 | +## Migrate to a new gateway in Azure portal |
| 56 | +
|
| 57 | +Here are the steps to migrate to a new gateway in Azure portal. |
| 58 | +
|
| 59 | +
|
| 60 | +1. In the [Azure portal](https://portal.azure.com/), navigate to your Virtual Network Gateway resource. |
| 61 | +
|
| 62 | +1. the left-hand menu under *Settings*, select **Gateway SKU Migration**. |
| 63 | +
|
| 64 | + :::image type="content" source="media/gateway-migration/gateway-sku-migration-location.png" alt-text="Screenshot of Gateway migration location."lightbox="media/gateway-migration/gateway-sku-migration-location.png"::: |
| 65 | +
|
| 66 | +1. Select **Validate** to check if the gateway is ready for migration. You'll first see a list of prerequisites that must be met before migration can begin. If these prerequisites aren't met, validation fails and you can't proceed. |
| 67 | +
|
| 68 | + :::image type="content" source="media/gateway-migration/validate-step.png" alt-text="Screenshot of the validate step for migrating a virtual network gateway."lightbox="media/gateway-migration/validate-step.png"::: |
| 69 | +
|
| 70 | +1. Once validation is successful, you enter the *Prepare* stage. Here, a new Virtual Network gateway is created. Under **Virtual Network Gateway Details**, enter the following information. |
| 71 | + |
| 72 | + :::image type="content" source="media/gateway-migration/gateway-prepare-stage.png" alt-text="Screenshot of the Prepare stage for migrating a virtual network gateway."lightbox="media/gateway-migration/gateway-prepare-stage.png"::: |
| 73 | +
|
| 74 | + | Setting | Value | |
| 75 | + | --------| ----- | |
| 76 | + | **Gateway Name** | Enter a name for the new gateway. | |
| 77 | + | **Gateway SKU** | Select the SKU for the new gateway. | |
| 78 | + | **Public IP Address** | Select **Add new**, then enter a name for the new public IP, select your availability zone, and select **OK** | |
| 79 | +
|
| 80 | + > [!NOTE] |
| 81 | + > Be aware that your existing Virtual Network gateway will be locked during this process, preventing any creation or modification of connections to this gateway. |
| 82 | +
|
| 83 | +1. Select **Prepare** to create the new gateway. This operation could take up to 15 minutes. |
| 84 | +
|
| 85 | +1. After the new gateway is created, you'll proceed to the *Migrate* stage. Here, select the new gateway you created. In this example, it's **myERGateway_migrated**. This transfers the settings from your old gateway to the new one. All network traffic, control plane, and data path connections from your old gateway will transfer without any interruptions. To start this process, select **Migrate Traffic**. This operation could take up to 5 minutes. |
| 86 | +
|
| 87 | + :::image type="content" source="media/gateway-migration/migrate-traffic-step.png" alt-text="Screenshot of migrating traffic for migrating a virtual network gateway."lightbox="media/gateway-migration/migrate-traffic-step.png"::: |
| 88 | +
|
| 89 | +1. After the traffic migration is finished, you'll proceed to the *Commit* stage. In this stage, you finalize the migration, which involves deleting the old gateway. To do this, select **Commit Migration**. This final step is designed to occur without causing any downtime. |
| 90 | +
|
| 91 | + :::image type="content" source="media/gateway-migration/commit-step.png" alt-text="Screenshot of the commit step for migrating a virtual network gateway."lightbox="media/gateway-migration/commit-step.png"::: |
| 92 | +
|
| 93 | +
|
| 94 | +>[!IMPORTANT] |
| 95 | +> - Before running this step, verify that the new virtual network gateway has a working ExpressRoute connection. |
| 96 | +> - When migrating your gateway, you can expect possible interruption for a maximum of 30 seconds. |
| 97 | +
|
| 98 | +## Next steps |
| 99 | +
|
| 100 | +* Learn more about [designing for high availability](designing-for-high-availability-with-expressroute.md). |
| 101 | +* 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