Objective

The backend migration process is an automated upgrade performed by Microsoft to ensure your ExpressRoute gateways use the Standard IP SKU. This migration enhances gateway reliability and availability while maintaining service continuity. You receive notifications about scheduled maintenance windows and have options to control the migration timeline. For guidance on upgrading Basic SKU public IP addresses for other networking services, see Upgrading Basic to Standard SKU.

.

Important:

As of September 30, 2025, Basic SKU public IPs are retired. For more information, see the official announcement.
You can initiate the ExpressRoute gateway migration yourself at a time that best suits your business needs, before the Microsoft team performs the migration on your behalf. This gives you control over the migration timing. Please use the ExpressRoute Gateway Migration Tool to migrate your gateway Public IP to Standard SKU. This tool provides a guided workflow in the Azure portal and PowerShell, enabling a smooth migration with minimal service disruption. 

Backend migration overview

The backend migration is scheduled during your preferred maintenance window. During this time, the Microsoft team performs the migration with minimal disruption. You don’t’ need to take any actions. The process includes the following steps:

1. Deploy new gateway: Azure provisions a second virtual network gateway in the same GatewaySubnet alongside your existing gateway. Microsoft automatically assigns a new Standard SKU public IP address to this gateway.
2. Transfer configuration: The process copies all existing configurations (connections, settings, routes) from the old gateway. Both gateways run in parallel during the transition to minimize downtime. You may experience brief connectivity interruptions may occur.
3. Clean up resources: After migration completes successfully and passes validation, Azure removes the old gateway and its associated connections. The new gateway includes a tag CreatedBy: GatewayMigrationByService to indicate it was created through the automated backend migration

Important:

 To ensure a smooth backend migration, avoid making non-critical changes to your gateway resources or connected circuits during the migration process. If modifications are absolutely required, you can choose (after the Migrate stage complete) to either commit or abort the migration and make your changes.

Backend process details

This section provides an overview of the Azure portal experience during backend migration for an existing ExpressRoute gateway. It explains what to expect at each stage and what you see in the Azure portal as the migration progresses. To reduce risk and ensure service continuity, the process performs validation checks before and after every phase.

The backend migration follows four key stages:

1. Validate: Checks that your gateway and connected resources meet all migration requirements for the Basic to Standard public IP migration.
2. Prepare: Deploys the new gateway with Standard IP SKU alongside your existing gateway.
3. Migrate: Cuts over traffic from the old gateway to the new gateway with a Standard public IP.
4. Commit or abort: Finalizes the public IP SKU migration by removing the old gateway or reverts to the old gateway if needed.

These stages mirror the Gateway migration tool process, ensuring consistency across both migration approaches.

 

The Azure resource group RGA serves as a logical container that displays all associated resources as the process updates, creates, or removes them. Before the migration begins, RGA contains the following resources:

 

This image uses an example ExpressRoute gateway named ERGW-A with two connections (Conn-A and LAconn) in the resource group RGA.

Portal walkthrough

Before the backend migration starts, a banner appears in the Overview blade of the ExpressRoute gateway. It notifies you that the gateway uses the deprecated Basic IP SKU and will undergo backend migration between March 7, 2026, and April 30, 2026:

 

 

Validate stage

Once you start the migration, the banner in your gateway’s Overview page updates to indicate that migration is currently in progress.

 

 

In this initial stage, all resources are checked to ensure they are in a Passed state. If any prerequisites aren't met, validation fails and the Azure team doesn't proceed with the migration to avoid traffic disruptions. No resources are created or modified in this stage.

 

After the validation phase completes successfully, a notification appears indicating that validation passed and the migration can proceed to the Prepare stage.

 

Prepare stage

In this stage, the backend process provisions a new virtual network gateway in the same region and SKU type as the existing gateway. Azure automatically assigns a new public IP address and re-establishes all connections. This preparation step typically takes up to 45 minutes.

To indicate that the new gateway is created by migration, the backend mechanism appends _migrate to the original gateway name. During this phase, the existing gateway is locked to prevent configuration changes, but you retain the option to abort the migration, which deletes the newly created gateway and its connections.

After the Prepare stage starts, a notification appears showing that new resources are being deployed to the resource group:

 

 

Deployment status

In the resource group RGA, under Settings → Deployments, you can view the status of all newly deployed resources as part of the backend migration process.

 

In the resource group RGA under the Activity Log blade, you can see events related to the Prepare stage. These events are initiated by GatewayRP, which indicates they are part of the backend process:

Deployment verification

After the Prepare stage completes, you can verify the deployment details in the resource group RGA under Settings > Deployments. This section lists all components created as part of the backend migration workflow.

The new gateway ERGW-A_migrate is deployed successfully along with its corresponding connections: Conn-A_migrate and LAconn_migrate.

 

Gateway tag

The newly created gateway ERGW-A_migrate includes the tag CreatedBy: GatewayMigrationByService, which indicates it was provisioned by the backend migration process.

 

Migrate stage

After the Prepare stage finishes, the backend process starts the Migrate stage. During this stage, the process switches traffic from the existing gateway ERGW-A to the new gateway ERGW-A_migrate.

Gateway ERGW-A_migrate:

 

Old gateway (ERGW-A) handles traffic:

 

After the backend team initiates the traffic migration, the process switches traffic from the old gateway to the new gateway. This step can take up to 15 minutes and might cause brief connectivity interruptions.

 

 

New gateway (ERGW-A_migrate) handles traffic:

Commit stage

After migration, the Azure team monitors connectivity for 15 days to ensure everything is functioning as expected. The banner automatically updates to indicate completion of migration:

 

During this validation period, you can’t modify resources associated with both the old and new gateways. To resume normal CRUD operations without waiting15 days, you have two options:

• Commit: Finalize the migration and unlock resources.
• Abort: Revert to the old gateway, which deletes the new gateway and its connections.

To initiate Commit before the 15-day window ends, type yes and select Commit in the portal.

 

 

When the commit is initiated from the backend, you will see “Committing migration. The operation may take some time to complete.”

 

 

The old gateway and its connections are deleted. The event shows as initiated by GatewayRP in the activity logs.

 

 

 

After old connections are deleted, the old gateway gets deleted.

 

Finally, the resource group RGA contains only resources only related to the migrated gateway
ERGW-A_migrate:

 

The ExpressRoute Gateway migration from Basic to Standard Public IP SKU is now complete.

Frequently asked questions

How long will Microsoft team wait before committing to the new gateway?

The Microsoft team waits around 15 days after migration to allow you time to validate connectivity and ensure all requirements are met. You can commit at any time during this 15-day period.

What is the traffic impact during migration? Is there packet loss or routing disruption?

Traffic is rerouted seamlessly during migration. Under normal conditions, no packet loss or routing disruption is expected. Brief connectivity interruptions (typically less than 1 minute) might occur during the traffic cutover phase.

Can we make any changes to ExpressRoute Gateway deployment during the migration?

Avoid making non-critical changes to the deployment (gateway resources, connected circuits, etc.). If modifications are absolutely required, you have the option (after the Migrate stage) to either commit or abort the migration.