Upcoming change: Migrate your Atlassian teams to site-level visibility (original user management)

[#1]

Hi Atlassian Community

We’re updating the way Atlassian teams are visible in your organization. Going forward, if your organization has original user management, your Teams will have site-level visibility.

What’s changing?

We’re making Atlassian teams and groups management simpler and more consistent.

Currently, your Atlassian groups are only visible to users within a specific site (site-level visibility) , while your Atlassian teams can be seen by everyone across your organization (organization-level visibility).

To make things clearer, we’re updating teams so they’ll only be visible to users on the site they’re assigned to, just like groups. This change will simplify administration, ensure the right users have access to the right Teams, and pave the way for upcoming Teams app features.

To learn more about team visibility, please refer to ‘understanding team visibility’.

Once a team is assigned to a specific site, it will only be visible and accessible on that site. For example, if you assign Team Vitafleet Dev to site X, it will no longer appear or be available in site Y or any other sites.

Who does this affect?

This migration is only relevant to organizations in Cloud that use original user management and do not already have site-level visibility for teams. Only a small subset of customers will need to take action.

If you are an organization admin and want to determine whether this migration impacts your organization, please check for any of the following indicators:

• An email notification regarding ‘Atlassian teams’

• An in-product notification about ‘Atlassian teams’ in your Atlassian inbox

• A notice displayed on the groups page within Atlassian Administration

If you see any of these notifications, your organization is included in this migration

Why do you need to migrate?

We’re updating teams to be visible only within the site they’re assigned to (site-level visibility). This brings several benefits:

• See only relevant teams: You’ll no longer see teams that aren’t used in your site, making it easier to find and connect with the Teams that matter most to your work.

• Unlock new features: This change enables upcoming enhancements related to Teams and Groups:

  • Centrally view and manage Atlassian teams in Atlassian Administration

  • Grant permissions using Atlassian teams

  • Copying Atlassian teams data in Jira Cloud

• Improve consistency: With both groups and teams visible at the site level, it’s easier to understand and manage who can see and interact with each group or team.

By making teams visible at the site level like groups, we’re creating a more consistent and streamlined experience for everyone in your organization, and preparing your Atlassian environment for future enhancements.

Key migration dates

Who does this apply to?	Migration begins	Migration ends
Organizations without Jira Service Management, or with fewer than 25 teams	20 Oct 2025	19 Dec 2025
Organizations with Jira but not Jira Service Management	20 Oct 2025	28 Jan 2026
Organizations with at least one license of Jira Service Management	18 Nov 2025	26 Feb 2026

What do you need to do?

Before migration

To make your migration as smooth as possible, we recommend the following steps:

1. Get familiar with key resources: Read the FAQs and review the sections that relate to the Atlassian Apps your organization uses. This will help you understand what’s changing and what to expect.

2. Review and update your Teams: Check that your teams are up-to-date and accurately reflect how your organization works today.

3. Clean up unused Teams: Delete any teams you no longer need. For example, go to the team directory and delete any teams that don’t have any members. This helps reduce clutter and makes the migration process easier.

4. Join our community group: Connect, ask questions, and stay up-to-date throughout the migration.

During migration 

• New teams will automatically be assigned to the site where they’re created.

• Existing teams will need to be assigned to a site (guide here). To help you prepare for this change, we’ve mapped teams to recommended sites based on current usage.

  • For detailed steps, helpful resources, and FAQs, please refer to the support documentation.

There are different scenarios to consider based on your Apps and how you use teams. Please make sure to review the migration guide here thoroughly, as it contains important instructions and guidance specific to your situation.

After migration

• Teams will only be visible and usable in the site they’re assigned to.

• If a team is assigned incorrectly, admins can update the assignment during the migration window and for a 1 month grace period after.

Need help?

Join and reach out here in our community group to ask questions and seek guidance at any stage of the migration. If you need further assistance, you can also contact support here.

[John Tester]

@April Chi To clarify this is also only applicable to orgs that have multiple sites, correct? The docs state:

"This migration is only relevant to organizations using original user management whose Atlassian Teams are not on site-level visibility already."

The documentation is thorough but examples within speak to site X vs site Y, implies you have multiple to begin with.

[James Rickards _SN_]

Thanks @April Chi .

This is great news. Teams being across all sites in an Org was a limitation for Consultancy orgs that have a site per customer to better segregate data. In that case, team names needed to be obscure to prevent giving away your who you're workign with, and seeing more teams than relevant cluttered the UI.

Can you confirm if it would be possible to assign a Team to more than one site?  For example, in the past it was possible to have a single OpsGenie instance linked to many JSM instances.

[Sebastian Wigge]

Does the upcoming feature "Grant permissions using Atlassian Teams" mean that users can create, edit and permit their teams across Atlassian products just like with Jira groups? That would be huge for the many admins that are frustrated with group management in JIRA. It would save us a lot of time.

[April Chi]

Hi @John Tester ,

Thank you for the question! Yes, that is correct. We'll make that clearer. If you receive a notification that you are a part of this migration, then you are original user management and you have multiple sites. 

[April Chi]

Hey @James Rickards _SN_ ,

Hope you're well and thanks for the question! 

This is great news. Teams being across all sites in an Org was a limitation for Consultancy orgs that have a site per customer to better segregate data. In that case, team names needed to be obscure to prevent giving away your who you're workign with, and seeing more teams than relevant cluttered the UI.

Can you confirm if it would be possible to assign a Team to more than one site?  For example, in the past it was possible to have a single OpsGenie instance linked to many JSM instances.

Great to hear the positive feedback. Unfortunately, no. You would not be able to assign a team to more than one site. When you update your teams to site-level visibility, it has to be assigned to a single site. This means that the team will only be visible and usable in the site you assign it to - you can read more about how to do this in the migration guide here.

If your team was assigned to work in multiple sites, this will have some implications documented here in our guide too.

This is a step towards a new visibility model that we will be introducing next year where you will get more granularity called Units.

Please let me know if that makes sense and if you have any further questions. 

[April Chi]

Does the upcoming feature "Grant permissions using Atlassian Teams" mean that users can create, edit and permit their teams across Atlassian products just like with Jira groups? That would be huge for the many admins that are frustrated with group management in JIRA. It would save us a lot of time.

Hey @Sebastian Wigge,

Not yet but that is something that is on our radar as we build the fundamentals of teams! This item is referring to granting permissions to Confluence pages i.e. you can grant permissions to a team in a Confluence page. This is something we're currently working on. We expect this to be delivered in the first half of next year.

[Chris]

Automations with JSM may be impacted

We recommend that you double check any automations you have set up with JSMOps teams. To ensure minimal disruption to your automations.

1. Ensure your team belongs to the site or instance of the product where the automation is run.
2. If it does not, create a copy of the team in the sites or products you need the automation, and set that automation up for that site.

I just assigned all teams to our site. I am creating a new JSM-Project in a Sandbox and my automations don't work anymore, because the sandbox does not have access to the teams? This is unacceptable and is - again - one of those 80% solutions that Atlassian is famous for. Can you just for once please come up with a solution that includes all use cases? -> Please open a bug report, please link it here so that everyone can vote for it AND PLEASE FIX IT ASAP.

[April Chi]

Hey @chris ,

Thank you for the feedback. So I can understand how to help you better, can I please clarify the following:

- Have you assigned all your teams to a production site but have another sandbox site? 

- Is it all the automations that aren't working in the sandbox site?

- What automations are you using? Are you using json with teamIDs? 

If so, the context here as stated in the migration guide is unfortunately, with site-level visibility, you can only use a team in a single site. So if you say, assigned a team to a production site, that team is no longer accessible in other sites including sandbox sites, hence the automations will no longer work. The guidance here is to create a copy of that team in the sandbox site and update your automations there if required. 

Apologies for the inconvenience on this - I'm happy to work with you on this and help you quicker if you'd like to hop into a 30 minute call with me.

Here is also a ticket you can vote for so we can gather the impact/interest in this: https://jira.atlassian.com/browse/JRACLOUD-96463