Has Anyone Successfully Migrated Azure Subscriptions Between Tenants? Success Rate and Downtime Considerations

Azure subscriptions can be moved between Microsoft Entra tenants, but tenant-to-tenant migrations are complex and often require a mix of subscription moves and workload rebuilds. Many services and identity constructs don’t move cleanly and must be re-created.

Can subscriptions be moved directly between tenants?

Yes. A subscription can be transferred to a different Microsoft Entra directory primarily for billing/ownership reasons.

Key points and limitations:

• Moving a subscription is supported but has service-specific impacts. Some services are recoverable with manual steps; others are not supported at all.
• The official guidance emphasizes that migrating subscriptions between tenants is complex, and in many cases it’s easier and more controlled to rebuild workloads in a new subscription in the destination tenant rather than move the subscription itself.
• Some resources are impacted and require manual remediation after the move. For example:
  • Azure Service Bus: must delete/re-create managed identities and re-create role assignments.
  • Azure Synapse Analytics Workspace: must update the tenant ID and possibly Git configuration.
  • Azure Databricks: moving workspaces to a new tenant is not supported.
  • Azure Compute Gallery: must replicate/copy images.
  • Azure resource locks: must be exported and re-created.
• Some services (e.g., Microsoft Dev Box, Azure Deployment Environments, Service Fabric clusters) cannot be transferred and must be re-created.

For a cross-tenant resource move (not just subscription transfer), many resources cannot be moved; the documented pattern is to re-create them in the destination subscription.

Common migration approaches

1. Subscription transfer where possible
   • Use “Transfer an Azure subscription to a different Microsoft Entra directory” when:
     • The subscription is relatively simple.
     • Impacted services are known and manageable.
   • Then remediate impacted services using the official impact matrix.
2. Rebuild/redeploy workloads in a new subscription/tenant
   • Recommended in the Cloud Adoption Framework for multitenant scenarios: because subscription moves are complex, it’s often easier to rebuild the application workload in a new subscription in the destination tenant.
   • Use IaC (ARM/Bicep/Terraform) and DevOps pipelines to re-create PaaS resources, App Service, networking, and policies in the target tenant.
   • Use backup/restore or data copy for data services (e.g., Azure SQL Database, Storage).
3. Hybrid approach
   • Transfer some subscriptions (where impact is acceptable) and rebuild others.
   • For IaaS workloads (VMs/images) where cross-tenant moves are blocked, use patterns like:
     • Snapshot + cross-tenant shared access for managed disks, then create new VMs in the target subscription.
     • Export managed images to a storage account accessible by the destination tenant and re-create images.
     • Use Compute Gallery with cross-tenant sharing for images.

Identity and access (Entra ID, RBAC, service principals, managed identities)

• Cloud Adoption Framework guidance strongly recommends starting with a single tenant and only introducing multiple tenants when absolutely required, because managing identity, governance, and security across multiple tenants is significantly more complex.
• When transferring a subscription to another tenant:
  • App registrations are impacted and must be re-created or reconfigured.
  • RBAC role assignments tied to identities in the source tenant will not automatically map to identities in the destination tenant; they must be re-established.
  • Managed identities for services like Service Bus must be deleted and re-created, then reattached to resources, and role assignments must be re-created.
• For cross-tenant workload migration (rebuild pattern):
  • Re-create service principals and managed identities in the target tenant.
  • Re-apply RBAC assignments in the new subscriptions/management groups.
  • Carefully plan JML (joiners, movers, leavers) processes and tools to handle multiple tenants if they will coexist.

Impact on networking, policies, and tenant-scoped services

• Networking (VNets, NSGs, firewalls, etc.) is subscription-scoped. If the subscription is moved, the networking moves with it, but any dependencies on tenant-scoped identity (e.g., private endpoints using managed identities, firewall rules referencing service tags tied to specific services) may require validation.
• Policies and management groups:
  • When moving subscriptions between management groups (within a tenant), existing policies and RBAC may change; tokens may take up to 30 minutes to refresh.
  • When moving to a new tenant, the entire management group and policy hierarchy is different; policies must be redefined and re-applied.
  • Existing resources may show as noncompliant under new policies and require manual remediation.
• Tenant-scoped services (e.g., Microsoft 365 integration, cross-tenant collaboration, Entra administrative units) are not moved with subscriptions and must be reconfigured in the destination tenant.

Downtime and recovery considerations

The documentation does not provide a full downtime matrix per service, but it does outline patterns that influence downtime:

• Low/no-downtime patterns (where supported):
  • For VMs: snapshot managed disks, share via cross-tenant access, create new VMs in the destination subscription, then perform a planned cutover.
  • For images: use Compute Gallery cross-tenant sharing to pre-stage images before cutover.
  • For data services: use backup/restore or replication-based approaches (where supported) to pre-stage data, then perform a short cutover window.
  • Use Azure Backup to protect data and enable recovery during migration.
• Services that typically require downtime or re-creation:
  • Azure Databricks workspaces: cannot be moved; must be re-created, implying downtime or parallel environment with cutover.
  • Service Fabric clusters: must be re-created.
  • Dev Box and Azure Deployment Environments: cannot be transferred; must be rebuilt.
  • Any resource using encryption at rest with keys in a Key Vault that is also being transferred can hit unrecoverable scenarios; guidance is to switch to a different key vault or temporarily disable customer-managed keys before the move.
• Rollback and recovery:
  • Use Azure Backup for data protection and recovery during migration.
  • Before subscription transfer, use Azure Resource Graph to inventory impacted resources and plan remediation/rollback.
  • For rebuild scenarios, rollback usually means failing back to the original tenant/subscription and DNS/traffic manager changes.

Real-world success, reliability, and lessons (from guidance)

The official guidance emphasizes:

• Complexity and risk of multi-tenant and tenant-to-tenant scenarios.
• Strong recommendation to prefer a single tenant where possible.
• For tenant moves, it’s often easier and more controlled to rebuild workloads in a new subscription in the destination tenant rather than rely solely on subscription transfer.

Key lessons and pitfalls from the guidance:

• Carefully analyze service-specific impacts before transferring a subscription; some services are unrecoverable or require significant manual work.
• Pay special attention to encryption at rest with Key Vault dependencies to avoid unrecoverable scenarios.
• Expect to rebuild identity and RBAC in the new tenant.
• Use Azure Resource Graph to list impacted resources and plan remediation.
• Plan for policy and RBAC changes when moving subscriptions into new management groups or tenants; tokens and compliance states may lag.
• For cross-tenant VM/image moves, use snapshots, storage exports, or Compute Gallery rather than trying to move the resource directly.

The documentation does not provide quantified success rates, but the presence of detailed remediation and “rebuild instead of move” guidance indicates that while such migrations are feasible, they require careful planning, service-by-service analysis, and often a combination of subscription transfer and workload re-creation to achieve acceptable downtime and reliability.

References:

• Considerations and recommendations for multitenant Azure landing zone scenarios
• Migrate cloud workloads across security tenants
• Transfer an Azure subscription to a different Microsoft Entra directory
• Azure resource move fails because current tenant isn't authorized for linked subscription
• Transition an existing Azure environment to the Azure landing zone reference architecture