• Products
  • Documentation
  • Resources

Fix invalid email addresses

In Cloud, all users must have valid email addresses, such as user@atlassian.com. The migration assistant lets you identify users who don’t meet this requirement. Then, you can either update them in the user directory or fix automatically during migration.

How to access the user assessment

This page only describes the options that you can choose after completing the assessment in the migration assistant. If you haven’t done the assessment yet, see this page instead:

Learn how to assess and prepare users for migration

Before you begin

Check this information before you start.

Best practices for fixing invalid email addresses

Fixing invalid emails in the migration assistant is intended to resolve problems with old or unimportant accounts. Actual users who will be working in Cloud should be updated in your user directory.

Learn more assessing and preparing users for migration

Fixes will only be applied if you migrate with the migration assistants

When you choose an option to fix users during the migration, we’ll apply the fixes only if you migrate with the migration assistants. The Jira Site import isn’t supported.

Active directories

If you have an active directory connected to Jira, we recommend that you fix important users in the active directory and apply the Migrate invalid users as Former users option to the remaining users. Treating users with invalid emails as former users and migrating them as such helps you avoid problems after you sync the directory to Cloud.

The other option you can choose is generating new emails, in different configurations. Having the same users with different emails in the active directory and in Cloud might result in the following issues:

  • In Cloud, users are matched by emails, so the ones from your directory won’t be linked to their migrated equivalents that got the new emails.

  • If you later fix the user’s email address in the directory, they will be provisioned as a new account if this address is different from the one generated here.

Choose an option to automatically fix users during migration

After you’ve identified important users and updated them in your user directory, choose one of the automatic options to fix the remaining users during migration.

  • The changes will be applied to users created in Cloud, not your original users.

  • The changes won’t be applied right away, but only after you start a migration.


Options available in the migration assistant

Here’s an overview of options you can choose:


Do nothing

We won’t make any changes. Your migration will be blocked unless you update users in your user directory.


Migrate invalid users as Former users

Users will be migrated as Former user in Cloud. A former user:

  • Is deactivated, can’t log in, and can’t be restored

  • Doesn’t consume a license

  • Has every activity, such as comments or history, preserved but displayed under the name ‘Former user’

  • It’s a container that groups activity from all former users, for example deleted users

In Server or Data Center

In Cloud

  • charlie1 (user@atl)

  • charlie2 (user@)

Users don’t exist as separate entities, you can’t view them. Any activity is displayed as Former user.


Migrate invalid users as Former users up to a certain date (Jira only)

Users who last logged in before the chosen date or who never logged in:

  • Are migrated as Former user in Cloud. For more info, see the Migrate invalid users as Former users above.

Users who logged in after the chosen date:

  • Receive pre-generated email addresses and are migrated as active users. For more info, see the Create new emails option below.


Create new emails for invalid users

Users get pre-generated email addresses that unblock the migration, because they’re valid. Users with such emails:

  • Are migrated as active users

  • Consume the license if they’re migrated into a group with product access

  • Have every activity, such as comments or history, preserved and correctly displayed under their name

  • Can’t log in, because they don’t have access to the email address

This option isn’t used to preserve access for users, but to preserve their identity. The email address is based on userID and a domain most common in your user directory.

In Server or Data Center

In Cloud

  • charlie1 (user@atl)

  • charlie2 (user@)

  • useri_10101@atlassian.com (charlie1)

  • useri_10102@atlassian.com (charlie2)


Update users based on a CSV file (Jira only)

You can download a CSV file that includes a list of invalid users and then upload the modified file back. It let’s you apply the above options in a more granular way, for example you can migrate most of the users as Formers users and then select just a few that should get a new email address, either pre-generated or entered by you. The file is also a useful way to identify important users that should be updated in your user directory.

Learn more about updating users based on the CSV file


Next steps

If the assessment also identified duplicated email addresses, see Fix duplicated email addresses. If not, select Review changes where you can apply the changes to your migrations.

Additional Help