Plan your Cloud migration
Documents to help you prepare to migrate your Atlassian Server products.
Migrate groups and permissions
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.
When you migrate users and groups from one Cloud site to another, we will check to see if your groups already exist on the destination site. This page explains how we link your groups and what you need to look for.
User management and permissions for Cloud sites
In your Jira Cloud site, product permissions are applied through groups. If a user is added to a group that has permissions to access Jira, this new user will be given access to Jira and added to your Jira license and bill. Learn more about giving users product access.
It is important to remember that groups and their permissions are managed centrally across a site in the Cloud. So you can have a group that manages permissions for both Jira Software and Jira Work Management, or you can have separate groups for each. Learn more about groups and permission in the Cloud.
Linking groups
When you migrate your users from one Cloud site to the other, you're also migrating the groups they are in, and by default, the permissions that those groups have.
Here's what happens if there is a group in your destination site with the same name as a group that you're migrating:
Users from the source site will be added to the group with the same name in the destination site.
Users from your source site will be given the same permissions as those on your destination site.
If your users and groups are the same (with the same name and permissions) across both sites, merging your groups will not lead to any mismatch in permissions which could lead to permission escalations.
If the groups have the same name but different permissions, you may encounter some problems concerning permissions while migrating.
Possible group migrations and their behavior after migration if you choose to preserve group membership
Group name | Permissions on the source site | Group with the same name exists on the destination site | Permissions on the destination site | Permissions post migration |
|---|---|---|---|---|
ABC | Users of ABC have:
| Yes | No permissions |
|
ABC | Users of ABC have:
| Yes | Users of ABC have:
|
|
ABC | Users of ABC have:
| No | - |
|
If you decide to remigrate and change the permissions of an already migrated group in the destination site: | ||||
ABC (already migrated group) | Users of ABC have:
| Yes | Users of ABC have:
|
|
You can migrate your site first and then manually add users and groups to prevent giving users unwanted permissions.
Preserving group membership
While we recommend migrating your site and then manually adding users and groups, there could be situations wherein preserving group membership may be a better option. Select the Preserve group membership option if:
your source and destination sites both have the same group names and permissions.
you don't mind groups on your source site inheriting the product-level permissions of groups on your destination site.
you're testing the migration.
How to preserve group membership
If you want to preserve group memberships, select the Preserve group membership option before migrating. This option gives your users product access and project-level permissions, and they will be added to your cloud license after migration. Users will not receive any emails or invitations from Atlassian once the migration is complete.
If there are any groups with conflicts, we'll show them to you when you land on the Check for conflicts screen. You can download the CSV file for the exact details of groups that have conflicts and the product roles in source and destination sites. If the product roles in source and destination sites are different, then the migration can result in users getting unwanted permissions.
Groups that manage admin access
Some default groups that manage admin access are blocklisted and will not be migrated. This is to avoid accidentally assigning admin access to those who shouldn't have it.
Blocklisted groups
"site-admins"
"system-administrators"
"atlassian-addons"
"Atlassian-addons-admin"
Users in these groups will still be migrated, but you'll have to manually add them after migration if you want them to be in one of the blocklisted groups.
If you have any other groups apart from these that manage admin access, they will be migrated. Be sure to take extra care when migrating groups with admin access.
After migrating
To make sure you're set up correctly after migration, we recommend that you follow the steps we've outlined based on the user management experience you have.
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 add users to the group, go to Add group members, select the users you'd like to add and select Add.
You need to add users only once and don't have to add them to each product on your site.
If the improved user management experience hasn't been rolled out to you yet, we recommend that you:
Review members of new groups and approve their permissions by going to Administration > User management.
Add users to groups by navigating to the site in admin.atlassian.com. Go to the product you want to add users to and select Manage product access and Manage users. You need to do this for each product on the site.
If you use an external user management system, check that your groups have synced correctly.
When you're ready, you can invite your users.
Was this helpful?