The safest approach is to treat this as a cutover, not a long-running dual-tenant migration. Short version: 1. Keep at least one Owner who can still get in if SSO breaks. 2. Recreate the SSO + SCIM app in the new Azure tenant. 3. Mirror users/groups in the new tenant before switching. 4. Cut over SSO first, then enable SCIM from the new tenant. 5. Validate group/team sync and access immediately after. A few important constraints in Prefect Cloud: - SSO is configured at the account level. - Prefect does not support running two active IdPs/tenants in parallel for the same account. - If SCIM is enabled, teams/group membership are governed by the IdP. - Owners can bypass SSO; Admins cannot. That bypass is your recovery path. Relevant docs: - Configure SSO - Manage teams - Manage roles - Audit logs Recommended migration plan 1. Prepare the new tenant first - Create the Prefect app in the new Azure tenant. - Recreate the same user and group assignments there. - Make sure the Azure groups match the team structure you want in Prefect. - Record current access/teams/roles before touching anything. 2. Ensure you have a recovery account - Confirm at least one Prefect Owner can bypass SSO. - Ideally, that account should still be usable even if the SCIM/SSO switch goes sideways. 3. Pause old SCIM provisioning - Before cutover, stop provisioning from the old Azure tenant. - This avoids churn while you switch identity sources. 4. Cut over SSO - Update Prefect Cloud’s SSO configuration to use the new tenant’s IdP setup. - Test login with a small pilot group first if possible. 5. Enable SCIM from the new tenant - Once SSO is confirmed working, enable SCIM provisioning from the new tenant. - Verify users are provisioned and groups/teams appear as expected. 6. Validate immediately Check: - users can sign in - correct users are provisioned - expected teams/groups are synced - no critical users lost access - service accounts still work Main risks to watch for - User lockout: if users are removed from the old app before they exist in the new one. - Team drift: SCIM-managed teams come from the IdP, so mismatched Azure groups will change team membership. - Provisioning timing: SCIM sync may not be instant. - Deprovisioning effects: unassigning users from the Azure app can remove their access quickly. Best practice on sequencing If you want the lowest-risk sequence, I’d suggest: 1. Build and validate SSO config in new tenant 2. Confirm fallback Owner access 3. Freeze/disable old SCIM changes 4. Switch SSO to new tenant 5. Test login 6. Enable new SCIM 7. Validate users/groups/teams 8. Remove old app assignment/config One subtle but important point If your teams are SCIM-managed, make sure the group names/membership in the new Azure tenant are correct before cutover. That’s usually where surprises happen. If you want, I can also give you a step-by-step Azure + Prefect cutover checklist for: - OIDC-based SSO, or - SAML + SCIM specifically.

You should plan on replacing the current SSO config rather than keeping both. In practice, yes — because Prefect Cloud supports a single SSO configuration for the account, you generally cannot keep the old Azure tenant active while independently setting up a second one for the same account. So the safe interpretation is: - you cannot run both side-by-side in Prefect - the current config will need to be removed or overwritten as part of the cutover - therefore, make sure the new Azure tenant/app is fully ready before you switch Recommended order 1. Prepare the new Azure enterprise app / IdP config completely 2. Confirm you have an Owner account that can bypass SSO 3. Record current SCIM-managed users/groups/teams 4. Replace the SSO configuration in Prefect with the new tenant’s configuration 5. Test login immediately 6. Then enable or re-enable SCIM from the new tenant Why not delete it too early? If you delete the current SSO config before the new one is ready, users on enforced domains may be unable to log in as expected, and SCIM-managed access can get messy. So I would not do an early delete as a first step. I’d do it only as part of the actual cutover window. Docs: - Configure SSO - Manage roles If you want, I can turn this into a minute-by-minute cutover runbook so your team can do the switch with minimal downtime.