How groups and permissions are migrated with the Migration Assistant

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

When you migrate your users and groups with either of the migration assistants, 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

In your Jira or Confluence Cloud sites, 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

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 and cloud sites 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 Team A 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 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.

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

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

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.



Last modified on May 19, 2020

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.