Transitioning Jira Server-to-Cloud migrators from Site Import to the Jira Cloud Migration Assistant

[#1]

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.

Why we're making this change

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.

Benefits of the Jira Cloud Migration Assistant

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:

Supports important migration use cases

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

Reduces complexity

• 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.

Maximizes business continuity

• 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.

Allows you to move one or multiple projects at once or in phases

You can install the migration assistant on multiple server instances and move projects to multiple cloud sites by running one or multiple migrations. 

---

Need help on your migration and don’t know where to begin? Visit the Atlassian Migration Center or get in touch with our verified Solution Partners.

[abhishek_sharma03]

Hi @Vineet Gandhi , Will JCMA be capable of migrating dashboards and boards that are shared in multiple projects to cloud ? At the moment this feature is not available.

[Nick Dring]

As I have mentioned in another post, I was quite relieved when I saw that JCMA was finally working with JSM Projects. Unfortunately, it still doesn't work for us. Manually importing to the cloud isn't working yet for us either. I've been trying to get this done for a month and we still haven't run a successful test run. It's a nightmare.

[Vineet Gandhi]

Hi @abhishek_sharma03, Migration of Dashboards and Cross Project Boards is on our roadmap and we should be able to enable this within the next couple of quarters.

[abhishek_sharma03]

Hi @Vineet Gandhi

So kind of you to take time of your busy schedule and respond. Really good to know that it is in your roadmap for next couple of quarters. Many thanks for the update. This helps us to plan the scope of migrations more efficiently and set the expectations accordingly with our clients.

[Vineet Gandhi]

No problem @abhishek_sharma03 

Please watch these tickets for updates:

Support Migration of Dashboards: https://jira.atlassian.com/browse/MIG-164

Support Cross-project boards migration: https://jira.atlassian.com/browse/MIG-169

[Vineet Gandhi]

Hi @Nick Dring , Sorry to hear that you have been facing issues. May I request you to please reach out to our migration support team through this form. 

[Nick Dring]

Hi @Vineet Gandhi I have a support request open already. But like I said it's not a easy-going process.

[Nestor Vigo]

Hi @Vineet Gandhi  I hope you are very well! What is the target date for the JCMA to support the migration of Advanced Roadmaps data please?

We are in the middle of the migration to the Cloud and still do not have clarity on delivery dates from Atlassian to handle this dependency on our Timeline.

Thanks! 

[Mark de Bont [Terberg]]

Is the " licensed user count" the user count on the server side or the cloud side? Also, will I be able to migrate using a DC trial license after 1 Feb. 2022?

[Vineet Gandhi]

Hi @Nestor Vigo 

Thanks for reaching out. I am pleased to inform you that we recently launched the capability to migrate Advanced Roadmaps through JCMA. 

Please see further details here: https://community.atlassian.com/t5/Atlassian-Cloud-Migration/Advanced-Roadmaps-migration-now-supported-in-the-Jira-Cloud/ba-p/1885579

Hope this helps.

[Vineet Gandhi]

Hi @Mark de Bont [Terberg] 

We will be taking the server license user count into consideration. The restrictions will not be based on license type and will only be based on user count. 

[Aggelos Paraskevopoulos _Relational_]

@Vineet Gandhi We are running into a serious problem when migrating issues that have sprint refs that belong to cross-project boards (not migrated). These issues fail to migrate as well

ERROR ABC project-import We couldn't import Issue ABC-XXXXX because of 1 missing dependencies: Custom Field 'Sprint'. This caused 180 other items to fail. Check the reasons for the missing dependencies on your server site.

We have an open (MOVE) ticket with support, but I thought to post here as well. Is this an expected behavior?

[Rob Horan]

Aren't there still limitations of the JCMA that are better suited to site import?

Advanced Roadmaps seems to have a lot that isn't migrated:

• Classic plans

• Any plans that has issue sources as filters and cross-project boards

• Unsaved scenario data

• Saved views

• User defined custom fields of type

  • Parent Link

  • Team

  • Target start

  • Target end

The list of Jira items not migrated is also long:

Project setup

• Custom field language translations

• Workflow functions

  • Properties

  • Triggers

• Notification schemes - projects are added to the default schemes in cloud

• Mail handlers

• Project avatars

• Links to issues or entities that are not migrated

Jira global entities and permissions

• Global permissions

• General configuration (timezone, language, etc)

• Dashboards

• Cross-project boards

• Boards not connected to the projects being migrated

• Boards that belong to inactive users

• Filters on boards that are not migrated

• Confluence links

• Webhooks

Users and groups

• Users and groups from inactive directories - make directories active to migrate them

Specific app data

• App data of the ‘Automation for Jira’ app is not included in the migration.

User profiles

• User avatars. Users will need to update their avatars after migrating

• Passwords. Unless you've set up SSO, users will need to reset their passwords after migrating

• Timezones. Timezone information on a per-user profile will be lost

Other issue types

• Archived issue

[Nick Dring]

I'm having a complete nightmare with this migration business.

First of all, I had issues with inactive users. When I finally get that done I find that I can't use the site import function anymore because I don't have enough users so I'm forced to use JCMA which has its own issues which I'm having real trouble fixing. I'm on the road to hell.

I'm in touch with Atlassian support and they are trying to help but its still not happening. I started this in september.

[Rob Horan]

Are there any easy ways to migrate dashboards, shared boards, and workflow properties? 

(EDIT: there is a dark feature for dashboards)

[Rob Horan]

That last question wasn't rhetorical, I'm really hoping someone knows :)

[Rob Horan]

It would be beneficial if site import was still an option for migrations.  In addition to not having to manually recreate a large set of objects that the JCMA does support, there are many potential migration-breaking problems, and the error messages provided are often vague.

For example:

2022-05-24 18:52:28.784 ERROR KEY project-import We couldn't import Issue KEY-1234. Reason: customfield_10049: Specify a valid option 'id' for MyCustomField. This caused 192 other items to fail.

Here's another:

2022-05-24 19:05:39.428 WARNING KEY project-import We couldn't import Issue Link 'Epic-Story Link' (from KEY-1234 to PRJ-5678) because of 1 missing dependencies: Issue PRJ-5678. Check the reasons for the missing dependencies on your server site.

The problem for those performing the migration is that there is no documentation explaining these errors, nor are there steps to follow to resolve them.

For example, what are the missing dependencies?   How can we check for the reasons they are missing?  Is this an issue link, or is there something else?

Site imports would seemingly prevent this as all information would be ingested as is.