Plan your Cloud migration
Documents to help you prepare to migrate your Atlassian Server products.
Will my organization need Atlassian Access?
Atlassian Access is an organization-wide subscription that connects Atlassian cloud products to your identity provider. It provides enterprise-grade authentication and additional security options and oversight across your company domains. Learn about Atlassian Access features and pricing
You will need an Atlassian Access subscription and a third-party identity provider (often known as an IdP) if you want to:
provide single sign-on for your users
create and manage user accounts automatically using SCIM user provisioning.
You won’t directly connect your external user directory (such as Microsoft Active Directory or Atlassian Crowd) to your Atlassian products. Instead, you connect a cloud-based identity provider. You may be able to populate it from your existing external directory, if that’s supported by your identity provider.
This page will help you determine whether you will need an Atlassian Access subscription to meet your single sign-on and user provisioning requirements. Atlassian Access provides more than just authentication so be sure to also take a look at the data security and governance features. Learn about Atlassian Access
About identity providers
Many Atlassian Access features rely on the connection to your identity provider. You can use the identity provider of your choice, but some capabilities are only available with selected identity providers.
Learn which identity providers we support
Compare your current user management setup
To help you determine whether you’ll require Atlassian Access, we’ve summarized the most common user directory and authentication setups in Server and Data Center and explain how you can achieve a similar result in Cloud.
Internal directory only
This setup is primarily used for small instances, where there is no need for external user management. It only uses Jira or Confluence’s internal user directory, not an external directory.
How it worked in Server / Data Center
All user details are created, managed, and stored in your product’s internal directory.
Users log in with the username and password stored in the internal directory for that product.
Admins add and remove users in the product manually.
Admins create groups to manage product access in the product manually.
How it will work after migration to Cloud
You can achieve a similar setup in Atlassian Cloud.
Users log to their Atlassian Account with their email and password.
Admins add and remove users at admin.atlassian.com.
Admins create groups to manage product access at admin.atlassian.com.
Requires Atlassian Access?
No, you don't need Atlassian Access.
Internal directory with LDAP authentication
This setup is used when you only want to authenticate users against a central directory.
How it worked in Server / Data Center
Each Server or Data Center product is connected to the external LDAP directory, and that directory is only used to authenticate user passwords on login.
Users log in with the username and password stored in the LDAP directory.
Admins add and remove users in the product manually.
Admins create groups to manage product access in the product manually.
How it will work after migration to Cloud
An organization admin could configure SAML single sign-on so authentication is managed centrally.
Users log in via an identity provider (SAML single sign-on)
Admins add and remove users at admin.atlassian.com.
Admins create groups to manage product access at admin.atlassian.com.
Requires Atlassian Access?
Yes. You will need Atlassian Access and your own identity provider.
External user directory or Atlassian Crowd
This setup is used when you want to manage user details and product access in a central directory.
How it worked in Server / Data Center
Each Server or Data Center product is connected to the external LDAP or Crowd directory, and that directory is synchronized to populate user details and group memberships. There are numerous variations of this approach.
Users log in with the username and password stored in the LDAP or Crowd directory.
Admins add and remove users in the external LDAP or Crowd directory.
Admins create groups to manage product access in the external LDAP or Crowd directory.
How it will work after migration to Cloud
An organization admin could configure SAML single sign-on so authentication is managed centrally, and SCIM user provisioning to create accounts and manage group memberships.
Users log in via an identity provider (SAML single sign-on)
Admins add and remove users in the identity provider.
Admins create groups to manage process access in the identity provider.
Note that the identity provider directory may be populated from an LDAP directory if supported by the provider.
Requires Atlassian Access?
Yes. You will need Atlassian Access and your own identity provider. SCIM user provisioning is only supported for selected identity providers.
SAML authentication
This setup is used when you want to authenticate users against an identity provider using SAML single sign-on.
How it worked in Server / Data Center
An identity provider or Crowd Data Center is configured for SAML single sign-on authentication in your Data Center product. Generally, either the product is also connected to an external LDAP or Crowd directory to populate users and group memberships, or Just-In-Time (JIT) provisioning is enabled.
Users log in via an identity provider (SAML single sign-on)
Admins add and remove users in the external LDAP directory, Crowd, or identity provider.
Admins create groups to manage product access in the external LDAP directory, Crowd, or identity provider.
How it will work after migration to Cloud
An organization admin could configure SAML single sign-on so authentication is managed centrally, and SCIM user provisioning to create accounts and manage group memberships.
Users log in via an identity provider (SAML single sign-on)
Admins add and remove users in the identity provider.
Admins create groups to manage product access in the identity provider.
The identity provider directory could be populated from an LDAP directory if supported by the provider.
Requires Atlassian Access?
Yes. You will need Atlassian Access and your own identity provider. SCIM user provisioning is only supported for selected identity providers.
OpenID Connect authentication
This setup is used when you want to authenticate users against an identity provider using OpenID Connect single sign-on.
How it worked in Server / Data Center
An identity provider is configured for OpenID Connect single sign-on authentication in your Data Center product. Generally, either the product is also connected to an external LDAP or Crowd directory to populate users and group memberships, or Just-In-Time (JIT) provisioning is enabled.
Users log in via an identity provider (OpenID Connect single sign-on)
Admins add and remove users in the external LDAP or Crowd directory.
Admins create groups to manage product access in the external LDAP or Crowd directory.
How it will work after migration to Cloud
OpenID Connect is not currently supported as an authentication method. You need to use an identity provider that supports SAML 2.0.
Google Workspace authentication
This setup is used when you want to authenticate users using Google Workspace (formerly G Suite).
How it worked in Server / Data Center
Server and Data Center products don’t provide the ability to connect to Google Workspace. There were some third-party integrations available.
How it will work after migration to Cloud
You can sync your Google Workspace domains and users under those domains to Atlassian Cloud. This allows all users on your email domain to log in to Atlassian products with their Google account. Users are added to a default group on first login. Learn how to connect to Google Workspace
Users can choose to log in using their Google account.
Admins add and remove users in the Google Workspace admin console.
Admins create groups to manage product access at admin.atlassian.com.
Requires Atlassian Access?
No, you don't need Atlassian Access to sync all users from Google Workspace to a single group called 'All users from Google Workspace'. However, if you want to be able to sync group memberships or require people to log in with Google, you will need Atlassian Access.
More information and support
We have a number of channels available to help you with your migration:
for more migration planning information, visit the Atlassian Migration Program website
for technical issues or support with strategy and best practices, contact our support team
for peer advice, ask the Atlassian Community
for expert guidance, work with an Atlassian Partner
Was this helpful?