Save to My DOJO
Microsoft already provides a good guide on how to migrate to Azure Virtual WAN, however, there are several frequently asked questions not covered there which streamline the migration process and save you a few headaches along the way. This article will focus on real-world migrations and advice covering:
-
- Dos and don’ts
-
- Mitigating downtimes
-
- Interims solutions
Getting Started with Azure Virtual WAN
Normally you are coming from a hub and spoke architecture with a shared services hub. Microsoft describes that architecture within the architecture design center.
Hub-spoke network topology in Azure – Azure Reference Architectures | Microsoft Docs
Your target architecture would be a plain and simple Azure virtual WAN like shown here
Hub-spoke network topology with Azure Virtual WAN – Azure Architecture Center | Microsoft Docs
Or you could deploy a virtual WAN with shared Services
Scenario: Route to shared services VNets – Azure Virtual WAN | Microsoft Docs
Step 1 – Deploy your Virtual WAN Hub
In the first step, you should create your virtual WAN with VPN and or ExpressRoute Gateways and connect it to your on-premises infrastructure.
Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections | Microsoft Docs
Very important side note: the requirement for the IP range of a virtual WAN hub changed. Microsoft Virtual Product Group now engages customers to use a /23 CIDR address range for every hub. That’s a necessary change due to the enhanced capabilities of the Azure Virtual WAN Hub.
The next step is testing. Connect your on-premises location to Azure and deploy a Virtual Network with a virtual machine in it.
Quickstart – Create a Windows VM in the Azure portal – Azure Virtual Machines | Microsoft Docs
Then connect the Virtual Network to your virtual WAN hub. Afterwards, test if you can reach the virtual Machine using its private IP.
If you can connect to the Virtual Machine, you know connectivity is working correctly.
Step 2 – Setting up Network Security
Before you migrate to Virtual WAN, you need to decide how to implement network security. Currently, you have three options.
-
- Using Network Security Groups in a Virtual Network for basic security.
- Use Azure Virtual WAN Secured Hub with Azure Firewall.
- Use a Network Virtual Appliance in a Spoke Virtual Network as a security device.
Network Security Groups
With Network Security Groups you have basic network security and control but they are hard to manage at scale. Network Security Groups (NSGs) offer all the necessary configuration options for network security, but the sheer amount of NSGs to manage with individual rules per subnet or server can become a tough challenge.
Many Microsoft customers are asking for a Network Security Group management tool or interface. Currently, there is no Microsoft announcement on a solution to this. An example of such a tool by a third party is Aviatrix. Schedule a Demo – Aviatrix
To be honest, most smaller customers should be fine using NSGs instead of large appliances or Azure Firewall.
Below you can find a guide to create Network Security Groups.
https://docs.microsoft.com/en-us/azure/virtual-network/manage-network-security-group
With Network Security Groups, you have no restrictions on routing scenarios. With the other two Network Security solutions, you might face some restrictions.
We can dive deeper within another blog post, please leave a comment if you would like to learn more about Network Security Groups and their use.
Azure Virtual WAN Secure Hub
Azure Virtual WAN Secured Hub is an addition to a regular Azure Virtual WAN. When securing an Azure Virtual WAN hub, you introduce a Managed Azure Firewall into the Virtual WAN Hub.
In contrast to a traditional hub and spoke architecture with custom routing, where customers need to manage the route integration themselves, a secured Hub integration will connect Azure Firewall directly into the routing of your Azure Virtual WAN Hub.
Customers can easily change routing behaviour and force traffic from Site 2 Site, Point 2 Site, ExpressRoute or Virtual Network Connection through the Azure Firewall. You only need to change it within the Azure Firewall Manager Interface.
Azure Firewall Manager deployment overview | Microsoft Docs
Currently, all routing flows are supported with Azure Virtual WAN Secure Hub except routing between two secured hubs. At the time of writing, the Secure Hub to Secure Hub route flow is currently in limited private preview for 3 weeks.
It may be the case that route flow may see it as a supported flow when you’re reading this.
If it’s still in private preview, please contact me via LinkedIn and I will help you onboard to the private preview.
You can find more documentation about the routing via the links below.
Scenario: Azure Firewall custom routing for Virtual WAN – Azure Virtual WAN | Microsoft Docs
Network Security Appliance in a spoke
The third option you can choose is to put a Network Virtual Appliance into a spoke Virtual Network which is connected to an Azure Virtual WAN Hub.
Here you would either use static routes or the new BGP Peering integration with virtual WAN.
Both configurations are described below.
Route traffic through NVAs by using custom settings – Azure Virtual WAN | Microsoft Docs
About BGP peering with a virtual hub – Azure Virtual WAN | Microsoft Docs
Currently, there is only one limitation in the NVA scenario. The route flow from Virtual Network to Virtual Network via Virtual WAN Hub and Network Virtual Appliance is not supported.
If you want to secure Virtual Network to Virtual Network Traffic through a Network Virtual Appliance, you need to use a so-called Hub – Hub – Spoke architecture.
Conclusion
Depending on your current architecture, you should always choose the simplest method. During migration to Virtual WAN you should not overly complicate the migration itself. If you are already using Network Virtual Appliances in your current hub and spoke architecture, the easiest way to migrate is to use the “Network Security Appliance in a Spoke” scenario.
If you are using Azure Firewall in a spoke, the secure hub would be the solution of your choice because you can just migrate the rules and policies to the hub.
If you didn’t use Network Virtual Appliances and Azure Firewall, you can go with plain Network Security Groups.
Now that you know the network security options currently available, you should also be aware of other scenarios with Virtual WAN on the horizon where you can use Network Virtual Appliances within the Virtual WAN Hub, so stay tuned and follow the Virtual WAN updates.
Azure Virtual WAN: About Network Virtual Appliance in the hub | Microsoft Docs
Now let’s discuss what happens to a classic hub after the Migration to virtual WAN.
Step 3 – What happens to my old hub after the Migration?
When you migrate away from a classic hub and spoke, you normally have fragments of the old environment remaining. Normally, you had your central hub Virtual Network which homed the virtual Network Gateways, Network Virtual Appliances and Shared Services like Domain Controllers, DNS or other shared services.
With Virtual WAN at least the Gateways are obsolete and will move into Virtual WAN. You will still need some of the Shared Services like the Domain Controllers and DNS.
In the end, the old hub will be transformed into a connected Virtual Network.
How to Prepare and Test your Migration
Before you start a migration, you should always set up a test or at least a pre-staging environment. It helps you learn the procedures and will optimize your migration steps.
Step 1 – Prepare your Test Environment and test all route flows
You should have already prepared a virtual WAN Hub and a spoke with at least one Virtual Machine in it.
If you are migrating to the Hub – Hub Spoke with Network virtual Appliance, you should have a second hub with at least a Router Virtual Machine in. That could be a Linux VM acting as a router at that time. Later it would be your Network Virtual Appliance.
Don’t build or test scenarios and architectures which are too far away from your planned target architecture. Always stay as near as possible, otherwise, you could find yourself in trouble while migrating.
Step 2 – Prepare your classic Hub and Virtual WAN interconnect
As your old hub is the last part you would touch in the migration, you need to prepare it for the migration. Otherwise, you will encounter longer downtimes or issues during the migration.
If you are migrating to the Hub – Hub Spoke, you can skip the following part and move directly to the migration chapter of this article.
Old environment to the new virtual WAN Hub environment
To establish complete communication between both environments during the whole migration process, I suggest establishing a connection directly between both the old hub and the new virtual WAN hub.
If you are using Azure ExpressRoute, you can just create the ExpressRoute Gateway in Virtual WAN. Afterwards, you connect the old Virtual Network Gateway from the old Hub and the new ExpressRoute Gateway from the new Virtual WAN hub to the ExpressRoute Circuit. That will enable routing of the traffic via the Microsoft Enterprise Edge and Microsoft backbone
Important note: please remove any default routes (0.0.0.0/0) or forced tunnel configurations to on-premises before you connect the ExpressRoute to Azure Virtual WAN. That could break the hub routing. If your provider is advertising such a route, please let the provider remove it.
Tutorial: Create ExpressRoute connections using Azure Virtual WAN | Microsoft Docs
If you are using an IPSec VPN Connection, create a VPN tunnel between the Classic Virtual Network Gateway and the Azure Virtual WAN VPN Gateway.
Connect a virtual network gateway to an Azure Virtual WAN | Microsoft Docs
The connection either via ExpressRoute or VPN will ensure that your spokes have access to your spoke at any time during the migration. If you remove the peering from the old spoke and switch it over to the new hub, it will then be announced through the temporary VPN or ExpressRoute peering.
There is a third option to stay connected during the whole migration, but it carries some risk. You can also keep the old peering from the spoke to the hub, but you need to remove the “use remote gateway/route server” option in the old peering. That option will be provided by the Azure Virtual WAN Virtual Network Connection.
I personally would recommend the VPN or ExpressRoute connection, it carries with it some costs but reduces the downtime, time to clean up and the chance of mistakes.
Step 3 – Test the connectivity
As you now have the connection established it is important to test it and ensure you stay connected during the whole migration.
Test old to new interconnect
Connect to your test Virtual Machine connected to the new virtual WAN hub and check if you can reach the following Virtual Machines on the old Hub environment.
-
- Check if you can reach another Virtual Machine on the other Hub environment
-
- Check if you can reach DNS and Domain Controllers
On the old hub please ensure that you can reach the Test Virtual Machine in the new Virtual WAN environment.
If you can reach both ends, the connection is fine and established.
Please also ensure that both environments can still reach your on-premises environment.
Test Migration of a spoke
If you want to ensure that you can migrate a spoke, you can create a new Virtual Network connected to the old spoke and deploy a Virtual Machine into the spoke. Afterwards, you can perform one of the migration paths described below.
Connect your Branches
Before you migrate, one necessary step is to connect your VPN branches to Virtual WAN before you start the migration. Otherwise, your branches will no longer be able to connect to your Azure environment.
Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections | Microsoft Docs
I would highly recommend using a managed CPE provider to simplify the whole configuration and integration or even use a Network Virtual Appliance in Virtual WAN Hub Partner and use a managed appliance Partner.
Azure Virtual WAN: Create a Network Virtual Appliance (NVA) in the hub | Microsoft Docs
Azure Virtual WAN: About Network Virtual Appliance in the hub | Microsoft Docs
Create a BGP peering with virtual hub(Preview) – Azure portal – Azure Virtual WAN | Microsoft Docs
Prepare your Point to Site VPN
If you use Point to Site VPN with the old environment, you need to prepare your user VPN and clients as well.
Configure an Always-On VPN tunnel – Azure Virtual WAN | Microsoft Docs
Configure an Always-On VPN user tunnel – Azure Virtual WAN | Microsoft Docs
Create an Intune profile for User VPN clients – Azure Virtual WAN | Microsoft Docs
Download Azure Virtual WAN global or hub-based VPN profiles | Microsoft Docs
For the profiles you should use, I would highly recommend the global profile. In addition to the global profile, you can also use Azure Traffic Manager in front of the Virtual WAN Point to Site Gateways to optimize global load balancing and customize according to your needs, for example, if you want to use a custom DNS Name for the VPN Dial-In.
Azure Traffic Manager | Microsoft Docs
How to Perform Your Migration
Now as your hub is ready, connected and tested, we can start with the actual migration. Depending on the migration scenario, you should plan a maintenance window accordingly.
Step 1 – Migrate your Spokes to virtual WAN
As we have three different target scenarios, I will split the next part of the guide into three parts. One per scenario.
Step 1a – Migrate to Network Virtual Appliance in the Spoke Scenario
When you are targeting that architecture, the migration is rather simple. You can follow the steps below:
-
- Remove the connection between Local Network Gateway and Virtual Network Gateway of the old hub. Note: never delete the Local Network Gateway Configuration.
- Remove the Classic Virtual Network Gateway for the old hub Delete a virtual network gateway: portal – Azure VPN Gateway | Microsoft Docs.
- Peer your old hub to the new Azure Virtual WAN Hub Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections | Microsoft Docs.
- If you are not using BGP on your on-premises VPN and Routing devices, know the point where you would switch your routes on-premises to the new Virtual WAN for your Azure Virtual Networks.
- Configure the Virtual WAN Hub routing so that the default route or the route that specific IP ranges points to the Network Virtual Appliance.
How to configure virtual hub routing – Azure Virtual WAN | Microsoft Docs
6. Test if you can reach all Virtual Machines and your route flows work as expected.
If everything works as expected, you can start with the cleanup process. The cleanup can be done rather quickly. Delete the User Defined Route that is associated with the Gateway Subnet, if you had one, and afterwards delete the Gateway Subnet itself. Never ever delete the Gateway Subnet and the User Defined Route before you are sure everything works as expected. After that is done, you can delete the Local Network Gateway configuration.
The cleanup process should take no longer than 25 minutes.
Please don’t forget to delete the out-of-date configurations from your on-premises VPN and Router Devices, but like with the Local Network Gateway, please leave it untouched until you can confirm that everything works smoothly.
Normally you can expect the following time during the migration process.
| Removing the Virtual Network Gateway | 30 to 55 minutes |
| Peering between Virtual Network and Virtual WAN Hub | 15 to 20 minutes per Virtual Network |
| Changing on-premises routing | 20 to 40 minutes |
| Routing Configurations in Virtual WAN to NVA | 20 to 30 minutes |
Normally you would plan a Maintenance Window from about four hours with a point of no return after three hours. If you somehow encounter issues that are not fixable until the third hour, you should start a rollback. The rollback includes the following steps:
-
- Delete the Peering to the Virtual WAN Hub
- Recreate the Virtual Network Gateway
- Reconnect the Virtual Network Gateway to the Local Network Gateway
- Change back your on-premises routing
If everything goes according to plan, you should now run your environment based on Azure Virtual WAN. In the case of that scenario, there is no additional clean process to do, as your old hub is now becoming a shared services hub.
Step 1b – Migrate to Secured Hub Scenario
The migration to a secure hub scenario is the most complex and time-consuming migration. Before you can start the actual migration, you need to upgrade your Virtual WAN Hub and transform it into a Secured Virtual Hub.
What is a secured virtual hub? | Microsoft Docs
Important note: please be aware, at the time of writing, the feature of securing routing between two or more Secured Virtual WAN Hubs is still in preview.
During the migration, I would not recommend using any firewall rules, but you should test your rules and the security options prior to the migration. Analyze your current firewall ruleset and translate it to Azure Firewall Rules.
Azure Firewall Manager policy overview | Microsoft Docs
After upgrading your Virtual WAN Hub and implementing your ruleset, you can start with the migration.
In that configuration, you will have a router within your hub environment. That router is no longer needed for Virtual WAN. To migrate to Virtual WAN you need to perform the following steps.
-
- If you are not using BGP on your on-premises VPN and routing devices, now is the point where you would switch your routes on-premises to the new Virtual WAN for your Azure Virtual Networks.
- Remove all user defined routes from the spoke you want to migrate to Virtual WAN.
- Remove the peering from the current Hub and recreate the peering to the new Virtual WAN hub Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections | Microsoft Docs.
- Repeat the step for all your spokes.
- After you’ve migrated all your spokes, remove the user-defined routes from the old hub.
- Remove the connection between Local Network Gateway and Virtual Network Gateway of the old hub. Note: never delete the Local Network Gateway Configuration.
- Remove the Classic Virtual Network Gateway for the old hub Delete a virtual network gateway: portal – Azure VPN Gateway | Microsoft Docs.
- Peer your old hub to the new Azure Virtual WAN Hub Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections | Microsoft Docs.
- Now start to secure the Virtual Network Connections with Azure Firewall. Do that one step at a time, so that you can revert changes that break service availability. How to configure Virtual WAN Hub routing policies – Azure Virtual WAN | Microsoft Docs.
If everything works as expected, you can start with the cleanup process. The cleanup can be done rather quickly. Delete User Defined Routes that are associated with the Gateway Subnet, if you had one, and afterwards delete the Gateway Subnet itself. Never ever delete the Gateway Subnet and the User Defined Route before you are sure everything works as expected. After that is done, you can delete the Local Network Gateway configuration. Delete your Router Virtual Machine and keep the backup for another few days to be on the safe side.
| Removing the Virtual Network Gateway | 30 to 55 minutes |
| Peering between Virtual Network and Virtual WAN Hub | 15 to 20 minutes per Virtual Network |
| Changing on-premises routing | 20 to 40 minutes |
| Removing the User Defined Routes from the old hub | 10 to 15 minutes |
| Securing Virtual Network and other connections | 10 to 15 minutes per connection |
For a Secured Hub migration, you should at least plan for an 8-hour migration window with 6 hours of migration and 2 hours to reverse if anything goes wrong. Your point of no return for any migration is around hour 6. Afterwards, you do not have any time to reverse back all changes.
-
- Delete the peering to the Virtual WAN Hub for every Virtual Network including the old hub and peer all spokes back the old hub.
- Reconnect the spoke User Defined Routes of the spoke and the hub.
- Recreate the Virtual Network Gateway.
- Reconnect the Virtual Network Gateway to the Local Network Gateway.
- Change back your on-premises routing.
If everything works as expected, you can start with the cleanup process. Delete User Defined Routes that are associated with the Gateway Subnet, if you had one, and afterwards delete the Gateway Subnet itself. Never ever delete the Gateway Subnet and the User Defined Route before you are sure everything works as expected. After that is done, you can delete the Local Network Gateway configuration. Delete your Router Virtual Machine and keep the backup for another few days to be on the safe side.
The cleanup process will again take about 40 Minutes.
Please don’t forget to delete the outdated configurations from your on-premises VPN and Router Devices but like with the Local Network Gateway, please leave it untouched until you can confirm that everything works smoothly.
After all the steps are done, you will operate on the shared services VNet architecture. Scenario: Route to shared services VNets – Azure Virtual WAN | Microsoft Docs
Step 1c – Migrate to Network Security Group Scenario
A Migration to the Network Security Group based scenario is very simple but implies some clean up afterwards.
In that configuration, you will have a Router within your hub environment. That Router is no longer needed for Virtual WAN. To migrate to Virtual WAN you need to perform the following steps.
-
- If you are not using BGP on your on-premises VPN and Routing devices, now is the point where you would switch your routes on-premises to the new Virtual WAN for your Azure Virtual Networks.
- Remove all User Defined Routes from the Spoke you want to migrate to Virtual WAN.
- Remove the Peering from the current Hub and recreate the peering to the new Virtual WAN hub Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections | Microsoft Docs.
- Repeat the step for all your spokes.
- After you migrated all your spokes, remove the User Defined Routes from the old hub.
- Remove the connection between Local Network Gateway and Virtual Network Gateway of the old hub. Never delete the Local Network Gateway Configuration.
- Remove the Classic Virtual Network Gateway for the old hub Delete a virtual network gateway: portal – Azure VPN Gateway | Microsoft Docs.
- Peer your old hub to the new Azure Virtual WAN Hub Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections | Microsoft Docs.
If everything works as expected, you can start with the cleanup process. The cleanup can be done rather quickly. Delete the User Defined Route that is associated with the Gateway Subnet, if you had one, and afterwards delete the Gateway Subnet itself. Never ever delete the Gateway Subnet and the User Defined Route before you are sure everything works as expected. After that is done, you can delete the Local Network Gateway configuration. Delete your Router Virtual Machine and keep the backup for another few days to be on the safe side.
The Clean-Up Process will again take about 40 minutes.
Please don’t forget to delete the outdated configurations from your on-premises VPN and Router Devices but like with the Local Network Gateway, please leave it untouched until you can confirm that everything works smoothly.
| Removing the Virtual Network Gateway | 30 to 55 minutes |
| Peering between Virtual Network and Virtual WAN Hub | 15 to 20 minutes per Virtual Network |
| Changing on-premises routing | 20 to 40 minutes |
| Removing the User Defined Routes from the old hub | 10 to 15 minutes |
Normally you should plan a maintenance window from about 3 hours with a point of no return after 2 hours depending on the number of spokes you need to migrate. If you somehow encounter issues that are not fixable until the end of hour 2, you need to start the rollback. The rollback includes the following steps.
-
- Delete the Peering to the Virtual WAN Hub for every Virtual Network including the old hub and peer all spokes back the old hub
- Reconnect the spoke User Defined Routes of the spoke and the hub
- Recreate the Virtual Network Gateway
- Reconnect the Virtual Network Gateway to the Local Network Gateway
- Change back your on-premises routing
If everything went according to plan, you should now run your environment based on Azure Virtual WAN. As we already removed the Gateways and other components during migration and cleanup, your old hub is now a shared services spoke according to the architecture below.
Scenario: Route to shared services VNets – Azure Virtual WAN | Microsoft Docs
Useful Resources
Before we finish this blog post, I would like to recommend a few articles to read while preparing your migration.
Deployment
New Features
Additional Configurations
Troubleshooting and Monitoring
Closing Thoughts
First, thank you for reading this guide! My job is to help people troubleshoot their Microsoft problems, so I hope this guide helps you avoid the most common complications encountered when migrating to Azure Virtual WAN. If there’s anything I’ve missed, please contact me via LinkedIn or leave a comment below and I’ll get straight back to you!
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
More in this category
About the Author
Flo Fox
