Plan your Cloud migration
Documents to help you prepare to migrate your Atlassian Server products.
Updating users based on the CSV file is one of the options to fix invalid and duplicated email addresses when migrating your users to cloud.
Using the CSV file is available only in the Jira Cloud Migration Assistant.
A separate CSV file is generated for users with invalid and duplicated email addresses, so you need to handle each of these cases separately. The CSV file that you download from the migration assistant always contains the default data identified during the latest assessment, even if you already uploaded a modified file.
We recommend choosing one of the automatic options instead of updating the CSV file. We provided the file in case these options are too generic for you, for example if you’d like to apply a different solution to only select users.
You can modify existing users in the file, but you can’t add or delete users. If the number of users in the uploaded CSV file is different than in the original file, you won’t be able to upload it.
Here you can see the data from a sample CSV file generated for users with invalid email addresses:
UserKey | UserName | Type | OldEmail | NewEmail | Tombstone |
---|---|---|---|---|---|
JIRAUSER10105 | user1 | INV | user1@atlassian | useri_10105@atlassian.com | FALSE |
JIRAUSER10106 | user2 | INV | user2@user2 | useri_10106@atlassian.com | FALSE |
JIRAUSER10107 | user3 | INV | user3@atl | useri_10107@atlassian.com | FALSE |
JIRAUSER10108 | bottybot | INV |
| INV_10108@atlassian.com | FALSE |
UserKey: User key. For users created in earlier Jira versions, it should be the same as the username.
UserName: Username, the primary identifier in your self-managed instance.
Type: Problem with the email address, either invalid or duplicated, depending on the file.
OldEmail: Current email address.
NewEmail: Pre-generated email address to unblock the migration. The domain chosen is the most common one among your users, so it should resemble your actual domains. You can edit this value.
Tombstone: Controls whether a user should be migrated as Former user to cloud. The values are True or False. You can edit this value.
The values you can change in the CSV files are NewEmail and Tombstone:
The pre-generated email addresses are always valid so they meet the requirements and let you
migrate. Note that these emails aren't actually working and your users won't be able to log in
with them. Such emails let you migrate your users, preserving both their activity and identity,
but not the access. If you'd like some of them to keep access, you can change the value to
an address your users have access to. However, in the case of active users, we recommend that
you update their emails directly in the source (Jira user directory, external directory).
If you use an email address that already exists in cloud or is shared by other users
in this file, the users will be merged. Note that merging isn’t supported with the ‘Migrate all data at once’ migration option.
You can change this value to true if you'd like to migrate select users as Former user. Such users will have their activity preserved, but not the identity. Every interaction they ever made, such as adding a comment, will be displayed under the name Former user.
Here are all the options you can do with this file:
For users that should exist in cloud, but don't need access: use default values.
For users that should exist in cloud and need access: set 'NewEmail' to a working email.
For users that should be merged together: set 'NewEmail' to the same address for all of them.
For users that should be deactivated: set 'Tombstone' to 'true'.
Was this helpful?