Azure CSP to EA Migration: Tenant-to-Tenant Subscription Migration Complete Guide
Migrating Azure subscriptions from a Cloud Solution Provider (CSP) agreement to an Enterprise Agreement (EA) — or from one tenant to another — is one of the most complex operations in enterprise Azure management. Unlike a workload migration, this is an identity and billing layer change that affects every resource in the subscription. Done correctly, it is achievable with minimal disruption. Done incorrectly, it causes downtime, broken resource dependencies, and authentication failures that take weeks to remediate.
What CSP to EA Migration Actually Involves
A CSP subscription is owned by the CSP partner — your Microsoft Partner. It lives in the CSP partner's billing structure and may live in the partner's Entra tenant or your own tenant, depending on the CSP model (direct vs. indirect, partner-managed vs. customer-managed). An EA subscription lives in your organisation's EA enrollment and your Entra tenant.
The migration transfers subscription ownership from the CSP billing structure to the EA enrollment. If the subscription is also moving between Entra tenants (Tenant A to Tenant B), there is an additional identity migration layer on top of the billing transfer.
What Can and Cannot Be Moved
Understanding the resource portability constraints upfront prevents the most common migration failures.
Resources that move cleanly with subscription transfer: Most IaaS resources (VMs, storage accounts, VNets, load balancers), PaaS services (App Service, Azure SQL, AKS clusters), Key Vault instances, and most Azure resource types that are not tied to Entra identity at the resource level.
Resources that require special handling: Resources using managed identities (the identity is tied to the source tenant and must be recreated in the destination tenant), RBAC assignments (all role assignments are lost on tenant transfer and must be recreated), Azure AD-integrated resources (App Registrations, Service Principals used by resources), and Key Vault access policies (tenant-specific and lost on transfer).
Resources that cannot move: Azure Active Directory Domain Services, Azure DevOps organisations bound to the source tenant, and some marketplace resources with tenant-bound licensing.
Migration Strategy
The recommended approach for most CSP to EA migrations is a phased resource migration rather than a subscription transfer, particularly when a tenant change is involved. Transfer the subscription at the billing level first to move to EA billing, then migrate workloads to new subscriptions in the destination tenant using Azure Resource Mover, manual redeployment, or infrastructure-as-code re-deployment.
Pure subscription transfer (without resource migration) is viable when remaining in the same tenant and the only change is the billing agreement. This is the low-risk path — resources stay in place, only the billing context changes.
Identity Migration
Identity migration is the hardest part of tenant-to-tenant moves. Every service principal, managed identity, and app registration in the source tenant must be recreated in the destination tenant. There is no automated tool that handles this end-to-end — it requires a systematic inventory of identity dependencies before migration begins.
Document all managed identity assignments before migration starts. After the move, recreate managed identities in the destination tenant, reassign RBAC roles, and update any Key Vault access policies or secrets that reference the old identity.
Downtime Planning
For subscription transfer without resource migration: near-zero downtime if identity dependencies are handled correctly. For resource migration across tenants: plan for maintenance windows per workload, starting with non-critical systems to validate the migration process before moving production workloads.
Common Mistakes That Cause Failed Migrations
- Not inventorying managed identity dependencies before starting — discovered post-migration, these cause authentication failures across multiple services simultaneously
- Forgetting RBAC assignments — all custom role assignments are lost on tenant transfer; document them before and recreate immediately after
- Missing Key Vault access policies — if applications use Key Vault access policy model (not RBAC), policies reference source-tenant object IDs that are invalid after transfer
- Not testing DNS resolution post-migration — private endpoint DNS entries may need to be recreated in the destination environment
- Insufficient rollback planning — define the rollback procedure before starting; subscription transfers can be reversed in a limited window
