Too many Jira users
This insight checks if the number of users with access to Jira Sofware exceeds the limit of users in Jira Cloud.
More details about Jira users
Jira Cloud limits the number of users with product access. The limit includes users who:
Have active status
Have been granted access to Jira Cloud
We use the same criteria for your result, however we check for access to Jira Software, which is the Data Center equivalent of Jira Cloud. The previous Jira Core access should no longer be available in Data Center (and isn't migrated) while the Jira Service Management access would be granted separately in cloud. You can match your result to your Jira Software license in Administration > Versions & licenses.
If you'd try to migrate these users:
The migration assistant compares your users to your cloud plan. If you have more users than allowed in your plan, your migration will be blocked.
If you temporarily remove user access for the migration, you can migrate them. However, on the cloud side, you'll be able to grant access only until you reach the limit.
What’s the recommendation?
We recommend that you review and clean up your user base. It's common to have many old or testing accounts that have access, yet no longer need it. All of these users count towards your license, so it might be a good idea to delete them or remove their access before the migration.
Remove users from access groups
You can either remove users from groups that grant access, or remove access from entire groups.
To view groups that grant access and remove their users:
In Jira Data Center, go to Administration > Groups.
Every group that grants access should have a product label next to it, like Jira Software.
Select Edit members for your group.
Remove users from these groups.
To view, grant, and revoke access for groups:
In Jira Data Center, go to Administration > Applications > Application access.
Groups that have access will be listed under a specific product.
Select Remove next to your group. The group will lose product access.
Fix invalid and duplicated emails (former users and merge)
You can run a user assessment in the migration assistant that will find users with invalid and duplicated email addresses. Users with such emails block your migration and must be fixed anyway.
Run a user assessment to identify users with incorrect emails
Access the user assessment faster
When viewing this insight on the dashboard, select the first View user assessment in the assistant link to open the assessment in your instance.
To run a user assessment:
Open the Jira Cloud Migration Assistant by going to Administration > Migrate to cloud.
On the home screen, find the Assess and prepare your users card, and select Begin assessing.
Once the assessment is complete, you should see the number of users with incorrect emails:
The results show the number of users that have invalid or duplicated email addresses. These users are potential candidates for deletion, but you should review them.
Fix invalid emails by migrating these users as former users
Before you begin
When fixing invalid emails, we’ll make the following choices:
CSV: Use the CSV file instead of automatic options. This will allow you to choose which users are deactivated and which migrated as active users.
Former users: Turning users with invalid emails into former users, deactivating them. Thanks to the CSV file, you’ll be able to choose a different option for selected users.
To fix users with invalid emails:
When viewing the assessment results, select Fix invalid emails.
You’ll see a few automatic options for fixing your users. Select the Update users based on CSV file, and download the CSV file.
How to edit the CSV file
The CSV file includes all users with invalid emails. You can view detailed instructions and explanations in the readme file.
Most important information on the CSV file
Pre-generated emails: All users will have dummy email addresses assigned. These addresses are valid, but aren’t actually working. If you’d like to migrate users as active users, you can change them to any working email you have access to.
Tombstone: All users will have this value set to false. This means they’ll be migrated as active users by default. You can change this value to true for users who can be deactivated and turned into former users.
To reduce the number of users by turning them info former users:
For each user that can be deactivated, change the Tombstone value to true.
For users that you’d like to keep, change the email address to a working email.
Save and upload the file to the migration assistant.
Fix duplicated emails by merging these users
Before you begin
When fixing duplicated emails, we’ll make the following choices:
Automatic option: In this case, we’ll use one of the automatic options instead of the CSV file. That’s because it’s easier and more efficient for merging duplicated emails.
Merging: We’ll merge all users that share the same email address to reduce the final user count.
After you fixed invalid email, select Fix duplicated emails. You’ll be moved to a similar screen where you can fix users with duplicate emails.
To merge users with duplicated emails:
Select the Merge duplicate users option.
Review changes and make a list of changed users
After choosing options to fix invalid and duplicated emails, select Review and apply.
Migrate only users referenced in projects
When you migrate projects in the Jira Cloud Migration Assistant, you’ll have an option to migrate only users referenced in these projects, excluding all the rest.
You’ll be able to check the number of referenced users and groups without running the migration to give you an idea how many users you can exclude.
Migrate only users referenced in selected projects
You can choose an option to migrate referenced users after you add projects to your migration plan.
To migrate only referenced users:
Create a new migration plan in the Jira Cloud Migration Assistant.
Select the Choose what to migrate method, so you can manually select the data.
In the Projects card, select some projects to be included in your plan.
In the Users and groups card, select the Only users and groups related to the selected projects option. Learn more about the options you can choose
You can skip selecting data in other cards, such as Roadmap plans or Apps.
Check the number of referenced users and groups
You can check the number of referenced users and groups in the pre-migration report.
To download the pre-migration report:
1. Continue through the pre-migration checks until you reach the Review your migration screen.
2. In the Logs and report tab, download the pre-migration report.
3. Extract the archive, and look at the following files:
Summary: The file includes the number of users and groups included in migration.Users and groups: The files includes the details of referenced users and groups, and the projects they’re referenced in.
Repeat these steps for all projects you want to migrate to understand how many users you’ll actually need in cloud. When viewing the pre-migration report, make a list of referenced users and groups so you can exclude them from your provisioning and syncing filters on the cloud side.
Change user provisioning filters on the cloud side
Depending on how your user provisioning and syncing filters are constructed, you might be syncing more users than necessary, for example including users who are no longer needed or who never even logged in.
Here are some ideas on how to avoid that:
Modify your LDAP (server) or SCIM (cloud) filters to exclude users that are no longer needed or were fixed using other recommendations
Making changes to users in your external directory, and not only the Jira directory. This will make sure that any updated or removed users won’t be provisioned to cloud
SCIM filters in Atlassian Cloud
You can’t connect an external directory directly to Atlassian Cloud. You will need to use an identity provider in-between. If you wish to modify filters, you’ll need to do it in your identity provider.
Here’s an idea on how to do this with Microsoft:
Here are docs for connecting Atlassian Cloud to identity provider. In some of them, like Okta, you’re able to specify who’s being synced when configuring this connection:
OneLogin: Learn how to configure user provisioning for OneLogin
Azure AD: Learn how to configure user provisioning for Azure AD
Google Cloud:Configure user provisioning with Google Cloud
Google Workspace: Learn how to set up user provisioning for Google Workspace
PingFederate: Learn how to configure user provisioning for PingFederate
JumpCloud: Learn how to configure user provisioning for JumpCloud
Learn more about user provisioning in cloud
LDAP filters in Data Center
Although it’s more important to update your filters on the cloud side, you can also do it in Data Center. This will let you delete some users more easily (for example, users with no content in Jira are deleted automatically after being excluded from syncing), and try some changes on your existing user base.
Was this helpful?