robotsnoindex
descriptionLearn about how we migrate and link your groups when you use the Cloud Migration Assistant to migrate from server to cloud.

robotsnoindex

We’re currently 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.



Note this difference if you have the improved user management experience: any references to “cloud site” in this section are now “cloud organization”.


When you migrate your users and groups with either of the migration a ssistant s, 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. This guidance applies to the Confluence Cloud Migration Assistant and the  Jira Cloud Migration Assistant .

User management and permissions for cloud sites

Note this difference if you have the improved user management experience: any references to “site” in this section are now “organization”.

In your Jira or Confluence Cloud, 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. Learn more about giving users product access.

Users and groups are managed differently in server and cloud. In cloud, groups and their permissions are managed centrally across a site. So you could 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

Note this difference if you have the improved user management experience:

  1. any references to “cloud site” in this section (excluding the examples) are now “cloud organization”.
  2. refer to Example 3 as Example 1 and Example 2 are not applicable.

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.

*You can follow the instructions to rename a group on your Jira Server or Confluence Server sites.


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 then 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.


A fter migrating, Alex then 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 migration 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 Assistant) 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"

  • "administrators"

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

Note this different way to review groups if you have the improved user management experience: from your organization at admin.atlassian.com, select Directory > 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. Check out this guide if you're migrating with an external identity provider

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.