Migrate Network Resources

  • Article

Most networking services don’t support migration across Azure regions. However, you can connect your networks in two cloud environments with Global VNet Peering. Global VNet peering enables you to connect across regions privately using the Microsoft Backbone. Once peered, the virtual networks appear as one for connectivity purposes. The steps you take to set up VNet peering across regions are listed below. Once your virtual networks created, all you need to do is peer them.

Note

VVNet Peering will only work when connecting the same cloud environment types. If you’re connecting different cloud environment sites, such as sovereign and public, then use VPN Gateway.

Here are the summary of the steps needed to create a peering:

  1. Create a Virtual Network in the target region.
  2. Create a peering link from the new virtual network that is in the target region to the virtual network in the source region.
  3. Create a peering link from the virtual network in the source region to the new virtual network created in the target region.

Virtual networks

Migrating virtual networks across Azure regions isn’t supported at this time. We recommend that you create new virtual networks in the target region and migrate resources into those virtual networks.

For more information:

Network security groups

Migrating network security groups across Azure regions isn’t supported at this time. We recommend that you create new network security groups in the target region and apply the network security groups rules to the new application environment.

Get the current configuration of any network security group from the Azure portal or by running the following PowerShell commands:

$nsg=Get-AzureRmNetworkSecurityGroup -ResourceName <nsg-name> -ResourceGroupName <resourcegroupname>
Get-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg

For more information:

ExpressRoute

Migrating an Azure ExpressRoute instance across Azure regions isn’t supported at this time. For migration across cloud types, we recommend that you create new ExpressRoute circuits and a new ExpressRoute gateway in the target Azure region.

For more information:

VPN Gateway

Migrating an Azure VPN Gateway instance across Azure regions isn’t supported at this time. We recommend that you create and configure a new instance of VPN Gateway in the new region. You can collect information about your current VPN Gateway configuration by using the portal or PowerShell. In PowerShell, use a set of cmdlets that begin with Get- AzureRmVirtualNetworkGateway . Make sure that you update your on-premises configuration. Also, delete any existing rules for the old IP address ranges after you update your Azure network environment.

For more information:

Application Gateway

Migrating an Azure Application Gateway instance across Azure regions isn’t supported at this time. We recommend that you create and configure a new gateway in the new region. You can collect information about your current gateway configuration by using the portal or PowerShell. In PowerShell, use a set of cmdlets that begin with Get- AzureRmApplicationGateway.

For more information:

DNS

To migrate your Azure DNS configuration across Azure regions, export the DNS zone file, and then import it under the new subscription. Currently, the only way to export the zone file is by using the Azure CLI.

After you sign in to your source subscription in the source Azure region, configure the Azure CLI to use Azure Resource Manager mode. Export the zone by running this command:

az network dns zone export -g <resource group> -n <zone name> -f <zone file name>

Example:

az network dns zone export -g "myresourcegroup" -n "contoso.com" -f "contoso.com.txt"

This command calls the Azure DNS service to export the zone contoso.com in the resource group myresourcegroup. The output is stored as a BIND-compatible zone file in contoso.com.txt in the current folder.

When the export is finished, delete the NS records from the zone file. New NS records are created for the new region and subscription. Next, sign in to your target environment, create a new resource group (or select an existing one), and then import the zone file:

az network dns zone import -g <resource group> -n <zone name> -f <zone file name>

When the zone has been imported, you must validate the zone by running the following command:

az network dns record-set list -g <resource group> -z <zone name>

When validation is finished, contact your domain registrar and redelegate the NS records. To get NS record information, run the following command:

az network dns record-set ns list -g <resource group> -z <zone name> --output json

For more information:

Network Watcher

Migrating a Network Watcher instance across Azure regions isn’t supported at this time. We recommend that you create and configure a new Network Watcher instance in the target region. Afterward, compare results between the old and new environments.

For more information:

Traffic Manager

Azure Traffic Manager can help you complete a smoother migration. While migrating Azure resources across Azure regions, you can add a new target endpoint in the target region, and update the Traffic Manager profile to use the new endpoint.

However, you can’t migrate Traffic Manager profiles across Azure cloud types. You can define additional endpoints in the target environment by creating a new Traffic Manager profile in the target region while using the source environment at the same time. When Traffic Manager is running in the new environment, you can still define endpoints that you haven’t yet migrated in the source environment. This scenario is known as the Blue- Green scenario.

The scenario involves the following steps:

  1. Create a new Traffic Manager profile in the target Azure region.
  2. Migrate and configure endpoints. For each endpoint in the source Azure region:
    1. Migrate the endpoint to the target Azure region.
    2. Add the endpoint in the new Traffic Manager profile.
  3. Change your DNS CNAME record to the new Traffic Manager profile.
  4. Wait until the queries to the old ATM profiles totally stop by monitoring the Queries by endpoint returned metric. Some LDNS might have cached the old profile names – it’s a good idea to wait for some time to make sure all queries are now routed to the new ATM profile before disabling the old profile.
  5. Disable the old Traffic Manager profile
  6. Once you’re sure the old ATM profile can be safely deleted, delete the old ATM profile.

For more information:

Load Balancer

Migrating a Load Balancer instance across Azure regions isn’t supported at this time. We recommend that you create and configure a new load balancer in the target Azure region. If you’re currently using the Azure Load Balancer - Basic, it is recommended to upgrade to the Azure Load Balancer – Standard.

Learn more about Why use Standard Load Balancer, including limits and pricing.

Note

As we continue to add new capabilities and features for the Load Balancer, we anticipate they’ll only be available on the Standard SKU.

For more information:

CDN

CDN functiona has no regional properties and no migration is required.

Cloud Connection Service

Cloud Connection Service function has no regional properties and no migration is required.