Hi Atlassian Community,
Today we’re announcing that from February 01, 2022, we’ll begin transitioning customers looking to migrate fewer than 1000 users from Site Import to the Jira Cloud Migration Assistant. We’ll follow a gradual rollout plan based on the number of users to be migrated from February to May 2022. Site Import will continue to be available for migrators looking to migrate more than 1,000 users until further notice.
Even after this change goes into effect, all customers will continue to be able to import Jira Cloud backups using Site Import to restore or reset cloud sites.
We want to let you know about the key dates and upcoming changes well in advance so you and your teams can prepare for this change.
|Number of users you’re migrating||You’ll be redirected to the Jira Cloud Migration Assistant starting|
|Less than 10||February 1, 2022|
|11-100||March 1, 2022|
|101-250||April 1, 2022|
|251-1000||May 4, 2022|
|More than 1000||Site Import will continue to be available until further notice|
To learn how you can view the number of licensed Jira Server or Data Center users, see the Viewing your licensed user count section on the Licensing your Jira applications page.
We acknowledge that Site Import has been a popular tool for cloud migrations for the past few years. However, it is fragile, does not offer flexibility (no option to migrate in phases), and does not support as many migration use cases as the Jira Cloud Migration Assistant now does (for example, unable to migrate apps). Therefore, Site Import can introduce friction for <1000 user migrations, and customers migrating fewer than 1,000 users would have a better migration experience using the Jira Cloud Migration Assistant.
That being said, our top priority is helping you get to cloud, regardless of the migration method you choose. That’s why we’ve created an escalation path if you’re working on migrations that require the use of Site Import.
You may require the use of Site Import if:
You’re in the middle of a migration using Site Import
You have already planned your migration using Site Import
You’re unable to use the Jira Cloud Migration Assistant because of any technical issues
If you have any concerns with this change, please comment on this post or raise a support ticket.
We are continuing to invest in making the journey to cloud easier for you. The Jira Cloud Migration Assistant is increasingly becoming the preferred tool of choice for server-to-cloud migrations. Here’s why 70% of migrating customers with fewer than 1,000 users choose the Jira Cloud Migration Assistant:
By the time this change goes into effect, JCMA will support additional migration use cases that are important to customers such as:
Automated app migrations BETA
Jira Service Management Migrations BETA
Advanced Roadmaps migrations BETA
Unmapped configurations aren’t migrated, which means that configuration schemes that aren’t used aren’t migrated. This reduces admin complexity in cloud.
We keep a track of configuration schemes that have already been migrated. So, duplicate configurations aren’t created, which reduces post-migration cleanup efforts in cloud.
Project filtering and usage insights help decide which projects are recently used, prioritize what to migrate, and whether to leave the projects behind or archive.
Retain your original configuration. Projects with shared configuration will continue to have the same configuration mappings (workflow scheme, permission scheme, field configuration scheme, screen scheme, issue types, and statuses) after migrating to cloud even when projects are migrated at different times.
Attachments in the background. As soon as a project’s data (projects, issues, and configuration) is migrated, you can log in and start using issues in cloud, significantly reducing downtime. Attachments will be moved to your cloud site in the background.
You can install the migration assistant on multiple server instances and move projects to multiple cloud sites by running one or multiple migrations.