• Products
  • Documentation
  • Resources

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.

Diagram showing how users can gain additional permissions after the migration.

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.

Diagram showing how users can lose product access after the migration.

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.

Diagram showing changes to user memberships between the migrations.

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

Get started with migrating users to Atlassian Cloud

Still need help?

The Atlassian Community is here for you.