Plan your Cloud migration
Documents to help you prepare to migrate your Atlassian Server or Data Center products.
Understand problems with duplicate or re-migrated groups
When you migrate users, we’ll check if the groups they belong to already exist in cloud, based on the group’s name.
If they do, we’ll take the following actions:
We’ll migrate new users into existing cloud groups
We won’t migrate the server groups, keeping the original groups in cloud
We won’t migrate product access from the server groups, keeping the original in cloud
This shouldn’t cause any problems if you’re actually re-migrating the same groups. But, if you’re migrating duplicate groups from different products or made changes to memberships between migrations, it might result in users getting different access and permissions than they should.
Getting additional product access or permissions
Users can get additional product access, and by extension permissions, if a duplicated group in cloud has access to more products than the server group.
Example
In this example, you have the following groups:
Server: Marketing (with View only permission set in Confluence for this group)
Cloud: Marketing (with View and edit permission set in Confluence for this group)
When you migrate, users from the server group will be migrated, but not the group, because its counterpart already exists in cloud. This way, the migrated users receive additional edit permission, because Confluence Cloud was configured to give more permissions to the cloud group.
Getting incorrect product access
Users can get incorrect product access if a duplicate group in cloud is configured for different products.
Example
In this example, you have the following groups:
Server: Team leads (Jira access)
Cloud: Team leads (Confluence access)
When you migrate, users from the server group will be migrated, but not the group, because its counterpart already exists in cloud. This way, users from the server group receive different access – access to Confluence, and not Jira.
Changes to group memberships
When you migrate a group to cloud and then change its members on the server side, only new members will be added to the cloud group. We won’t change any existing memberships, for example remove users.
In this example, you have the following equivalent groups:
Server: Admins (4 users)
Cloud: Admins (4 users)
When you remove a user from the server’s Admins group and re-migrate this group to cloud, the user won’t be removed from the cloud group. We can add new users to the group, but we can’t change existing memberships.
This is especially important in phased migrations when you migrate different projects or spaces at a different time. You might think that a project or space can only be viewed by Admins, but in reality – the cloud’s Admins might have more users than its server equivalent.
How you can avoid these problems
There are some ways in which you can avoid these problems, either by renaming the groups or creating new groups and moving your users.
Renaming server groups that you want to migrate
Renaming server groups is not straightforward, because you can only do it by modifying the database. If you rename them before the migration, the groups are migrated as unique groups, with their original product access.
Renaming existing cloud groups
Unlike in server, you can rename groups in cloud. If you rename them before the rmigration, the migrated server groups lose their cloud duplicates and can be migrated as new, unique groups.
Moving migrated users to different groups
You can also create new groups (for example, Team leads → Jira team leads, Confluence team leads) and move your migrated users to these groups, either before or after the migration.
You can also migrate users without preserving their group membership to avoid giving them different product access right after the migration.
Manually making changes to group memberships in phased migrations
When it comes to changing group memberships between the migrations, you need to always assume that your manual updates won’t be re-migrated. Whenever you make such changes on the server side, always make equivalent changes in cloud.
Related pages
Was this helpful?
Still need help?
The Atlassian Community is here for you.