Documents to help you prepare to migrate your Atlassian Server products.
A collection of topics that help prepare you to migrate your apps to the Cloud.
Ensure you’re ready to migrate with these pre-migration checklists for Jira, Confluence, and Bitbucket Server or Data Center.
Migrate your Jira data with the Jira Cloud Migration Assistant. This is the recommended way to migrate.
Migrate your Confluence data with the Confluence Cloud Migration Assistant. This is the recommended way to migrate.
Documents that walk you through using the Bitbucket Cloud Migration Assistant to migrate to Cloud.
Resources to help get started and testing after you migrate.
Everything you need to know about moving your data from one cloud site to another.
A set of optional best practices that you can apply to your migration.
With an Atlassian Access subscription, you can use SCIM to provision user accounts and sync group memberships from your identity provider. The process to set up SCIM user provisioning, and when this should happen, will depend on the products you’re migrating and the data migration method you plan to use.
Before you begin:
Set up SCIM user provisioning
The process will depend on the products you’re migrating and the data migration method you’re using.
When using the Migration Assistants
You can configure SCIM user provisioning and sync users from your identity provider before or after starting the migration. The Jira Cloud Migration Assistant and the Confluence Cloud Migration Assistant will 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 people from both internal and external server directories.
However, when deciding on your strategy, you will want to reduce the risk of creating duplicate Atlassian Accounts. We recommend you start by verifying your domains and claiming accounts so that you identify any issues early. If there is a chance that your users' Atlassian Account email addresses won’t match the primary email addresses in your identity provider, you may want to enable SCIM user provisioning last, after you’ve completed the migration, checked that your users data is mapped correctly, and performed any required changes to Atlassian account email addresses.
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. After migration, you should reconfigure your identity provider and directory from scratch. We recommend this method.
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. There is a higher chance of problems occurring when the sync is in a ‘paused’ state, so in most cases we recommend you stop the sync from the identity provider and delete the existing provisioning directory from your Atlassian organization.
Frequently asked questions
How does SCIM work for existing cloud users and groups?
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, the user’s SCIM record will be linked to the existing Atlassian account.
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 an Atlassian account for the user, or link the SCIM record to an existing Atlassian account.
If a managed user is deleted in the identity provider, SCIM will deactivate the user’s Atlassian account. This means they won’t be able to access any cloud products.
If a group is deleted in the identity provider the group is then deleted from the cloud site and directory. If the group was used to provide product access or permissions, the group members will lose access. Re-syncing the group, or creating a new group with the same name won’t restore access.
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
Was this helpful?