Cross-Tenant Azure VM Migration using Native Azure Migrate

Share

Overview

This guide explains how to migrate Azure VMs across tenants by treating the source VM as a physical machine. The Mobility Agent is modified to bypass Azure environment detection, allowing it to register with an Azure Migrate appliance in a different tenant.

Why the Native Approach Doesn’t Work

Azure Site Recovery’s Mobility Agent detects when it’s running on Azure and blocks registration with external configuration servers. This prevents cross-tenant migration using standard Azure-native flows. The fix: a single configuration change makes the agent behave like a physical server instead.

Cross Tenant Migration via Native Azure Migrate

Prerequisites

Source VM (Tenant A):

• Windows Server 2012 R2 / 2016 / 2019 / 2022, or supported Linux

• Managed disks only (unmanaged disks not supported)

• At least 32 GB free on the OS disk

• Outbound access on ports 443 and 9443 to the target appliance

• Local administrator access

Target Appliance (Tenant B):

• Azure Migrate project with source type: Physical or other cloud servers

• Windows Server 2022 VM — 32 GB RAM, 16 vCPUs, 600 GB disk

• Ports 443 and 9443 open from the source VM

• Contributor permissions on the target subscription

• Cache storage account, VNet, and target subnet ready

Migration Steps

Step 1 — Set Up Azure Migrate in the Target Tenant

  • Create an Azure Migrate Project in Target Tenant (Tenant B)
    In the Azure portal, create a new Azure Migrate project in Tenant B. While configuring the project, set the source type as “Physical or other cloud servers” to support non-Azure workloads.
  • Deploy the Azure Migrate Appliance VM
    Provision a virtual machine to act as the Azure Migrate appliance using the recommended specifications (CPU, memory, and storage as per Azure Migrate guidelines). This VM can be deployed in your on-premises environment or source infrastructure.
  • Generate Project Key and Download the Installer
    Navigate to Azure Migrate → Discover → Generate Project Key in the Azure portal.
    Download the replication appliance installer from the same section and prepare it for installation on the appliance VM.
  • Install and Register the Appliance
    Run the downloaded installer on the appliance VM in the source environment (on-premises or other cloud). During setup, register the appliance using the project key generated from the Azure Migrate project in the target tenant.
  • Validate Appliance Registration in Azure Portal
    Once registration is complete, verify the appliance status in the Azure portal. It should appear as “Available” under the Azure Migrate project and within the associated Recovery Services vault.
  • Prepare Replication Agent for Source Servers
    On the appliance VM, navigate to the software directory (typically under C:\). From there, locate the Windows/Linux replication agent files. Copy the appropriate agent to the source servers that you plan to onboard for replication.

Step 2 — Install the Mobility Agent on the Source VM

On the source VM, open a command prompt and run:

Microsoft-ASR_UA*Windows*release.exe /q /x:”C:\Program Files (x86)\Microsoft Azure Site Recovery”

Then install the agent:

UnifiedAgentInstaller.exe /Platform vmware /Silent /Role MS /CSType CSPrime /InstallLocation “C:\Program Files (x86)\Microsoft Azure Site Recovery”

Save the Agent Config Input string shown after installation — you’ll need it in Step 4.

Step 3 — Apply the Configuration Workaround

Navigate to:

C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\etc

Open drscout.conf and change:

IsAzureStackHubVm=0 → IsAzureStackHubVm=1

📝 Note: This tells the agent it is running on Azure Stack Hub (a non-standard environment), which bypasses the Azure VM detection and allows registration with an external appliance in another tenant.

Step 4 — Register the Agent (Credential-less)

Now run the below command on source server to register the source server against the target appliance:

“C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\UnifiedAgentConfigurator.exe” /SourceConfigFilePath “config.json” /CSType CSPrime /CredentialLessDiscovery true

• /SourceConfigFilePath — points to the registration config with appliance details and project key

• /CSType CSPrime — uses the modern Configuration Server architecture

• /CredentialLessDiscovery true — skips shared identity/credential requirements between tenants

Step 5 — Verify Registration

5. In the Azure portal, go to Azure Migrate → Discovered Servers in Tenant B.

6. Confirm the source VM appears as a Physical or other cloud machine.

7. On the source VM, verify that InMage Scout Application Service and SVagents are both running.

Replicate and Cut Over

8. In Azure Migrate → Replication, select the discovered VM.

9. Configure the target resource group, VNet, subnet, and disk type.

10. Start replication and wait for the initial sync to complete.

11. Run a test failover and validate.

12. Execute the final failover. Replication from Tenant A stops and the VM comes up in Tenant B.

13. Select Complete Migration in the portal to finalize.

Reference

Below link covers the commands for agent installation & registration. Change on config file to represent azure vm as physical, would not be there, follow the blog.

Microsoft Learn — About the Mobility service for disaster recovery of VMware VMs and physical servers: Mobility service overview | Azure Site Recovery