Plan your Cloud migration
Documents to help you prepare to migrate your Atlassian Server or Data Center products.
How user management works in Atlassian Cloud
User management in Atlassian Cloud is different from what you know from Server or Data Center. The main difference is that it’s separated from products, like Jira or Confluence. If you used Crowd, it would be the closest comparison. This page explains the main concepts of how you’ll manage users in cloud.
Centralized user management
In cloud, users are managed from a central location called admin.atlassian.com, available under the same URL. This is a platform shared by Atlassian cloud products where you manage, for example:
Users and groups
Access to products
User provisioning and single sign-on
Products, subscriptions, billing
When you deploy a cloud product, you always get access to your own admin.atlassian.com. It can only be accessed by organization admins who are a rank higher than Jira or Confluence admins, though they’re really just a different type. Think system admins, though we don’t have system admins in cloud.
Organizations
The admin.atlassian.com platform is divided into organizations – you can have one or more if you prefer to keep things more separated. Every organization has a separate user base, including individual product access, user provisioning configuration, and so on. When accessing the platform, you always choose which org you want to view.
Organizations are further divided into sites that hold products, like Jira and Confluence. All sites (and products) within one organization share the same user base and configuration. You can have many sites, and many products, within one org.
Learn more about organizations
User management area from Server or Data Center
The user management area that you know from Server or Data Center doesn’t exist in cloud. In server, it’s based on Embedded Crowd – a set of libraries that we’ve embedded in Jira and Confluence for user management. They’re not available in cloud, and you won’t be able to access this area. We’ve moved everything to admin.atlassian.com. On the bright side, it does look a little better.
Product access
Product access is the first layer of access that controls whether users can even open a specific product. You grant it from admin.atlassian.com together with an additional product role (Admin, User, Customer) to groups or individual users. Once it’s granted, all users with product access start counting towards your cloud subscription. This works in the same way as application access in server.
We migrate your product access from server, but we won’t apply it to groups until you confirm it after the migration, because it affects billing.
Learn more about product access in cloud
No product access
Users without any product access still exist and can log in to Atlassian Cloud. But, they won’t be able to do much apart from changing their preferences or uploading an avatar. They won’t count towards your cloud subscription.
Permissions
Permissions are the second layer of access, and allow you to give your users more granular permissions than just access to products – for example, permission to view secret projects or spaces. They work in the same was as in server – they’re managed on the product level, and not from admin.atlassian.com. That’s because they’re really more on the data protection side rather than user management.
Permissions depend on your product, like in server. In Jira, you’d have project roles, permission schemes, and more granular permissions. In Confluence, that’s space permissions, with additional restrictions on pages. We’ll migrate your roles, schemes, permissions, or restrictions when you migrate projects or spaces (with the exception of most global permissions).
Learn more about roles and permissions
Atlassian Access subscription
Atlassian Access, although seen as a separate product, is really an expansion for admin.atlassian.com. It’s an additional subscription that enables such features as:
SCIM user provisioning
SAML single sign-on
Data security policies
Organization audit log
When you subscribe to Atlassian Access, you’ll still manage users from admin.atlassian.com, but you’ll see more tabs, options, and features. If you sync users from external directories (other than Google Workspace), you’ll most likely need Atlassian Access.
Here’s an example page in admin.atlassian.com that’s available only with an Atlassian Access subscription – it’s still the same Atlassian Admin area:
Atlassian Cloud accounts
In Atlassian Cloud, users are identified by their email address – every email must be valid and unique. In server, it was the username, that’s why many people have problems with migrating users because of missing or invalid emails. Every user that you create, invite, provision, or migrate will get an Atlassian Cloud account based on their email address.
Access to multiple products
When users are granted access to multiple products, they’ll access them through their single Atlassian Cloud account. In server, they would have separate users in each product.
When you migrate users from multiple products (Jira, Confluence), we’ll match them by their email address and link all of their references (mentions, comments, and so on) to their single Atlassian Cloud account.
Accounts vs. managed accounts
Individual users own their accounts by default. You still control product access, but you can’t modify the account itself. If you want more control, you can verify that you own the domain (@atlassian.com) and claim all accounts from this domain. This transfers ownership of the account to the organization that verified the domain, and the accounts become managed accounts. They’re the same accounts, you just have more control. Atlassian Access specific features can be used only for managed accounts.
Logging in with emails
A key difference for users when they log in is that they’ll use their email address instead of logging in with their username as they previously did in server.
If you’re using single sign-on in cloud, users will log in through single sign-on and have the same password.
If you don’t use single sign-on, users need to select “Forgot password” and enter a new password. Passwords aren’t migrated.
Users will need to upload new avatars, as they aren’t migrated.
User provisioning and authentication
You can manage and sync users from external directories to cloud, but there are additional requirements:
Cloud identity providers
You can’t connect an external directory directly to admin.atlassian.com. You’ll need a cloud identity provider in-between. If you don’t have one, in this guide you’ll find a list of IdPs that are best suited for migrations. We also have a partnership with Okta that lets you set up a free account.
Subscription for Atlassian Access
You’ll need a subscription for Atlassian Access to enable SCIM user provisioning and SAML single sign-on. Some integrations for user provisioning, like Google Workspace or Azure AD for nested groups work without Atlassian Access, because they’re our custom-built integrations that don’t use SCIM.
Here’s how it all connects:
No user provisioning or authentication
If you don’t configure user provisioning, you can create and update users in admin.atlassian.com, just like in the Jira or Confluence internal directories. If you don’t configure single sign-on, users will log in with their emails and passwords. Passwords must be reset after migration, as they’re not migrated.
Other differences related to user management
Here are some other differences or information you should know about.
Nested groups
Atlassian Cloud doesn’t support nested groups. You can still have nested groups in your external directory, but you’ll need to flatten them when syncing to cloud. In admin.atlassian.com, they’ll always appear on the same level. Most cloud identity providers support flattening, we’ve also built custom integrations that flatten groups when syncing from Google Workspace or Microsoft Azure AD.
Duplicate group names
All groups are managed from a single location, so you can’t have multiple groups with the same name. When you try to migrate a group whose copy already exists, we’ll migrate its users, but not the group itself. This is important if you’re migrating from both Jira and Confluence. If each of these products had a group admins with a different set of users, after migration all of these users would belong to a single admins group, with product access coming from the group that was migrated first. Permission escalation at its finest. This guide will tell you more about that.
Crowd Server or Data Center
Crowd doesn’t have an equivalent cloud product, although admin.atlassian.com works in a similar way. If you’d like to continue managing users in Crowd, you can connect it to a cloud identity provider, and then connect the provider to admin.atlassian.com.
Related pages
Was this helpful?