What to Expect When You're Expecting Direct CSP with Microsoft

More and more, I'm finding that I'm getting asked a series of similar questions when a customer decides to pick up a Cloud Solution Provider or switches between a Cloud Solution Provider for Microsoft. It starts with a: "What happens to our tenant? Do we lose our identities? Does someone have to rebuild Entra ID?"

The short answer is no. The longer answer is the rest of this post, because while nothing dramatic happens to your tenant, plenty of small things change at the billing, permissions, and support layers, and a few of them will bite you later if nobody cleans anything up. So think of this as the what-to-expect-when-you're-expecting version. The baby (your tenant) is fine. It's the paperwork, access lists, and quota limits that need attention.

First, what does not change

Your Microsoft Entra tenant belongs to you, not the partner. Changing CSP partners does not move the tenant, delete it, or rebuild it. Specifically, these Entra ID things all stay exactly where they are:

• Users, groups, service principals, and managed identities

• Conditional Access policies, named locations, authentication methods

• Your domains, DNS, and federation config

• All of your data in Exchange, SharePoint, Teams, and OneDrive

• Your Azure resources, resource groups, RBAC assignments, and policy assignments (the lone caveat is if you're moving TO a direct CSP - I'll cover that later in the post)

• License assignments and quantities on your users (a partner transfer changes billing ownership only, not what is assigned in the tenant)

  
  

If you came in expecting an identity migration project with a cutover weekend and a rollback plan, relax. There is no identity migration. The tenant is the constant!

What actually changes

Three things move when you switch partners, and they are more independent of each other than most people assume:

1. Billing ownership: Who Microsoft invoices, and who in turn invoices you.

2. The support relationship: Who you call when something breaks, and who can open a ticket with Microsoft on your behalf.

3. Delegated admin access: Which partner can administer your tenant, and at what privilege level.

   
   

The trap is treating these as one switch. They are three separate switches, owned by different processes, and torn down by different steps. A partner can keep administering your tenant long after they stop billing you, simply because nobody removed their access. Let's walk through each thing next.

Untangling Entra, subscriptions, and RBAC (the part that trips everyone up)

Before the mechanics, it is worth slowing down on the model, because almost every confused question I get about CSP comes from running three different things together that all sound like "permissions." If you can mentally get these three separated, the rest of this post stops being mysterious.

• Layer one

  • Entra ID is your directory. It is the list of who: the users, groups, service principals, managed identities. You have exactly one tenant, and it's yours. It does not belong to the partner, and a CSP change does not move, copy, or rebuild it.

    
    

• Layer two

  • Azure RBAC is the access list attached to your Azure resources. A role assignment is three parts bolted together: an identity (a security principal from Entra), a role definition (what they can do), and a scope (where, meaning a management group, subscription, resource group, or resource). RBAC lives with the resource in Azure Resource Manager, not in Entra. This matters enormously during a move, and I will come back to this concept.

