Plan your Cloud migration
Documents to help you prepare to migrate your Atlassian Server or Data Center products.
Migrate groups and permissions
Starting January, 2024, we’re renaming the Jira cloud-to-cloud migration feature to Copy product data. We’re moving this feature to Atlassian Administration at admin.atlassian.com in a unified experience along with Confluence cloud-to-cloud data copy.
We’re rolling out the change slowly, so if you aren’t able to access this feature by logging into your Jira Cloud and selecting System > Settings > Migrate cloud site, we recommend you go to admin.atlassian.com, and select:
Settings > Data management > Copy product data
You’ll need to have organization administrator permissions to access and use the Copy product data feature.
When you migrate users from one instance of your cloud to another, we migrate the groups they are in and the permissions that the groups have. We check if groups with the same names exist in your source and destination instances. This page explains how we migrate your groups and the impact on permissions.
Ways in which you can migrate users and groups
You can migrate users and groups in two ways:
Migrate users and groups separately, which means you’ll need to add users to their groups after migration to give them access to products or projects.
Migrate users with their groups, which means users will remain in all the groups they were a part of before migration. Users receive product or project access immediately.
Migrate groups with the same names
It’s possible that groups with the same names exist on both source and destination instances. If the groups have the same name, and the same users and permissions, then merging your groups won’t cause any issues.
However, if the groups have the same name, but different users or permissions, some users may get access to projects or products they didn’t have before migration. We’ve put together an example to help illustrate this.
Example
Jane is an admin in a company called Acme Inc that has multiple Jira Cloud instances. Because of a reorganization, Jane is asked to merge two Jira Cloud instances – Acme-Global and Acme-Europe, by moving data from the source Acme-Europe to the destination Acme-Global.
In Acme-Europe, there is a group called Marketing (with users A, B, and X). This group has access to Jira Software and permission to browse a project called Alpha.
In Acme-Global, there is a group also called Marketing (with users A, B, and C) that has access to Jira Software and permission to browse a project called Beta.
When Jane moves the Alpha project and chooses to migrate users and groups separately, users A, B, and C get access to both Alpha and Beta projects after the migration. We’ll migrate X but X won’t be added to the group and so won’t have access to the two projects.
When Jane moves the Alpha project and chooses to migrate users with their groups, users A, B, C, and X will get access to both Alpha and Beta projects.
In this example, there is a mismatch in the permissions users get. User X who only had access to Project Alpha in Acme-Europe can access Project Beta after migration. Similarly, User X who did not have access to Project Alpha, can now access this project.
When you migrate users and groups and there are groups with the same name, the merged group:
retains project permissions of the source groups.
is granted both project and product permissions of the destination group.
Groups that manage admin access
Some default groups that manage admin access are blocklisted and aren’t 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 at 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?