We recently completed a tenant-to-tenant merger (Tenant A into Tenant B) using Microsoft's native migration tools. The technical migration appears successful, but we are now observing anomalous behavior with Conditional Access (CA) policies. Our primary issue is that policies scoped to specific users or groups from the legacy tenant (A) are now either not applying at all or, more concerning, are applying to users who were never members of those original groups in Tenant A.
Our environment:
* Source Tenant (A): Decommissioned, all objects migrated.
* Target Tenant (B): Active, contains all merged objects.
* CA Policies: We migrated 12 policies. 8 work correctly. 4 are problematic.
The most concrete example:
A policy named `CA-Legacy-Contractors` was scoped in Tenant A to a group `G-Legacy-Contractors`. This group contained 45 contractor accounts. Post-migration in Tenant B, the policy (with the same name) is now scoped to the migrated group (same `objectId`). However, the policy is blocking **all** users from a particular legacy application, not just the 45 contractors. The application is correctly assigned in the policy's "Cloud apps" section.
Initial investigation points to the group's membership. In Entra ID, `G-Legacy-Contractors` shows the correct 45 members. But the policy's effect suggests the evaluation engine might be using a stale or incorrect security principal mapping.
Key questions for the community:
1. Has anyone encountered a scenario where a CA policy's *effective* scope differs from its *configured* scope post-merge, despite the group object ID remaining consistent?
2. Are there known issues with policy inheritance or precedence after a tenant merger that could cause this "spillover" effect?
3. Beyond the obvious—what is your recommended diagnostic workflow? We've checked:
* Policy state (Enabled/Report-only).
* Group membership.
* Sign-in logs (which confirm the policy is being applied to non-members).
We are considering exporting all policy JSON definitions and comparing them against a pre-migration backup, but suspect the issue may be deeper in the authorization evaluation chain. Any insights on tools or logs (beyond the standard Sign-in logs) that could reveal the mapping discrepancy would be invaluable.
Less spend, more headroom.