• Layer three

  • Delegated permission (GDAP and AOBO - we'll cover those later in this post) is the partner's administrative access into your tenant. This is not your users' access to resources. It's a completely separate grant that lets an outside party administer your environment. Lumping it in with the first two layers is where everyone gets lost.

One tenant, and every subscription trusts it

Here is the glue: Every Azure subscription, regardless of how it is billed (pay-as-you-go, EA, or CSP), trusts exactly one Entra tenant for sign-in. When your new partner provisions CSP subscriptions for you, those subscriptions are created in your Entra tenant, not the partner's. Your users, groups, and their object IDs are unchanged. The subscription is just a billing-and-resource container that points at the directory you already have.

This is the single most common misconception: people picture new CSP subscriptions living inside the partner's tenant, with their users somehow needing to reach across and access their environment. That is backwards. Your subscriptions sit in your tenant. Your people get access to them the normal way, entirely inside your own directory. Nobody from your side ever needs an account in the partner's tenant.

So which direction does the delegation flow?

From the partner into you, never the other way. The partner's tenant is just where their admin agents live. The delegation is what lets their team reach into your tenant to manage things on your behalf.

There are two mechanisms, and they map to the two doors in the next section:

• GDAP grants the partner time-bound Entra roles inside your tenant, for Microsoft 365 and Entra administration.

• AOBO (Admin On Behalf Of) is the Azure equivalent. When the partner provisions a CSP Azure plan subscription, their Admin Agents group is automatically granted the Owner role on that subscription. It shows up in your tenant as a foreign principal, an object representing the partner's Admin Agents group from their directory. That foreign principal is how the partner manages and assigns access on your Azure resources. (Azure Lighthouse is the more granular, least-privilege alternative to default AOBO, covered below.)

  
  

One detail worth knowing because it surprises people: by default that AOBO foreign principal holds Owner, and your own Global Admin does not automatically have rights on those CSP subscriptions until someone assigns them. You can grant your own users RBAC on the subs, and you can remove or downgrade the partner's AOBO access at the subscription, resource group, or resource level. That trim-down is a good least-privilege habit, and it is part of the cleanup checklist later.

Why "assignment of access" splits two ways

Put it together and "who assigns access, and to whom" has a clean answer, and both halves happen inside your tenant:

• Your own users get RBAC on your subscriptions the ordinary way: their Entra identities, bound to roles, at a scope in your subscriptions. Nothing cross-tenant.

• The partner's team gets RBAC through the delegation: the Admin Agents foreign principal (AOBO) or a Lighthouse assignment. That is what lets them assign and manage on your behalf.

  
  

The analogy that Hopefully makes it Click

Entra is your badge system, the one set of employee badges your company issues. A subscription is a building. RBAC is the door-access list posted inside each building, saying which badges open which doors. GDAP and AOBO are contractor badges you hand an outside firm so they can work in your buildings.

Now the CSP part: even the new buildings the partner sets up for you sit on your campus (your tenant), not theirs. Your employees use their normal badges on their own campus. You issue the partner contractor badges that work on your campus, and their staff badge into your buildings to do the work. Nobody from your side ever needs a badge to the partner's campus. When you change partners, you collect the old firm's contractor badges and issue new ones. The buildings, the employees, and the badge system never moved.

The one place this analogy bends is the PAYG migration further down: there, you are not just changing the contractor, you are physically moving everything into a brand new building, and the door-access lists do not come with it. More on that when we get there.

The two access models you will deal with

When a partner manages a Microsoft environment, their standing access usually comes through one of two doors, sometimes both. You need to know about both, because they live in different portals and get removed in different places.

Door one: GDAP (your tenant and Microsoft 365)

Granular Delegated Admin Privileges (GDAP) is the current model for partner administration of your Entra tenant and M365 workloads. It replaced the old DAP model, which handed partners standing Global Admin and became a genuine security liability. Microsoft already ran a Microsoft-led transition from DAP to GDAP and removed DAP, so in practice your old partner's tenant access today is GDAP.

A few properties of GDAP that matter during a partner switch:

• GDAP is time-bound. Each GDAP relationship has a fixed duration (up to two years), and every role in that relationship expires at the same time. So it will eventually lapse on its own. I'd recommend not waiting for that.

• It is per-customer and stackable. A partner can hold multiple GDAP relationships with you, each with different Entra roles. When you audit, look for all of them, not just one.

• It is separate from billing. Removing GDAP does not end the reseller relationship, and removing the reseller relationship has no effect on existing GDAP. You have to deal with both.

  
  

Door two: Azure Lighthouse (your Azure resources)

Azure Lighthouse is the other door, and it's the one people forget. If your old partner managed Azure resources (monitoring, CSPM, patching, cost work), they may have onboarded your subscriptions or resource groups as Lighthouse delegations. This is completely independent of CSP and GDAP. It is delegated resource management at the Azure control plane, and it persists on its own schedule.

You can see every active delegation yourself. In the Azure portal, search for Service providers, open Service provider offers, and you will see each managing tenant, the offer name, the roles they were granted, and how many subscriptions or resource groups are in scope. This view is yours as a customer, and you do not need the partner's cooperation to read or remove it.

What can transfer, and the tool that Completes the Task

For the billing side, Microsoft supports a real partner-to-partner subscription transfer. These two categories are transferable:

• Azure plan items (your Azure consumption subscriptions under CSP)

• New Commerce Experience (NCE) license-based subscriptions (M365, O365, Teams, Defender, Entra ID P1/P2, and so on)

  
  

Legacy (pre-NCE) subscriptions are not part of the modern transfer tool and follow the older legacy transfer path, which usually means letting them lapse and re-provisioning under the new partner.

The transfer mechanics are worth understanding before you commit to a date, because the process has guardrails:

• The target (new) partner initiates the transfer, not you. The customer accepts a relationship request, then the new partner sends the transfer request to the source partner.

• Both partners have to agree. The source partner has to approve the transfer, and the target can cancel it if they don't. Neither partner is obligated to do this, so get alignment in writing early.

• You need a Microsoft Customer Agreement (MCA) on file and an active relationship with the new partner before the transfer can run.

• The transfer creates new subscriptions under the new partner at the original price, and the target inherits the remaining term and the original cancellation policy.

• Mid-term billing is split. The source partner is responsible up to the transfer date, the target from then on.

• A transfer does not open a new seven-day cancellation window, and there is a per-request item limit (25), so large estates get batched.

  
  

Net result for license-based subs: your users keep their licenses and assignments throughout. The change is purely who owns the subscription and bills you.

Know which lane you are in

Everything above assumes your Azure subscriptions are eligible for a billing-ownership transfer. That eligibility depends entirely on what agreement you are coming from, and this is where people get burned. There are three lanes:

• CSP to CSP (partner-to-partner) - This is the transfer tool above. Subscription and resource IDs are preserved, so that makes this the easy lane.

• EA or MCA-enterprise to CSP - Supported as a billing transfer, but only when the customer has accepted an MCA and the partner has set up an Azure plan, and only a CSP direct-bill partner certified as an Azure Expert MSP can request this transaction. IDs are preserved here too, and services keep running with no interruption.

• Pay-as-you-go (MOSA/MOSP) to CSP - This is not eligible for a billing transfer at all. This is a different and much bigger job...keep reading...to the next little section.

If you are coming from PAYG, this is a resource migration, not a transfer

This is the case that trips up first-time CSP customers, and it's exactly the situation when you are leaving a direct Microsoft pay-as-you-go relationship to go all-in with a CSP provider. Standard pay-as-you-go (the Microsoft Online Subscription Agreement, offer MS-AZR-0003P, sometimes called MOSP) is not on the supported list for billing-ownership transfer into CSP. Microsoft is explicit that for these offers it does not support the transfer, so you must move the resources yourself.

The shape of the project is completely different from a transfer:

1. Your new partner creates a fresh CSP Azure plan subscription in your tenant.

2. You move your resources (or redeploy as a number of PaaS resources do not support a migration) out of the PAYG subscription and into the new CSP subscription).

