Azure Resource Migration

Question

Dear Support, I have a question and I hope you can help.

We currently have two Azure subscriptions: one paid by credit card and one billed via an Azure Microsoft Partner (invoice). We need to move all possible resources from the credit-card subscription to the invoice-billed subscription, and we’ve already completed this for some resources.

The issue is with our IaaS resources: we have a virtual FortiGate and a virtual Meraki, plus VNet peering that enables communication with services in another tenant. All move requests fail, and it seems we would need to tear down the entire setup and rebuild it from scratch.

Is Microsoft able to move these resources to the correct subscription as a complete package (including the network configuration and peering), without requiring a full rebuild?

I am happy for any information I receive!

Answer 1

Hello Lazar

Thank you for reaching out to the Microsoft Q&A forum.

Moving IaaS resources, especially when they involve complex setups like virtual appliances (e.g., FortiGate, Meraki) and VNet peering, can indeed be tricky, especially when the resources span multiple Azure subscriptions. Typically, Azure does allow moving resources between subscriptions, but there are some important limitations and steps to be aware of when dealing with networked IaaS resources.

Key Considerations

Resource Move Limitations:

Virtual Network (VNet): VNets themselves cannot be moved directly between subscriptions. However, the resources within the VNet, like VMs, can be moved, but the VNet itself needs to be part of the same subscription as the resources you're moving.

VNet Peering: VNet peering is set up between VNets in the same subscription or in different subscriptions, but moving resources between subscriptions can break peering, depending on the configuration. You'll need to re-establish VNet peering after moving the resources if the VNets are in different subscriptions.

Third-party appliances: Virtual appliances like FortiGate or Meraki are treated like regular VMs in Azure, but their configuration might rely on specific network setups, including VNets, subnets, and peering. When moving them, the associated configuration should be preserved, but you might need to reconfigure some aspects of their network setup post-move.

Network Configurations and Peering:

VNet Peering: As mentioned, VNet peering needs to be adjusted after moving resources if the peered VNets are in different subscriptions. Peering is a cross-subscription feature, but you may need to reconfigure the peering relationships after the move.

Rebuilding Network Configurations: If the network setup (peering, network security groups, routing tables) relies on resources that aren't moveable or needs to be recreated in the target subscription, you may need to tear down and rebuild parts of the configuration.

Moving Virtual Appliances (FortiGate, Meraki):

Virtual machines like FortiGate and Meraki can be moved, but the network interfaces and associated VNet configurations need to be checked after the move.

When moving VMs, ensure that their IP addresses (static or dynamic) and network interface configurations are retained, and that any associated security settings and network resources are correctly configured in the new subscription.

Can Microsoft Move These Resources?

Microsoft does offer resource migration capabilities, but they may not cover every aspect of a complex network setup, especially when it involves network configurations like VNet peering. Typically, the process works for standalone resources, but for complex IaaS setups with tightly coupled VNets, peering, and virtual appliances, you might be required to manually handle part of the migration.

Here’s what you can do:

Preliminary Steps:

Ensure that the destination subscription is properly set up to receive the resources, with necessary permissions and configurations (e.g., VNets, network security groups).

Verify that the VNet peering between the VNets (if they span different subscriptions) is properly configured in the destination subscription.

Azure Resource Move:

Use the Azure portal or Azure CLI to attempt moving the resources, including the virtual appliances, network interfaces, and VMs. Azure should retain the settings for the resources if they are successfully moved.

However, peering connections and certain configurations (e.g., network interfaces) may need to be manually re-established after the move.

Re-establish Network Configurations:

Once the resources are moved, you may need to reconfigure VNet peering, network security groups, and routing tables in the new subscription to ensure the network is functioning properly.

Recreate Peering: If your VNets are in different subscriptions, you will need to reconfigure the VNet peering in the new subscription.

Conclusion

While Microsoft Azure allows for the migration of many resources between subscriptions, network configurations such as VNet peering and third-party virtual appliances might require manual reconfiguration after moving the resources. It is unlikely that the entire setup can be moved seamlessly as a "complete package" without some post-move adjustments to the network configuration. Therefore, while the move process can help, you might still need to rebuild or reconfigure parts of the network (e.g., VNets, peering, routing) manually.

Let us know if you have further questions?

Answer 2

Moving Azure resources, particularly IaaS resources like virtual machines and networking configurations, can be complex. Based on the information available, here are some important points regarding your situation:

1. Resource Move Limitations: Not all Azure resources support moving between subscriptions, especially when they involve complex configurations like network peering. For instance, moving resources such as virtual machines may require that the destination subscription is registered for the specific resource types involved.
2. Network Configuration: When moving resources, Azure does not support moving the entire network configuration (including VNet peering) as a complete package. Each resource must be moved individually, and dependencies may need to be reconfigured post-move.
3. Manual Reconfiguration: If the move requests for your FortiGate and Meraki virtual appliances are failing, it may indeed require manual intervention to tear down and rebuild the network configuration in the new subscription. This includes setting up VNet peering again, as it does not automatically transfer with the resources.
4. Microsoft Support: Unfortunately, Microsoft does not provide a service to move these resources as a complete package. You will need to follow the guidelines for moving resources and potentially engage Azure support for specific issues related to your subscriptions and resources.

If you are encountering specific errors during the move process, it may be beneficial to check the Azure documentation for troubleshooting or to create a support request for assistance.

---

References:

• Move Azure resources to a new resource group or subscription
• Move Azure resources across resource groups, subscriptions, or regions