Azure VNet Gateway SKU Migration Causing Loss of On‑Prem Connectivity

Question

Azure VNet Gateway SKU Migration Causing Loss of On‑Prem Connectivity

Htin Aung 20

My Azure VMs connect to on‑premises servers through ExpressRoute. Recently, I needed to perform a SKU migration on the virtual network gateway. I used the SKU migration tool, and after the traffic migrated to the new gateway, the connection between my Azure VMs and on‑premises servers was lost. I then aborted the migration to restore connectivity.

How can I resolve this issue and successfully complete the SKU migration without losing the ExpressRoute connectivity?

0 comments

Answer accepted by question author

Praveen Bandaru 11,800 Microsoft External Staff Moderator

Hello Htin Aung

It appears your ExpressRoute circuit lost BGP connectivity when the new gateway took over. You can perform a SKU migration without disrupting your on-premises connectivity by using the “seamless gateway migration” workflow instead of resizing the current gateway. Here’s an overview:

During migration, when you use the Prepare option to create a new virtual network gateway, a Public IP will be assigned automatically. This process takes around 45 minutes and does not cause any traffic disruptions.

Additionally, after migrating traffic from the old gateway to the new one, you may experience network drops for a few minutes (up to 15 minutes). You can plan for this accordingly. See the screenshot below:

User's image

Check the below reference document for more understanding:

Steps to migrate to a new gateway

Check prerequisites:

Your ExpressRoute circuit should be at least Standard SKU (Basic circuits can’t cross regions).
If your gateway’s public IP is Basic SKU, upgrade it to Standard (ExpressRoute doesn’t support Basic-IP gateway migration).
Confirm all gateway connections and BGP peers are in “Succeeded” state.

Validate → Prepare → Migrate → Commit process.

Validate: In Azure portal, go to Virtual Network Gateway > Gateway SKU migration > Validate. Resolve any issues (such as circuit SKUs or regions)

Prepare: A second gateway with your target SKU is created alongside the existing one. The old gateway remains active and locked.

Migrate traffic: Select the new gateway and click Migrate traffic. Azure transfers BGP sessions, routes, and ExpressRoute peering to the new gateway. Expect a short BGP flap, but no downtime. Wait until this process finishes (about 5–15 minutes).

Commit: After verifying your on-prem routers receive Azure prefixes via the new gateway, select Commit migration to remove the old gateway

While

Post-migration checks: Confirm that BGP neighbors are active on the new gateway. Use ping or iPerf to test connectivity from your VMs to on-premises. Review your ExpressRoute metrics (bytes in and out) to ensure traffic is flowing correctly.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "accept the answer" and "upvote" where the information provided will help you, this can be beneficial to other members of the community.

Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2026-03-25T12:46:40.2966667+00:00

Hello Htin Aung

I just wanted to follow up and see if you had a chance to review my answer to your question. Please let us know if you found it useful, and don't hesitate to contact us if you have any further questions.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.
Htin Aung 20 Reputation points

2026-03-26T01:49:49.0966667+00:00

Hi Praveen Bandaru,

Thank you for your response.

I did the SKU migration again and completed it via the Azure Portal without any connectivity disruption. However, after the traffic migration, I noticed that while the new gateway's Admin State is enabled, its connection metrics show no data throughput (BitsInPerSecond / BitsOutPerSecond).

Interestingly, the old gateway connection still appears to be actively passing traffic with the gateway's Admin State is disabled. Is this expected behavior post triffic migration, before commit it?

Appreciate your guidance on this.
Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2026-03-28T17:11:07.7166667+00:00

Hello Htin Aung

This is expected behavior during the migration phase before changes are committed. While migrating SKUs, Azure keeps both the old and new gateways active. Even though the new gateway is enabled from the control plane, Azure continues to direct live traffic through the existing gateway until the migration is finalized. This means you’ll still see traffic metrics on the old gateway, while the new one stays idle during this period.

After the migration is committed, all traffic moves to the new gateway, and the connection metrics will update accordingly. Until then, the current setup does not indicate any problem or misconfiguration, and operations are running as expected.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "accept the answer" and "upvote" where the information provided will help you, this can be beneficial to other members of the community.
Htin Aung 20 Reputation points

2026-03-30T09:13:05.3666667+00:00

Hi Praveen Bandaru,

Thank you for the clarification. We worried of losing the connection after the commit.

Now we will proceed to commit the migraton and complete it.

Best Regards,

Htin Aung
Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2026-03-30T22:56:08.1666667+00:00

Hello Htin Aung

Thank you for your response. If the information above was helpful, please mark the answer as accepted and upvote it. This will allow future customers facing the same issue to refer to this document.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "accept the answer" and "upvote" where the information provided will help you, this can be beneficial to other members of the community.

1 additional answer

Your answer

Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2026-03-25T12:46:40.2966667+00:00

Hello Htin Aung

I just wanted to follow up and see if you had a chance to review my answer to your question. Please let us know if you found it useful, and don't hesitate to contact us if you have any further questions.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.
Htin Aung 20 Reputation points

2026-03-26T01:49:49.0966667+00:00

Hi Praveen Bandaru,

Thank you for your response.

I did the SKU migration again and completed it via the Azure Portal without any connectivity disruption. However, after the traffic migration, I noticed that while the new gateway's Admin State is enabled, its connection metrics show no data throughput (BitsInPerSecond / BitsOutPerSecond).

Interestingly, the old gateway connection still appears to be actively passing traffic with the gateway's Admin State is disabled. Is this expected behavior post triffic migration, before commit it?

Appreciate your guidance on this.
Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2026-03-28T17:11:07.7166667+00:00

Hello Htin Aung

