How Jira users and groups are migrated

The Jira Cloud Migration Assistant lets you migrate Jira users from Server or Data Center to Cloud. You can migrate users separately or together with project data.

User migration strategies

Before starting your migration, choose a user migration method that works for your setup, especially if you’re using a third-party identity provider. Learn more about user migration strategies

User migration options

When migrating users, you can either migrate them in advance or as part of data migration:

1. When migrating Jira users and groups in advance (recommended)

You can migrate users and groups in advance when you use the Migrate your users in advance card on the assistant’s home screen.

In this option, we migrate:

• All users and groups

• (Optional) Group membership

• (Optional) All Jira Service Management customers

2. When migrating Jira users and groups as part of data migration

You can migrate Jira users as part of data migration when you use the Migrate your data card on the assistant’s home screen.

In this option, you have the following choices on how you migrate users:

How users and groups referenced in projects are migrated

The following tables shows details of what users are included in your migration when you select the Migrate only the users and groups referenced in projects option.

	All users and groups	Referenced only	Referenced + assigned project roles	Referenced + members of groups	Referenced + assigned project roles + members of groups
Users referenced in project fields or user-generated content
Users and groups assigned a project role		unless also referenced in the project		unless also referenced in the project
Members of groups assigned a project role		unless also referenced in the project	unless also referenced in the project
Users or groups referenced in workflows or permission schemes of selected projects
Members of groups referenced in workflows or permission schemes		unless also referenced in the project	unless also referenced in the project
All other users and groups not mentioned above

How user and group data is linked

User accounts in cloud are identified by unique email addresses.

When using the Migration Assistant to migrate, a new account will be created in your Cloud site for each of your users. If an email address already exists in your cloud site, it won’t be migrated. Instead, we will link all data connected to that user to their account in cloud.

If you have users that already exist in your destination cloud site, then the following will occur:

• if a user has product access in cloud, but has disabled status in your Server site, they will continue to have product access in cloud after migration

• if a user does not have product access in cloud, but is enabled and has product access in your Server site, they will be granted product access through the migration process

Your groups will also be linked to existing groups in cloud (if they are already there). Group linking is identified by group name and could result in permission escalation during migration. Make sure you check your groups before migrating. Learn how groups and permissions are migrated

Re-migrated groups and possible permission escalation

When you re-migrate a group to cloud, we won’t update its existing memberships or the group itself. We only add new users that appeared in the group since the last migration. This can result in permission escalation. For example:

1. You migrate an Admins group to cloud.

2. Later, in Server or Data Center, you remove some users from this group, and re-migrate the group.

3. The changes in memberships won’t be reflected in cloud, because we keep what was already migrated intact. The removed users will still be members of the cloud’s Admins group.

4. However, if you add new users to the group, we’ll add them to the cloud’s group. That’s because it’s an addition of new memberships, not a modification of existing ones.

You should take that scenario into consideration when doing phased migrations. It might happen that you migrate a project or space thinking it can only be viewed by Admins, but in reality – the cloud’s Admins might have more users than its server counterpart.

Always assume that what was already migrated will stay as-is, without further updates.

Whenever you need to make changes to groups in Server or Data Center, manually make the same changes to their equivalent cloud groups.

Test migrations

For a test migration or User Acceptance Testing (UAT), we recommend that your test cloud site isn't part of the production organization. This is to ensure smooth migration of the relevant users and groups. All sites within a single organization would share the same users and groups.

Reducing downtime by pre-migrating users

If you migrate your users before your project data, you will save time on the migration day. This is because the Migration Assistant will not need to re-migrate those users. This is particularly helpful if you are migrating all of your users. 

Learn how to migrate Jira users and groups in advance

Deleted or inactive users and directories

Any deleted users or users in inactive directories that are referenced in your Jira data will appear as Former user after migration. If you need to migrate the references to these users, reactivate them (or the directory) before migrating.

Users with disabled status in your Server site will be migrated as active but without any product access. This means they will not be counted as active Jira users for billing purposes. Learn how users are managed in Cloud

Reviewing and approving permissions

The first time you migrate, you will need to review and approve group permissions after migrating. When you approve group permissions any active users in your cloud site will be added to your bill.

Global settings and global site permissions are not migrated with this tool. You’ll need to set these manually before or after migration.

Learn how groups and permissions are migrated

Migrating project roles, and related limitations

When you select a project for migration, the roles associated with that project will also be migrated. Unfortunately, at this point in time, project roles do not get removed when you delete a project in cloud, so when you migrate that same project again, the role will get migrated with the suffix: (migrated). This is a known issue and requires manual clean-up. If you need assistance with this, contact our support team.

Email invites to users

We won’t send an invitation to your users even if you choose to give your users access during the migration. To invite your users you can choose to send an invitation from the Administration space after you have migrated, or send a link for them to log in themselves.

Billing in cloud

Jira Cloud is subscription-based and billed on a per-user basis. If you plan to migrate your users, make sure you check the licensing options or calculate the cost with our pricing calculator. By default, cloud subscriptions are billed on a monthly basis, however you can choose annual billing if you prefer. 

Third-party identity providers

If you're intending to use an external identity provider in cloud, make sure you've read the guidance on migrating users and groups. Learn more about user migration strategies

We recommend synchronizing it with your local directory before migrating. This is to make sure that your users and groups are up to date before you transfer any data.

More information and support

We have a number of channels available to help you with your migration.

• For more migration planning information and FAQs, visit the Atlassian Cloud Migration Center.

• Have a technical issue or need more support with strategy and best practices? Get in touch.

• Looking for peer advice? Ask the Atlassian Community.

• Want expert guidance? Work with an Atlassian Partner.

Support for Atlassian Server products ends in February, 2024. Learn more about the Server end of support timeline.