Conditional Access does not migrate — you rebuild it, and the order matters
The mailboxes move, the users move, and the access rules that were quietly enforcing MFA and blocking legacy sign-ins stay behind in the old tenant — so the day identities arrive is the day the estate is wide open unless you rebuilt those policies first.
New to cloud? CAMPUX is a free, build-first course. Start here →
Moving people between tenants feels like a data problem right up until you notice the guardrails did not come along. This note is part of the Azure tenant-to-tenant migration guide, and it covers the piece that gets forgotten because it is invisible when it works: Conditional Access. A policy in the source tenant is an if-then rule — if this user, on this network, from this app, then require MFA or block. (If the line between the policy and the MFA it enforces is fuzzy, Conditional Access vs MFA draws it cleanly.) When the identities land in the target, none of those rules exist yet. Sign-ins that were protected yesterday are unprotected today, and nobody sees it because access still works. It works too well.
Why the policy stays behind
Conditional Access lives inside the tenant that owns it, and it does not follow an identity across the boundary. There is no clean export that carries a working policy from one tenant into another, and the reason is mechanical rather than a missing feature. A policy references its assignments by object (a security group, a named location, an app registration), and each of those is identified by an object ID that only exists in the tenant that created it. Copy the JSON of a source policy into the target and it points at groups and apps that are not there. The rule is real; everything it aims at is a dangling reference. So you do not migrate Conditional Access. You rebuild it, deliberately, in the target tenant.
Recreate what the policies point at, first
A Conditional Access policy is only as portable as its dependencies, and it has three kinds worth naming. Assignments target users and groups — and the practice that survives a migration is assigning by group, never by individual user, so the policy keeps working as membership changes rather than pointing at named people who may not exist yet. Conditions reference named locations, the trusted IP ranges for your offices and VPN egress. Target resources reference cloud apps — enterprise applications and app registrations. All three have to exist in the target before a policy can bind to them. Build them in this order: the security groups first, then the named locations, then the app registrations, and only then the policies that stitch them together. Skip ahead and you get a policy that saves but silently applies to nothing.
A rule that points at a group which does not exist yet is not protection. It is a saved intention, and attackers do not respect intentions.
Report-only mode is how you avoid the self-inflicted lockout
A rebuilt policy is a fresh guess about a tenant whose device posture, network shape, and app inventory are not identical to the old one. Enforce it blind and you find the mistakes in a flood of help-desk tickets. Report-only mode is the alternative: the policy evaluates against real sign-ins and writes what it would have done into the sign-in logs, without granting or blocking anything. You turn each new policy on in report-only, let live traffic run through it, and read the logs. If a policy that should require MFA for a group is quietly matching the wrong population — or matching nobody — the logs show it before a single user is affected. Only when the report-only results look right do you flip the policy to enforce.
Keep at least two break-glass accounts — cloud-only, high-privilege, emergency-access — and exclude them from every Conditional Access policy you build in the target, including the MFA and location rules. The point is blunt: if a rebuilt policy is wrong and locks out your admins, the excluded accounts are how you get back in to fix it. Set up and exclude these accounts before you enable a single policy, not after the lockout. A policy you cannot reverse is not a control, it is a trap you built for yourself.
Sequencing so nobody is locked out on switch day
Order is the whole game here. Do the rebuild ahead of cutover, not during it. Recreate the groups, named locations, and apps in the target; create the policies in report-only mode and exclude the break-glass accounts; run a pilot group of real users through the target and read the sign-in logs until the report-only verdicts match your intent. Then, before or at the moment identities cut over, move the validated policies from report-only to enforce so protection is live the instant users arrive rather than switched on days later after someone notices MFA never prompted. The failure mode to design against is the gap — the window where identities exist in the new tenant and no policy governs them. Good sequencing closes that gap to zero.
The takeaway
Conditional Access does not travel with your users, because every policy points at groups, locations, and apps that live only in the tenant that made them. You rebuild in the target, and the order is not optional: dependencies first, policies in report-only mode, break-glass accounts excluded, validate against live sign-in logs, then enforce timed to cutover. "The policies stayed in the old tenant, so I recreated the groups and named locations, validated in report-only, kept two break-glass accounts excluded, and flipped to enforce on switch day" is how you close the exposure window to zero, and it is the kind of sequencing you only plan carefully after you have watched an estate sit unprotected over a weekend.
Questions people also ask
Do Conditional Access policies migrate between tenants?
No. Conditional Access policies live in the tenant that owns them and do not follow identities to a new tenant. There is no export-and-import that carries a working policy across the boundary intact, because a policy points at groups, named locations, and app registrations by object ID, and those IDs only exist in the tenant that created them. You rebuild the policies in the target.
How do I move Conditional Access policies to a new tenant?
You recreate them, in order. First rebuild the dependencies the policies reference: the security groups used in assignments, the named locations for trusted IP ranges, and the app registrations or enterprise apps you target. Then create each policy in report-only mode pointing at the new objects, watch the sign-in logs to confirm it behaves, and only then flip it to enforce.
What is report-only mode in Conditional Access?
Report-only mode evaluates a policy against real sign-ins and records what it would have done in the sign-in logs, without actually granting or blocking anything. It lets you validate a freshly rebuilt policy in the new tenant against live traffic before it can lock anyone out. Run every new policy this way first and read the logs before you enforce.
Should break-glass accounts be excluded from Conditional Access?
Yes. Keep at least two emergency-access, or break-glass, accounts excluded from every Conditional Access policy, including MFA and location policies. If a rebuilt policy is wrong and locks out your admins, these excluded accounts are how you sign in and fix it. Exclude them in the new tenant before you enable a single policy, not after.
What breaks first after a tenant-to-tenant migration if you forget Conditional Access?
Access control. Users land in the new tenant with no MFA requirement, no device or location restrictions, and no block on legacy authentication, because the policies that enforced all of that stayed behind. Until you rebuild them, the estate is wide open. Rebuild the policies before cutover so protection is live the moment identities arrive, not days later.