This is expected behavior during the migration phase before changes are committed. While migrating SKUs, Azure keeps both the old and new gateways active. Even though the new gateway is enabled from the control plane, Azure continues to direct live traffic through the existing gateway until the migration is finalized. This means you’ll still see traffic metrics on the old gateway, while the new one stays idle during this period.

After the migration is committed, all traffic moves to the new gateway, and the connection metrics will update accordingly. Until then, the current setup does not indicate any problem or misconfiguration, and operations are running as expected.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "accept the answer" and "upvote" where the information provided will help you, this can be beneficial to other members of the community.
Htin Aung 20 Reputation points

2026-03-30T09:13:05.3666667+00:00

Hi Praveen Bandaru,

Thank you for the clarification. We worried of losing the connection after the commit.

Now we will proceed to commit the migraton and complete it.

Best Regards,

Htin Aung
Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2026-03-30T22:56:08.1666667+00:00

Hello Htin Aung

Thank you for your response. If the information above was helpful, please mark the answer as accepted and upvote it. This will allow future customers facing the same issue to refer to this document.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "accept the answer" and "upvote" where the information provided will help you, this can be beneficial to other members of the community.

Answer 1

Use the guided ExpressRoute gateway migration workflow end to end and validate that all prerequisites and best practices are met before switching traffic to the new gateway. Loss of connectivity after the Migrate step typically indicates a configuration, health, or unsupported‑scenario issue on the new gateway or its connections.

Recommended approach:

Pre‑checks before retrying migration
1. Ensure the scenario is supported:
  - Migration is only for ExpressRoute virtual network gateways in the same VNet and not for VPN gateways or cross‑region/cross‑subscription moves.
  - No downgrade from an Az‑enabled SKU to a non‑Az SKU.
  - Gateway isn’t using the default SKU; if it is, resize it to Standard first.
  - Gateway isn’t a legacy (pre‑2017) gateway or connected to circuits created before 2017 in legacy mode.
  - No dedicated HSM attached to the VNet.
  - VNet has at most two ExpressRoute gateways.
2. Validate GatewaySubnet size:
  - GatewaySubnet must be /27 or longer (for example, /27, /26, /25). If smaller, delete and recreate it with a /27 or shorter prefix as required.
3. Confirm resource health:
  - Gateway, ExpressRoute circuits, connections, public IPs, VNet, and GatewaySubnet must all be in Succeeded state. If any are in a failed state, fix them (for example, by GET/SET or re‑create connections) before retrying.
4. Check FastPath and SKU compatibility:
  - If connections use FastPath (ExpressRouteGatewayByPass), only migrate to UltraPerf or ERGW3AZ SKUs. Do not downgrade SKU type.
5. Check connection limits:
  - Ensure the target gateway SKU supports at least as many connections as the current gateway. Do not migrate to a SKU with a lower connection limit.
6. Check for revoked circuit authorizations:
  - If any connected circuit authorization is revoked, migration cannot proceed; fix circuit authorizations first.
Follow migration best practices to avoid connectivity loss
1. Maintain all related resources in Succeeded state during migration; avoid updates or maintenance on circuits, connections, or gateways while migrating.
2. Do not modify properties such as FastPath, route weight, or traffic toggles on connections/gateways during the migration.
3. If multiple gateways share the same circuit, migrate them one at a time; do not run parallel migrations on the same circuit.
4. Do not manually create, delete, update, or reset gateways or their connections while they are carrying traffic.
5. Do not create new connections to a gateway that is undergoing maintenance; delete any failed connection attempts and retry after migration.
Retry the migration with controlled steps
1. Run Validate again:
  - Use the migration tool’s Validate step and ensure it completes successfully. If it fails, use the specific error from the “Common error messages” list to correct the issue (for example, resize GatewaySubnet, recreate legacy connections, deallocate HSM, or fix failed resources) and re‑validate.
2. Run Prepare:
  - Let the tool create the new gateway. If Prepare fails (for example, due to subnet size, legacy connections, or incompatible dedicated circuit), fix the reported issue, delete any partially created resources, and rerun Prepare.
3. Run Migrate and monitor traffic:
  - Start the Migrate step to move configuration and traffic to the new gateway.
  - Do not navigate away from the migration page while traffic is being moved; leaving the page may interrupt the process.
  - If migration fails and both gateways remain enabled, explicitly redirect traffic back to the old gateway (as already done) and then retry the migration after addressing the reported cause.
4. Verify ExpressRoute connectivity on the new gateway:
  - Once Migrate succeeds, confirm that:
    - ExpressRoute connections are in Succeeded state.
    - On‑premises routes are being advertised and received as expected.
    - Azure VMs can reach on‑premises servers over ExpressRoute.
  - If connectivity is not working but the migration step completed, check for any configuration changes made during or after migration (FastPath, route weight, or traffic toggles) and revert them to the original values.
Commit only after stable connectivity
1. When ExpressRoute connectivity is confirmed through the new gateway, run Commit:
  - This decommissions the old gateway and its connections.
  - After Commit, the change cannot be rolled back, so ensure connectivity is fully validated first.
2. If Commit fails and the old gateway remains enabled:
  - Retry Commit until the old gateway is successfully disabled.
  - After a successful Commit, delete the old gateway and associated resources if they are not automatically removed.
If Abort is needed again
- If migration must be aborted and the Abort step fails to clean up resources:
  - Redirect traffic to the new or old gateway as appropriate.
  - Retry the Abort operation until cleanup succeeds.

By strictly following the supported scenarios, pre‑checks, and the Validate → Prepare → Migrate → Commit flow, and by avoiding configuration changes during migration, the gateway SKU migration can be completed without losing ExpressRoute connectivity between Azure VMs and on‑premises servers.

References: