Azure ExpressRoute is Microsoft’s solution for extending an on-premises network into the Microsoft cloud with a private connection. In this article, I’ll be explaining how you can migrate an Azure ExpressRoute connection without experiencing any downtime.
There are two possible scenarios for the migration of an Azure ExpressRoute connection. Your first option is to migrate this connection to another Azure subscription or resource group under the same subscription. The second option is to migrate it to another connectivity provider.
How to migrate an Azure ExpressRoute connection to another tenant
Let’s start with the situation where you would like to migrate an Azure ExpressRoute connection to another tenant.
Why you need to raise a support ticket
To migrate an Azure ExpressRoute to another tenant, you’ll need help from Microsoft Support. While most resources within Azure can be migrated by customers themselves, that’s not the case for Azure ExpressRoute connections. That’s due to some backend integrations between the resource provider and the physical routers used by an organization.
If you try to migrate an Azure ExpressRoute yourself on the Azure portal, you will see the following message:
To migrate an Azure ExpressRoute connection to another tenant or Azure subscription, you’ll need to raise a support ticket on the Azure portal, as shown below.
Planning for the migration
You should plan for the migration and raise the support ticket at least three weeks ahead of the cut-off date. Microsoft will then take care of the migration, and there is no downtime to expect during the process.
You can find a more detailed guide on how to migrate an Azure resource to a new subscription or resource group on the Microsoft Learn website.
How to migrate an Azure ExpressRoute connection to another provider
A provider-to-provider migration is much more challenging than a tenant-to-tenant migration. That’s mostly due to the third-party network service provider engaged.
Why provider-to-provider migrations are more complex
Network service providers always bring their own challenges with them, I will list a few below:
- Contracts that need to be made.
- Time constraints and engineer availability.
- Knowledge gaps on how to deploy.
- Lead times for physical deployments.
If an Azure ExpressRoute connection is the most critical infrastructure for a customer, they cannot risk having any downtime for this connection. That’s why you should be aware that proceeding with a migration the way most providers would prefer would probably bring up a certain amount of downtime in your organization.
In my guide, I’ll be detailing a process allowing organizations to migrate an Azure ExpressRoute connection to another provider with zero downtime.
How to plan for your Azure ExpressRoute provider-to-provider migration
First of all, it’s very important to do some planning and calculation at least one to three months before the actual migration happens, depending on your current and future network provider. If you think you can start planning a few weeks before your connection will be cut off by the old provider, there’s almost no chance it’s going to be a smooth migration.
So how should you proceed?
- First of all, you should get the contracts with your new provider done, and get this provider ready to deploy the on-premises part of your new ExpressRoute connection.
- It’s important not to change anything with the old deployment until the new deployment is fully operational.
As soon as you have the situation with your new provider figured out, you can start the deployment of a new Azure ExpressRoute connection in the Azure Portal.
Deploying a new Azure ExpressRoute connection in the Azure Portal
You can get more details about how to deploy a new Azure ExpressRoute connection on this support page. Here are the steps you’ll need to follow here:
- After your second provider enabled the new connection, it will show with a “Provisioned” status in the Azure portal, as shown below:
- Once you are in a provisioned state, you need to configure a new private peering connection. If you want to go for zero downtime, you will need to configure a new Virtual Local Area Network (VLAN) ID and peering IP range.
- After you configured your private peering settings, you need to configure the new Border Gateway Protocol (BGP) sessions with your on-premises router.
- Once you’re done, you can connect your new Azure ExpressRoute connection to your current Azure ExpressRoute Gateway.
There is no need to remove the old connection yet, Azure ExpressRoute Gateways can carry more than one connection to an Azure ExpressRoute circuit. Now, your network architecture should look like shown below.
To force the traffic through the new Azure ExpressRoute connection, you need to configure the Connection Weight for the new connection and give it a higher priority.
Afterwards, you should give yourself a period of at least three to seven days to ensure the traffic flow and stability of the connection. Once that period is over, you can disconnect the old Azure ExpressRoute circuit from the gateway. If the traffic still flows and you do not see issues, you can contact your old provider and start deprecating your old Azure ExpressRoute connection.
Conclusion
Migrating an Azure ExpressRoute connection can be a complex process that requires many parties to be involved. The migration from one tenant to another is normally simple, though you will need to work with Microsoft Support and that can take some time.
If you need to migrate this connection to another provider, you should be aware that there is a wide range of network service providers. Some are very experienced, but some aren’t. As for the migration itself, you can also get some support from the Microsoft FastTrack or Azure teams to this process a success and avoid any downtime.