3. Once everything is moved and verified, you decommission and cancel the old PAYG subscription.

   
   

This is partner-plus-customer work. No Microsoft representative does the work for you, and it's not a background billing flip. A few hard constraints up front:

• Both subscriptions must live in the same Entra tenant. The move operation does not support moving resources to a new tenant. And the change-directory option is not supported on a CSP subscription, so if a directory change is needed, you change the PAYG subscription's directory to match before you start, not the CSP tenant.

• You get a new subscription ID, and your resource IDs change. A resource ID is /subscriptions/{subscriptionId}/resourceGroups/{rg}/providers/..., so moving across subscriptions rewrites the subscription portion of every resource ID. This is the single biggest difference from a billing transfer (where IDs are preserved) and it has specific effects covered below.

  
  

What moves, what breaks, what gets rebuilt

The resource itself is not redeployed during a move, but because the resource ID changes, anything that references the old ID by its full path needs updating, and some resource types cannot move at all.

Here's what moves cleanly (with ID rewrites you have to chase down): most IaaS (VMs, disks, NICs, NSGs, public IPs of matching SKU), storage accounts, most networking, and many PaaS services. Child resources move with their parent automatically.

Here's what breaks or needs to be rebuilt:

• RBAC role assignments and policy assignments do not travel with the resource. They are scoped to the old resource path. After the move you reassign roles and reapply policy at the new scope. Make sure to budget time for this task.

