After a team change in Atlassian, review which users still have Jira product access through old team groups, default groups, or synced groups. Remove or update access only after the new owner confirms what each user still needs.
Why this matters
Team changes create quiet license drift. People move to new projects, departments merge, vendors rotate, and old groups keep granting product access long after the work changed.
Cleanup after a team change should protect current work while removing access attached to the old structure. That requires owner review, group-path evidence, and explicit exceptions.
For the query team change access cleanup Atlassian, the useful answer should help an admin decide what to check now, which rows to hold out, and which proof should survive after the change. That is why this page stays inside a narrow operational boundary instead of becoming a general governance essay.
Working scenario
A product team splits into two squads. Some users still need Jira, some need different project access, and some contractors left. The admin reviews old team groups, default groups, and product access before removing licenses.
Start from the old team boundary
List the groups, projects, and product-access paths that represented the previous team. Old team groups often continue granting Jira access even after reporting lines change.
Ask the new owner to classify users
Managers or project owners should mark users as keep, remove, transfer, or exception. Admins should not infer business need from group names alone.
Check default and synced groups
A user removed from an old team group may still have access through a default Jira group or identity-managed group. Review all product-access paths before calling cleanup complete.
Update the access model, not just users
If the team change is permanent, adjust onboarding, default membership, or group ownership so new users do not inherit the old access pattern.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| User moved teams | New role and Jira need | Keep, transfer, or remove access based on owner decision |
| Old team group grants product access | Whether the group is still needed | Remove membership or replace group model |
| Default group still grants Jira | Default access mapping | Do not expect team-group cleanup to reduce billability alone |
| No new owner identified | Manager, project owner, or identity owner | Hold in owner-review lane |
Common mistakes
Most cleanup errors happen when an admin treats a partial signal as a complete answer. These are the failure modes to watch for on this topic:
- Removing old project access but leaving Jira product access.
- Letting team-change exceptions stay ownerless.
- Assuming group names still match current org structure.
- Forgetting to change defaults after the team model changes.
Checklist
- List groups and projects tied to the old team.
- Find users who still have Jira product access.
- Ask new owners to classify keep, remove, transfer, or exception.
- Check default groups and synced groups for remaining access.
- Update ownership or onboarding rules that caused drift.