Cloud Migration Assistant: Changing options when fixing duplicated email addresses

Summary

This article addresses a confusing behavior that may arise when resolving duplicated email addresses. This issue only occurs when changing the options to fix duplicates during migrations.

Solution

Overview

The Jira Cloud Migration Assistant includes a step to Assess and prepare your users that lets you assess your server users to find invalid and duplicated email addresses that block the migration. After the assessment, you can choose one of the options to automatically fix the problems with such email addresses during migration. Learn more about assessing and preparing users

This article explains a potential behavior that arises when addressing duplicated email addresses. This behavior is specific to situations where changes are made to fix duplicate emails between migrations.

For example:

1. Initially, you choose the option to Create new emails for duplicated users and migrate some projects with users.

2. Then you change to the option Merge duplicated users and migrate other projects with users from the same instance.

This approach is not advisable. It's best to select one option for dealing with duplicated users and maintain it throughout the entire migration process. If a change in option becomes necessary, it can be made; however, keep in mind that doing so will result in the behavior outlined in this article.

Scenario

Let’s use the following server users with duplicated email addresses as an example for this scenario:

• user1 (user@atlassian.com)

• user2 (user@atlassian.com)

• user3 (user@atlassian.com)

Action 1

At first, you wanted to migrate these users as individual users, to preserve their separate activity and identity. In the migration assistant, you selected the Create new emails for duplicated users option and migrated some of your projects.

Result

On Cloud, you ended up with 3 users, each with a new email address generated based on UserID:

• useri_10501@atlassian.com (user1)

• useri_10502@atlassian.com (user2)

• useri_10503@atlassian.com (user3)

This is expected and works exactly as it should. If you migrated all your projects with this option, you shouldn’t have any issues.

Action 2

Since all these users were migrated into a group that has product access, all of them were consuming licenses. To save license costs or just reduce the number of users in Cloud, you decided to merge these duplicates instead.

In the migration assistant, you selected Merge duplicated users and migrated other projects from the same instance (you couldn’t have migrated the same projects again).

Result

The original server users from the scenario description were now merged into a single account:

• user@atlassian.com (Main account: user1, with content from user2 and user3)

In such a case, one account is always chosen as the main one (randomly), and the content from the remaining accounts is merged into the main account.

The previously migrated users also remained in Cloud. They weren’t overwritten, because they exist in Cloud as separate users, each with their own email address:

• useri_10501@atlassian.com (user1)

• useri_10502@atlassian.com (user2)

• useri_10503@atlassian.com (user3)

Problem

Problem 1: Duplicated accounts

You now have a “duplicated” user1 in Cloud:

• Merged account: user@atlassian.com (Main account: user1, with content from user2 and user3)

• New email account: useri_10501@atlassian.com (user1)

• You could also consider the new email accounts for user2 and user3 duplicated accounts (because their content is already included in the merged account). But, since these accounts weren’t used as the main ones when creating the merged account, they don’t affect the references in a confusing way.

These are still individual users with separate emails, but since Merge duplicated users is the last action you made, you probably expected to overwrite any previously migrated accounts with the merged ones. This is not the case – what was migrated before, stays in your Cloud site.

Problem 2: References

A more confusing problem is how these duplicated accounts affect the references (for example, mentions) in all migrated projects:

• References to user2 and user3 will go to the merged account: user@atlassian.com (Main account: user1, with content from user2 and user3).

• References to user1 will go to the new email account: useri_10501@atlassian.com (user1)

Since merging the accounts is the last action you made, you probably expected all references to go the merged account. This happens only in the case of user2 and user3.

Recommendation

There isn’t any good solution to this problem, that’s why we recommend that you choose one option and stick to it for all of your migrations on a single instance. Deleting redundant users in Cloud won’t help – the users will be deleted (becoming Former users) and won’t consume extra licenses anymore, but the references in the already migrated projects will go to or be displayed as ‘Former user’. They won’t be remapped to any newly migrated users.