Plan your Cloud migration
Documents to help you prepare to migrate your Atlassian Server products.
How user groups and permissions are migrated
When you migrate your users and groups with the Confluence Cloud Migration Assistant or the Jira Cloud Migration Assistant, we will check to see if your groups already exist in your Cloud site. The information on this page explains how we link your groups and what you need to watch out for.
Changes to your Cloud organization
We’ve been rolling out changes that affect the content on this page. From your organization at admin.atlassian.com, if the Users list and Groups list are under the Directory tab, you have the improved user management experience. We’ll note changes for the improved experience in the content below.
User management and permissions for Cloud sites
In your Jira or Confluence Cloud site, product permissions are applied through groups. If a user is added to a group that has permissions to access Confluence, the new user will be given access to Confluence and will be added to your Confluence license and bill.
Users and groups are managed differently in Server and Cloud. In Cloud, groups and their permissions are managed centrally across a site. So you can have a group that manages permissions for both Jira and Confluence, or you can have separate groups for each.
Learn more about groups and permissions in Cloud
Linking groups
If you have the improved user management experience, replace any reference to “cloud site” in this section with “cloud organization”, except in the examples. Also, refer to Example 3 only (Example 1 and 2 are not applicable to the improved user management experience).
When the Migration Assistant migrates your users, it also migrates the groups that they are in. If we find a group in your Cloud site with the same name as a group that you are migrating, we will not re-migrate that group. Instead, we will add the users from the Server group into the Cloud group. Those users will then be given the same permissions as the Cloud group.
If your users and groups are the same (with the same users and permissions) across your Server site and Cloud site, then merging your groups should not cause any issues.
However, if they’re not the same groups but the groups have the same name, you may encounter some issues. We’ve put together some examples to help illustrate this.
Example 1
Neha’s company already has a Confluence Cloud site. Recently they acquired another business and Neha has been asked to migrate the acquired Confluence Server site into their existing Cloud site.
In Cloud, there is a group called Marketing that has edit access to all spaces. In Server, there is also a group called Marketing, but this group only has view access to all spaces.
When Neha uses the migration assistant the users from the Marketing group on Server will be added to the Marketing group on Cloud. This means they will get edit access.
To avoid this, before migrating, Neha renames the group on the server site to Viewers. Then when they migrate, the users from Server won’t be given additional access.
Helpful links:
Example 2
Alex’s company has both a Server and Cloud site. They use Jira on Server and Confluence on Cloud. To reduce costs, they want to move all their data from their Server into the Cloud site and only use the Cloud site.
Alex’s Jira Server site has a group called Team leads (with users A, B and C). This group allows product access to Jira Software Server.
Alex’s Confluence Cloud site also has a group called Team leads with different users (users 1, 2 and 3), but this group only allows product access for Confluence.
When Alex uses the migration assistant to migrate their Jira Software projects from Server to Cloud, the migration assistant adds the users (A, B and C) from Team leads on Server to the Team leads group on Cloud.
This means that the Team leads group in Cloud now has users A, B and C as well as users 1, 2 and 3. All these users only have access to Confluence and they are all being counted towards the Confluence license.
After migrating, Alex creates a new group called Jira leads (with Jira product access) and manually moves users A, B and C (from Server) to the new group.
Example 3
Omar’s company uses Jira Software on server and they also use Jira Software on two sites (site Acme-Global and site Acme-Europe) of their Cloud organization, Acme Inc.
Their Jira Software Server has a group called Engineers (with users A, B, and C), and they also have a group called Engineers (with users D, E, and F) in their Cloud organization, which grants access to Jira Software Cloud on Acme-Europe.
Omar wants to migrate all the projects from Jira Software Server to Jira Software Cloud on Acme-Global.
When Omar uses the migration assistant to migrate their projects from Server to Cloud, the migration assistant adds the users (A, B, and C) from the Engineers group in Jira Software Server to the Engineers group in their Cloud organization (the group that grants access to Jira Software on Acme-Europe). The users (A, B, and C) will not have access to Jira Software Cloud on Acme-Global.
To avoid this, Omar can either manually move the users (A, B, and C) after migrating to a new group that grants access to Jira Software Cloud on Acme-Global or rename the Engineers group on Server before migrating.
Groups that manage admin access
Some default groups that manage admin access are blocklisted (from the migration assistants) and will not be migrated at all. This is to avoid accidentally assigning admin access to users who shouldn’t have it.
The blocklisted groups are:
"site-admins"
"system-administrators"
"atlassian-addons"
"Atlassian-addons-admin"
"org-admins"
Users in these groups will still be migrated, but if you want them to be in one of the blocklisted groups you’ll need to manually add them after migration.
Other groups that manage admin access will be migrated. Be sure to take extra care when migrating groups with admin access.
After migrating
If you have the improved user management experience, go to your organization from admin.atlassian.com and select Directory > Groups to review your groups.
To make sure your groups are set up correctly after migration, we recommend that you:
Review members of groups and approve their permissions by going to Administration > User management.
Add users to the general administrator (or any blocklisted) groups if necessary.
If you use an external user management system, check that your groups have synced correctly.
When you are ready, you can invite your users. When they first log in they may be prompted to set a new password and add personal details.
More information and support
We have a number of channels available to help you with your migration:
for more migration planning information, visit the Atlassian Migration Program website
for technical issues or support with strategy and best practices, get in touch with our support team
for peer advice, ask the Atlassian Community
for expert guidance, work with an Atlassian Partner
Was this helpful?