• Azure Resource and Subscription Moves: What Does—and Does Not—Move Automatically

  Moving Azure resources between resource groups or subscriptions can appear straightforward: select the resources, choose Move, identify the destination, and allow Azure to validate the request.

  The difficult part is not initiating the move. It is understanding everything surrounding the resources—role assignments, managed identities, dependencies, logging, policies, and billing relationships—that might not follow automatically.

  Here are several important considerations.

  1. Azure RBAC Role Assignments Do Not Move Automatically

  If an Azure role assignment is applied directly to a resource—or to one of its child resources—the assignment does not move with that resource.

  After the resource moves, the original assignment becomes orphaned because its scope still references the old resource ID. Azure eventually removes the orphaned assignment, but Microsoft recommends deleting it before beginning the move. The required role assignments must then be recreated at the destination.

  Before moving resources:

  • Export all role assignments applied at the resource and child-resource levels.
  • Record the principal, role definition, scope, and any assignment conditions.
  • Remove assignments that will become orphaned.
  • Recreate the assignments against the new resource IDs after the move.
  • Validate that users, groups, service principals, and managed identities still have the intended access.

  Inherited permissions require separate consideration. If a resource moves into a different resource group or subscription, it begins inheriting RBAC assignments from its new hierarchy. This can result in either lost access or unintended additional access.

  Also remember that when resources are moved to a newly created resource group, the source resource group’s tags, policies, locks, and role assignments are not automatically copied to the destination resource group.

  2. Managed Identities Are Not Simply Portable Resources

  Managed Service Identity, or MSI, is now called Managed Identity. Its behavior depends on the identity type.

  A system-assigned managed identity is tied directly to the lifecycle of its Azure resource. It is not an independent resource that can simply be selected and moved to another resource group. When moving the parent resource, validate the service-specific move behavior and confirm afterward that the identity remains functional.

  A user-assigned managed identity is represented as a standalone Azure resource, but that does not mean it supports a standard move. Microsoft currently states that moving a user-assigned managed identity to another resource group or subscription is not supported. The normal approach is to create a new identity at the destination, attach it to the appropriate resources, and recreate its permissions.

  The process generally includes:

  1. Inventorying every managed identity used by the resources being moved.
  2. Recording the identity’s client ID, principal ID, resource associations, federated credentials, and role assignments.
  3. Creating replacement user-assigned identities where required.
  4. Attaching the new identities to the destination resources.
  5. Recreating Azure RBAC assignments, Key Vault permissions, database permissions, and application-specific authorization.
  6. Updating automation, templates, policies, and application settings that reference the old identity.
  7. Testing token acquisition and access to downstream services.

  If the subscription is being transferred to a different Microsoft Entra directory, the impact is greater. Managed identities must be recreated, their role assignments restored, and their downstream access re-established because managed identities do not work across Microsoft Entra tenants.

  3. Understand the Different Log Analytics Export Limits

  The often-mentioned 30,000-row limit should not be interpreted as a universal limit on exporting a Log Analytics workspace.

  Several different export mechanisms exist, and they have different behaviors:

  • Interactive portal exports may limit or truncate the results displayed or exported by the user interface.
  • Query-based exports are subject to Azure Monitor Logs query limits.
  • The Logic Apps Log Analytics connector can return up to 500,000 rows or 64 MB per query, whichever limit is reached first.
  • Log Analytics Data Export rules continuously stream newly ingested data from selected tables to Azure Storage or Event Hubs.
  • Continuous Data Export does not automatically export historical workspace data that existed before the rule was enabled.

  Microsoft describes continuous Data Export as a pipeline-based export of new table data as it arrives. Query-based exports can retrieve historical data, but they are subject to query limits and are not intended for large-scale bulk extraction.

  For a large workspace migration or archival requirement, do not depend on a single portal CSV download. Instead:

  • Identify the required tables and retention period.
  • Determine whether historical data or only future data must be exported.
  • Split historical queries into manageable time windows.
  • Export to an appropriately sized storage account.
  • Validate row counts, file sizes, timestamps, and ingestion coverage.
  • Consider continuous Data Export for future data.
  • Review compliance requirements such as immutability, retention, encryption, and regional storage.

  4. Moving from an EA Subscription to CSP Is Usually a Billing Transition—not Necessarily a Resource Move

  Moving from an Enterprise Agreement subscription to a Cloud Solution Provider arrangement should not automatically be treated as an Azure resource migration.

  In an eligible transfer, the existing subscription can undergo a billing ownership transfer to the CSP partner. The subscription and its resources may remain in place while the commercial and billing relationship changes. However, it is not accurate to say that Microsoft simply “takes ownership” of the new CSP subscription. The CSP partner assumes the applicable billing relationship and management responsibilities under the Cloud Solution Provider model.

  Eligibility depends on the source agreement, the CSP partner’s authorization, acceptance of the Microsoft Customer Agreement, tenant alignment, and other Microsoft requirements. For eligible direct EA or enterprise MCA subscriptions, a billing ownership transfer may be available.

  If the subscription is not eligible for a billing transfer, the organization may need to:

  1. Establish the CSP relationship.
  2. Create a new target CSP subscription.
  3. Ensure the source and target subscriptions use the same Microsoft Entra tenant.
  4. Confirm that every resource type supports a subscription move.
  5. Move supported resources into the target subscription.
  6. Rebuild or migrate resources that do not support a standard move.

  Marketplace products and SaaS subscriptions must also be reviewed separately because they might not transfer with the Azure subscription. Quotas, reservations, savings plans, support arrangements, policies, and cost-management configurations should be validated as individual workstreams.

  5. Dependent Resources Must Be Identified and Moved Together

  For a cross-subscription move, Azure requires a resource and its dependent resources to be in the same source resource group and included in the same move request.

  For example, moving a virtual machine might require moving:

  • The virtual machine
  • OS and data disks
  • Network interfaces
  • Public IP addresses
  • Network security groups
  • Availability sets
  • Load balancer components
  • Related networking resources

  If these components are spread across multiple resource groups, the recommended process is:

  1. Identify the complete dependency chain.
  2. Consolidate the required resources into one source resource group.
  3. Move the resource and its dependencies together into the target subscription.
  4. Redistribute them into the desired target resource groups after the subscription move.

  Microsoft describes this as a three-stage process: consolidate the dependencies, move them together, and then optionally reorganize them at the destination.

  Azure validates dependencies before beginning the move. If a required dependency is missing from the request and is not already present at the destination, the operation can fail with MissingMoveDependentResources.

  6. A Successful Move Does Not Mean the Work Is Finished

  After the move completes, perform a structured validation covering:

  • RBAC assignments
  • Managed identities
  • Azure Policy compliance
  • Resource locks
  • Tags
  • Diagnostic settings
  • Private endpoints and private DNS
  • Network security rules
  • Route tables and firewall policies
  • Key Vault access
  • Backup and disaster-recovery configurations
  • Monitoring, alerts, dashboards, and action groups
  • Automation scripts and infrastructure-as-code references
  • Subscription and resource quotas
  • Cost-management budgets and alerts
  • Application connectivity and authentication

  Azure resource IDs change when resources move between subscriptions, and they also change when the resource-group portion of the ID changes. Any external system, script, dashboard, policy, or application configuration containing the old resource ID must therefore be identified and updated.

  The central lesson is simple: an Azure move is not merely a relocation of resources. It is a controlled transition of resources, identities, permissions, dependencies, operational controls, and—sometimes—billing ownership.

  The Azure portal’s successful validation is only the beginning. A complete migration requires a documented inventory, a dependency map, a permissions-recreation plan, and thorough post-move testing.

The post Moving Resources across Subscriptions – Notes from the Field appeared first on Azure Security Architect.