• Diagnostic settings, alerts, action groups, and dashboards that point at the old resource IDs go stale. Re-point them after the migration.

• Anything that hardcodes resource IDs: IaC state (Terraform state, Bicep what-if baselines), private endpoint references, Key Vault references, automation runbooks, and CI/CD pipeline variables. Make a sure to plan a sweep.

• Resource types that flat out do not support a cross-subscription move, which you must recreate on the target side. The current list is in Azure resource types for move operations, and it includes gotchas like a VNet-integrated Azure Cache for Redis, Consumption-tier API Management, and certain Recovery Services vault configurations, among others. Check the move-support table before you commit to a cutover plan, not after.

• Application Insights resource IDs change on move, which splits telemetry continuity: prior data stays queryable only via the underlying Log Analytics workspace, not the moved resource.

  
  

One more reset: make sure the new subscription's quota can hold what you are moving. A new CSP Azure plan starts at default limits, so capture your PAYG quotas first and have the partner raise them on the target before you move compute in.

The tool

For a same-region PAYG-to-CSP move, the native move operation is the tool (portal, PowerShell, CLI, or REST). Azure Resource Mover is the better choice when the move also crosses regions or when you want its dependency mapping and test-move features, but for a straight billing-driven move in the same region you do not need it.

During the move, both the source and target resource groups are locked: you cannot create, delete, or modify resources in them until it completes, though existing resources keep running with no downtime. Move in batches by resource group so a single lock window does not freeze your whole estate.

Commands for the PAYG move

Confirm both subscriptions are in the same tenant before anything else:

az account show --subscription "<paygSubId>" --query tenantId -o tsv
az account show --subscription "<newCspSubId>" --query tenantId -o tsv
# These two must match.

Move a set of resources to the new subscription (target resource group must already exist there):

az resource move \
  --destination-subscription-id "<newCspSubId>" \
  --destination-group "<targetResourceGroup>" \
  --ids \
    "/subscriptions/<paygSubId>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>" \
    "/subscriptions/<paygSubId>/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>"

Validate eligibility first. The portal runs validation automatically before a move, and you can call the validateMoveResources REST action to check a batch programmatically before you trigger anything. Either way, cross-reference the move-support table so nothing surprises you mid-cutover.

When to migrate (timing is the whole game on the M365 side)

The Azure plan side is flexible because Azure is consumption-billed monthly, so you can move without fighting a commitment term. The license side is where timing matters, and it comes down to NCE terms. NCE subscriptions carry a committed term (monthly, annual, or triennial) with a hard seven-day cancellation window that only opens at purchase or at renewal, not at transfer.

This means that:

• If you are mid-term on annual subscriptions, a transfer carries that commitment to the new partner. You are not escaping the term by switching, you are just changing who invoices the charge.

• The clean break points are renewal dates. Lining the partner change up with your renewal anniversary avoids inheriting awkward partial terms and gives the new partner a natural point to right-size quantities.

• If you have mixed renewal dates across subscriptions, expect to either batch transfers or accept a staggered cutover, which is all normal.

My rule of thumb: move Azure plan whenever it suits the project, and align the M365 license move to your largest renewal date unless there is a pressing reason to transfer mid-term. I believe this saves a lot of heartaches and corresponding headaches.

What gets rebuilt or reset (the gotchas)

