Hi all — we’re planning a team membership migration for our Enterprise org (~700 users) and want to validate the approach before changing anything in production. Looking for feedback on downsides, ordering, and whether we’re missing a better path.
Current state
- Organization with one default/root team (original team from before multi-team)
- “Auto Add Users to Root Team” is enabled in Organization settings
- SCIM is enabled on the default team; users are provisioned via IdP (no invite-link users)
- We’ve created new teams at org level with:
- Org Groups (Synced) mapped to AD groups
- Membership Type = Synced with those Org Groups as membership sources
- Default team at org level is still Manual (not synced via Org Group mapping)
- All our AD directory groups appear under the default team’s Members & Groups → Directory Groups panel (team-level SCIM / directory groups)
Goal
Move everyone off the default team into department-specific teams, driven by AD group membership, so:
- Users are only on the team that matches their AD group
- Removing a user from one AD group and adding them to another moves them between teams automatically
- We can eventually empty the default team (or the AD group mapped to it)
Right now we’re seeing users on both the default team and a new synced team, even after AD group changes — we assume that’s because default team membership is still manual / auto-add / team-level SCIM, separate from the new org group → team mappings.
Proposed plan
-
Turn off “Auto Add Users to Root Team” in Organization settings
(after new synced teams + mappings are verified) -
Create a new Org Group (e.g.
"default") — Synced, mapped to a “default” AD group in IdP -
Change the default team from Manual to Synced, with that new Org Group as its membership source
-
Gradually move users in IdP: remove from the default AD group, add to the AD group for their real team (Engineering, Platform, etc.)
-
Expectation: when a user moves from the default AD group to e.g. Engineering AD group, they should appear only on the Engineering team, not on default
-
Over time, empty the default AD group and leave default team as admin-only / unused
Questions for the community / Cursor team
-
Is this the recommended migration path for moving off the default/root team, or is there a better pattern for ~700 users?
-
Any risk turning off “Auto Add Users to Root Team” with SCIM already on the default team? Will existing users be affected, or only new provisioned users?
-
Converting default team from Manual → Synced with one Org Group mapping — any known issues with the root/default team specifically? (Docs say the default team can’t be deleted; unsure if synced membership on it has special behavior.)
-
Team-level Directory Groups on default team (what we see under Members & Groups) vs Org Groups → team membership sources — do we need to change or remove the team-level directory group setup on default, or can both coexist during migration?
-
When a user is removed from the default AD group and added to another, should we expect automatic removal from default team immediately (assuming synced mapping), or is there a reconciliation delay we should plan for?
-
Edge cases: Can a user end up on zero teams during a brief IdP change (removed from group A before added to group B)? What happens to their access?
-
For 700 users, is Organization API
team-memberships/syncthe safer bulk approach for the one-time move, with SCIM handling ongoing changes afterward? -
Recommended order of operations — e.g.:
- Synced teams + Org Groups first
- Turn off Auto Add
- Convert default to Synced
- Bulk API migration
- IdP group moves
Or something else?
What we’re trying to avoid
- Blocking or losing access for any of ~700 users
- Users stuck on default + another team indefinitely
- Breaking SCIM / SSO during the transition
Happy to share more detail (IdP, team count, mapping structure) if helpful. Thanks for any guidance from others who’ve done this at scale.