• Products
  • Documentation
  • Resources

Recommendations about Atlassian Access

If you're planning to subscribe to Atlassian Access for advanced user management features, including SAML single sign-on (SSO) and System for Cross-domain Identity Management (SCIM), we have a few recommendations. But before you begin, determine your user migration strategy.

SAML SSO

If you’re planning to use SAML SSO in Cloud, set up SAML SSO before migrating. That way, users won't have to switch login experiences.

SCIM user provisioning

The process for setting up SCIM user provisioning will depend on the products you’re migrating and the data migration method you’re using.

When using the Migration Assistants

You can configure, enable, and sync users from SCIM before or after starting the migration. The Jira Cloud Migration Assistant and the Confluence Cloud Migration Assistant associate the data using email addresses. It won’t break the user and content association during the data sync and so you can keep SCIM enabled during the migration. The Migration Assistants will also migrate users from both internal and external server directories.

When using Site Import and the Migration Assistants

Migrate users and groups with the Jira Cloud Migration Assistant or the Confluence Cloud Migration Assistant. Learn how to use the Jira Cloud Migration Assistant to migrate

Then, use Site Import to migrate your data.

If you have enabled SCIM before the data migration

When migrating data using Site Import, perform these steps:

  1. Disable SCIM.

  2. In Jira Cloud, on the Import Jira Server page, Select I've migrated user data using the Jira Cloud Migration Assistant.

  3. Import the XML backup file by selecting Import data. Leave all users in the XML files you’re importing.

  4. Configure, enable, and sync users with SCIM.

If you’re migrating Confluence, migrate spaces using Confluence Cloud Migration Assistant.

If you haven’t enabled SCIM before the data migration

When migrating data using Site Import, perform these steps:

  1. In Jira Cloud, on the Import Jira Server page, Select I've migrated user data using the Jira Cloud Migration Assistant.

  2. If you’re migrating Confluence, migrate spaces using Confluence Cloud Migration Assistant.

  3. Configure, enable and sync users with SCIM, if applicable.

Disable SCIM

There are two ways you can disable SCIM.

  • Delete provisioning directory on Atlassian: This disconnects Atlassian organization from identity provider (IdP) provisioning, and all Atlassian accounts remain in the same state they were during provisioning. All previously synced groups become local and retain all membership and product associations.

  • Stop or disable provisioning on the IdP: This sends a signal to Atlassian that previously provisioned users are no longer actively maintained from the IdP. Refer to your IdP documentation to know how to temporarily stop or disable provisioning. We recommend this method.

Frequently asked questions

How does SCIM work for existing cloud users?

  1. If a user was migrated with the Jira or Confluence Cloud Migration Assistant or the user exists on the cloud site with the same email address, SCIM won’t import the user to the cloud site.

  2. If a user was not migrated with the Jira or Confluence Cloud Migration Assistant or the user doesn’t exist on the cloud with the same email address, SCIM sync will create the user.

  3. If a managed user is deleted on the IDP, SCIM will deactivate the users on the cloud site.

After migrating, why do the groups on Atlassian Cloud contain additional users compared to the groups in the identity provider?

If you synced a group using SCIM and the group appears as a locked group in the cloud site, and when you migrate using the Migration Assistants, users will be added to the locked group and will remain in the group even after subsequent SCIM syncs.

What to do when you run into group conflicts

Group conflict happens when you migrate a group using the Migration Assistants and then you enable the SCIM. SCIM syncs the same group via your identity provider (IdP) that might have a different set of users.

You may run into group conflicts when migrating or after migration. When the sync happens, we’ll warn you about duplicate group names between your IdP and your Atlassian organization. You’ll be able to accept or reject changes to group members before you sync those groups. Learn more about resolving group conflicts before syncing

Additional Help