Most things survive, but a handful do not, and these are the surprises as of June 2026:

• Azure quota can reset, which is a big one. After a subscription transfer, if you never had quota increases applied, your quota resets to the CSP default limits. Increases that were previously granted on an EA or MCA subscription carry over, but anything riding on defaults can drop back down. If you run anything compute-heavy, capture your current vCPU and SKU-family quotas before the move so you can request them back. And note the request now has to go through your CSP partner, not you (more on that below).

  
  

• Your support entitlement changes hands. In CSP, the partner owns the support relationship. When you switch, your support path switches as well. Any Professional Direct or premium support arrangement you had through the old partner does not automatically follow you, so confirm what the new partner provides ahead of the migration.

  
  

• Partner-deployed tooling does not migrate. Anything the old partner stood up inside your tenant stays where it is and keeps running until removed: their Lighthouse offers, any enterprise applications or service principals they registered (RMM agents, security scanners, automation identities), and any Conditional Access exclusions you created to let their CSP identities through. None of this transfers to the new partner, and all of it is now orphaned access you will want to clean up.

  
  

• New Azure subscriptions provision under the new billing scope. If you are not transferring existing Azure plan subscriptions but creating fresh ones under the new partner, they land under a new Azure plan billing scope. This is where subscription vending earns its keep. The Azure Verified Modules for vending (Bicep and Terraform) let you provision and govern new subscriptions at scale, and the parameter that changes after a partner switch is the billing scope you point them like this:

module "lz_vending" {
  source  = "Azure/avm-ptn-sub-vending/azurerm"
  version = "<version>"

  # This is the value that changes under a new partner's Azure plan.
  # Point it at the new partner's billing account / profile / customer scope.
  subscription_billing_scope = "/providers/Microsoft.Billing/billingAccounts/<id>/billingProfiles/<id>/customers/<id>"

  subscription_alias_enabled  = true
  subscription_display_name   = "workload-prod"
  subscription_workload       = "Production"
  # management group placement, networking, RBAC, RP registration...
}

Note that creating subscriptions through vending needs the Subscription Creator role, which is a billing-scope role rather than a normal Azure RBAC role, and your new partner controls that scope. So this is a coordinate-with-the-partner step, not a do-it-solo step.

How tickets and quota work after the move

This catches first-time CSP customers off guard, so it is worth being blunt: under CSP, you cannot open Azure support tickets directly. If you go into the Azure portal and try, you will get a message telling you the subscription is CSP-managed and support must go through your managing partner.

How this process actually works:

• For Azure technical support, only the CSP Direct-Bill partner or Indirect Provider that supplies the subscription can open the request, using their own RBAC. Indirect resellers route through their distributor.

• The partner accesses your environment through Admin On Behalf Of (AOBO) from Partner Center, or files the request through Partner Center on your behalf.

• Quota increases are the same story. A vCPU bump or a regional capacity request goes through your partner, who submits the Service and subscription limits (quotas) support request from the AOBO context.

• Microsoft talks to the partner, the partner talks to you. Even during escalations, you are not in the direct loop with Microsoft support.

  
  

So part of choosing a new partner is choosing your support desk. Ask about response times, escalation paths, and whether they actually staff Azure depth or just resell. That conversation matters more than the margin on your licenses.

The cleanup checklist (this is the security work - Your Security Teams will Love You if You Follow these Steps)

Here is the part nobody checks and everybody should. Once the new partner is in place, your old partner's access does not evaporate (so this checklist is only relevant if you're moving Direct CSP partners). Audit and remove these pieces so you treat it as offboarding a privileged third party, because that's effectively what it is.

1. Remove the old GDAP relationships. In Partner Center the old partner can remove themselves, but you do not have to wait on them. As the customer you can review and act on partner relationships from the Microsoft 365 admin center under Settings > Partner relationships.

2. Remove the old reseller relationship if it still lingers. Remember this is separate from GDAP and removing one does not remove the other.

