Migration of VM from my account to a clients account but require static IP to remain

Question

Hi all,

I created a VM to run a server software, connected 500+ remote devices via static IP to the VM.

Now i need to hand over by migrating the VM to the clients account.

How do i ensure the static IP get migrated also?

I can't afford for it to change as i would need to go to 500+ devices to reconfigure the IPs

So my question is can i retain the static IP if i transfer the VM to another account.

Answer 1

Static public IP addresses in Azure are scoped to a subscription/resource group and cannot be moved between different accounts (subscriptions/tenants) while keeping the same IP value. When a VM is recreated or moved into another subscription, any new public IP resource will receive a different address.

Within a given virtual network, Azure also does not support reserving a specific private IP in the way required for cross-account moves; private IPs are allocated and managed per VNet, and moving to another account implies a different VNet. The FAQ notes that while a VM’s private IP can be changed to any available address in its VNet, that does not extend across subscriptions or tenants.

Therefore, migrating the VM to a different customer account cannot preserve the same public IP address. To avoid reconfiguring 500+ devices, alternatives are required, such as:

• Keeping the VM (and its IP) in the current subscription and delegating access/management instead of moving it.
• Placing a DNS name in front of the IP and updating only DNS when infrastructure changes in the future (does not help retroactively if devices already have the raw IP hardcoded).

But a direct transfer of the VM to another account while retaining the exact same static IP is not supported.

---

References:

• Azure Virtual Network frequently asked questions (FAQ)

Answer 2

Thanks for the update. In Azure, a Public IP address is its own ARM resource, scoped to a single Azure AD tenant. Azure Resource Manager does not support cross-tenant resource moves. you cannot retain the same static public IP when migrating the VM to a subscription in a different Azure AD tenant.

This limitation explicitly applies to networking resources, including:

• Public IPs
  • NICs
  • VNets

"Static" only means:

• The IP does not change while the resource exists in the same tenant
• It does not mean:
  • Transferable across tenants
  • Portable between different Azure AD directories

Microsoft explicitly documents that moving resources across Entra tenants is not supported, even if both parties agree and the region is the same. Therefore: When the destination subscription is in a different Azure AD tenant, the public IP must change. There are no exceptions or Microsoft Support overrides for this today.

If retaining the IP is mandatory:

1. Create a new Azure subscription in your current tenant
2. Move the following resources to that subscription:
   • VM
   • NIC
   • Static Public IP
   • VNet (and dependencies)
3. Transfer subscription ownership / billing to the client

As a result, Public IP remains unchanged, No changes required on 500+ devices and Fully supported by Microsoft

This approach is the officially recommended pattern when IP retention is required but organizations differ.

Move Azure resources to a new resource group or subscription - Azure Resource Manager | Microsoft Learn

https://learn.microsoft.com/en-us/azure/role-based-access-control/transfer-subscription

Answer 3

Hello Andy, you can absolutely keep your VM’s static IP – as long as you move the Public IP resource along with the VM and its NIC into the target subscription under the same Azure AD tenant. Here’s how to do it:

1. Confirm your target subscription is in the same Azure AD tenant • Moving resources (VM + NIC + Public IP) only works within the same directory. • If it’s a different tenant, you can’t directly move the Public IP resource – you’d need to redeploy, which means a new IP.
2. Use Azure Resource Manager’s “Move” feature • In the Azure portal, go to the resource group containing your VM. • Click … (More) > Move > Move to another subscription. • Select the VM, its NIC, and the Public IP resource, then pick the target subscription and resource group. • Review and start the move. The static IP address stays exactly the same. Alternatively, via PowerShell:

   
      # Example: move VM, NIC and Public IP to a new subscription/resource group
   
      $resources = @(
   
        '/subscriptions/<sourceSub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vmName>',
   
        '/subscriptions/<sourceSub>/resourceGroups/<rg>/providers/Microsoft.Network/networkInterfaces/<nicName>',
   
        '/subscriptions/<sourceSub>/resourceGroups/<rg>/providers/Microsoft.Network/publicIpAddresses/<pipName>'
   
      )
   
      Move-AzResource -DestinationSubscriptionId '<destSub>' `
   
                     -DestinationResourceGroupName '<destRg>' `
   
                     -ResourceId $resources
   
   

3. Post‐move validation • After the operation completes, verify in the portal that your VM’s public IP hasn’t changed. • Test connectivity from a client device to ensure everything still routes to your server.

If you discover you must move across separate Azure AD tenants (so the move API won’t work), consider these options instead of touching 500+ devices:

• Assign a DNS name (or CNAME) to your static IP and have devices connect via FQDN. Then you can repoint that DNS to any new IP.
• Use Azure Traffic Manager or Front Door in front of your VM—devices hit the front‐end domain, and you can switch backends without reconfiguring them.

Follow-up questions to make sure we’ve got all the details:

1. Is the static IP you’re using an ARM Public IP resource (not a classic/reserved IP)?
2. Is the client’s subscription under the same Azure AD directory as yours?
3. Are you using any custom NSGs or route tables that we should include in the move?

Reference list

• Move resources to a new resource group or subscription (ARM)
• Migrate a classic reserved IP address to a public IP address
• Plan migration of IaaS resources from classic to Azure Resource Manager
• Platform‐supported migration of IaaS resources from classic to ARM
• Create a VM with a static public IP address (ARM)