3. Remove old Azure Lighthouse delegations (see commands below).

4. Check for the old partner's AOBO foreign principal on your Azure subscriptions. On any subscription the old partner provisioned, their Admin Agents group may still hold Owner as a foreign principal. Review your role assignments for a principal shown as "Foreign Principal for ..." and remove the old partner's if it lingers (this does not apply to PAYG subs you are cancelling anyway).

5. Audit enterprise applications and service principals in Entra ID. Look for anything the old partner registered: automation identities, monitoring connectors, security agents. Disable or delete what is no longer needed.

6. Clean up stale Conditional Access exclusions. If you excluded the old CSP from a CA policy to let their GDAP through, remove that exclusion and add one for the new partner only if required.

7. Recapture and re-request quotas that may have reset to CSP defaults.

   
   

Commands you can actually run

You can do most of the verification and Azure-side teardown yourself. None of this needs the old partner's cooperation.

See every Azure Lighthouse delegation on a subscription:

az login
az account set -s "<subscriptionId>"

# List delegations (registration assignments) on the current subscription
az managedservices assignment list -o table

Remove a specific delegation (you need a role with Microsoft.Authorization/roleAssignments/delete, such as Owner, or the Managed Services Registration Assignment Delete role):

az managedservices assignment delete --assignment `
"<assignmentId or full resourceId>"

Microsoft documents this same flow in Remove access to a delegation. You can also handle this in the portal under Service providers > Service provider offers with the trash can icon on the row.

Audit Lighthouse delegations across the whole tenant with Azure Resource Graph (good for catching delegations you forgot existed):

resources
| where type =~ "microsoft.managedservices/registrationassignments"
| extend managingTenantId = tostring(properties.registrationDefinition.properties.managedByTenantId)
| extend offerName = tostring(properties.registrationDefinition.properties.registrationDefinitionName)
| project subscriptionId, managingTenantId, offerName, id

Run that in the Resource Graph Explorer and you should get every managing tenant touching your environment in one pass. Anything pointing at the old partner's tenant ID is a delegation to remove.

List service principals to spot partner-registered apps (Microsoft Graph PowerShell, then filter to what you recognize):

Connect-MgGraph -Scopes "Application.Read.All"

Get-MgServicePrincipal -All | Select-Object ` 
DisplayName, AppId, PublisherName, AppOwnerOrganizationId | `
Sort-Object DisplayName

The AppOwnerOrganizationId is the lever here. Service principals owned by the old partner's tenant ID are the ones to scrutinize before you disable them.

Surface the partner's AOBO foreign principal (the Admin Agents group holding Owner on a CSP subscription shows up as a ForeignGroup principal):

az role assignment list \
  --scope "/subscriptions/<subscriptionId>" \
  --role "Owner" \
  --query "[?principalType=='ForeignGroup']. \{principal:principalName, type:principalType, id:principalId}" \
  -o table

If a foreign principal mapping to the old partner is still there and you have moved on, remove it with az role assignment delete against that assignment. Note that removing it cuts the old partner's standing Azure access entirely, so only do this once the new partner is fully in place.

The short version

A CSP partner change is not a tenant migration. Your identities, data, and config are constants. What moves is billing ownership, the support relationship, and delegated admin, and those three are independent switches you have to flip separately. The one place this stops being easy is if you are coming from pay-as-you-go: PAYG cannot be billing-transferred into CSP, so that lane is a real resource migration into a new subscription, with a new subscription ID, changed resource IDs, reassigned RBAC and policy, and rebuilds for anything that cannot move. Plan that one like a project.

For everything else: align the M365 license transfer to a renewal date, move Azure plan whenever it suits you, expect quota to possibly reset to CSP defaults, route all your support and quota requests through the new partner, and then do the unglamorous part: rip out every scrap of the old partner's access across GDAP, the reseller relationship, Lighthouse, enterprise apps, and Conditional Access. That cleanup is the actual project. Everything else mostly takes care of itself.