This article was written by Kamil Beer, an Atlassian Engineer at iDalko.

Usually, this series of articles explains how to migrate various apps to the Atlassian Cloud. But today, we want to focus on the Jira Cloud Migration Assistant’s (JCMA) newest version – 1.6.3., which supports automatic migrations of add-ons. We will explore the recent changes, run a test and show you the results.

New Assessment Stage

Until now, moving apps to Cloud was a blackbox. Each plugin worked differently on Cloud (if it even was there) and if a vendor didn’t provide clear documentation, the result was anyone’s guess. Over time, this improved and some developers even provided their own migration tools, like Structure for Jira. Apps were covered in the assessment step of JCMA.

On this screen, “See pathway” contained a link to the add-on documentation (if the plugin had a Cloud option). “Contact vendor” displayed the app page on the Atlassian Marketplace.

In version 1.6.3, Atlassian introduced migration paths. You can review which ones are available in the second column, which has several different options:

• Automated path, Stage 1
• Automated path, Stage 2
• Automated path
• View Path
• Contact Vendor
• Upgrade app

Three of these mention an “Automated path”, but what exactly is it? It describes an app that can migrate its data on Cloud automatically via JCMA, e. g. Scriptrunner will transfer Custom Script Fields, Listeners, JQL and Workflow functions.

Stage 1 means that there is a none or a low success rate of the automatic migration, and that you should contact the vendor if problems arise. This sounds intimidating. In the app developer’s linked documentation, the problems are usually described as being caused by the poor feature parity between on-prem and cloud.

Stage 2 are apps with a high probability of a successful automatic migration. We don’t know how Atlassian defines “low” or “high”, but it appears that Stage 2 simply preserves more add-on settings and customizations than Stage 1.

View path means that it is possible to migrate the app, but not through JCMA.

Automated path without a specified stage describes apps that, according to the Atlassian documentation, you only need to install for them to work. We have reviewed 62 commonly used apps, out of which at the time of writing (November 2021), 10 had a Stage 1 path, two a Stage 2 path, and none had one without a stage.

For testing, we decided to migrate three apps, each with a different path. Structure – Project Management at Scale (Stage 1), Clone Plus (Stage 2), and BigPicture (View Path). The target was a testing instance at https://kamilmigratest.atlassian.net.

JCMA Redesign

The Jira Cloud Migration Assistant has a new look!

Instead of the “Plan your migration” stage, linking to the relevant documentation, Assess your apps is now the first step. We already reviewed how it works. The next two are Prepare your apps and Migrate your data.

Prepare your apps connects you to the Cloud site you want to move to. JCMA will then request to install the apps there and review their privacy policy.

As with the assessment, the add-on preparation shows you which plugins have already been deployed on Cloud.

The third step of this stage lets you approve the privacy policies, as the vendor needs to access your server to transfer the add-on data. However, this wasn’t necessary for any of the apps we tested, and Jira only told us to move the plugin contents ourselves. It seems that it will be possible to migrate user data somehow in the future, and here you will need to consent to it.

During writing of the article, this screen has changed:

The third and final stage is Migrate your data, which hasn’t changed much from earlier. You choose the projects, users and groups to move, confirm the apps and review for errors or other warnings that could impact the process.

And then, it’s time!

Testing the Migration Paths

As mentioned, we decided to test the new JCMA on three apps including their data and custom settings.

For Structure, we have created an object called “Agile Backlog” that contains 33 issues and a “Filter”, “Group by”, “Sort by” and “Insert issues” automations, along with a customized Basic View and two Transformation filters.

For Clone plus, we created a custom “plus clone” option (this lets you change the project and issue type while cloning) with this setup:

# Show this action for all projects, issue types and status

1.plus.condition.*.*.* = true

1.plus.role.* = Support, Administrators

1.plus.label = Special Clone 1

1.plus.tooltip = Special Clone Description 1

1.plus.type.*.*.* = 10002

1.plus.set.summary = This is a clone of: %original_summary%

And finally, for BigPicture we will be migrating a simple Program Box with data in the Gannt and Resources modules, including custom columns view.

Let’s begin!

Migration Results

JCMA first notified us that Structure is still Stage 1 – it might not migrate successfully. We decided to proceed anyway.

Most of the objects were transferred, but Structure got stuck at 0%. This remained the same at the 12-minute, 32-minute and 2 days marks.

At this point, we decided to skip it and review what was actually migrated, based on what JCMA considered „complete“.

• All users were successfully transferred and received a cloud invitation.
• All groups were moved and two new ones were created: „jira-admins-kamilmigratest“ and „jira-software-users-kamilmigratest“.
• All projects were migrated and added to the existing ones.
• Clone Plus for Jira had its option copied on cloud, but the only parameters that persisted were the custom summary and label. The tooltip, issue type and condition were removed. ❌
• Structure was installed, but after opening the plugin, the error „The structure does not exist or is not accessible“ appeared and the add-on was unusable. ❌
  • In Structure’s system settings, the app has recognized the migration, but with a „You haven’t run the migration yet“ notice and an error message.
• BigPicture have first shown us the „BigPicture is loading… Please wait“ screen, which stayed for almost an hour. Then, the add-on was found to be empty (which was expected, as the path wasn’t automatic).

Conclusion

The results of the JCMA 1.6.3 test and its automatic app migration paths are far from favorable. Almost no add-ons are in Stage 2 and the only one we tested moved only a few custom settings. The problem wasn’t feature parity: tooltip, type and conditions are all available on Clone Plus’s cloud version.

The Stage 1 plugin, Structure, froze JCMA, which displayed a migration status of 0% even after two days after executing the transfer and made the cloud add-on unresponsive.

The third plugin, BigPicture, which didn’t have an automatic path, didn’t migrate anything.

Because it wasn’t possible.

This is an excerpt from the online documentation of Softwareplant, the developer of BigPicture. Right now, they are working on a way to back up cloud data, so you can transfer it to another cloud instance (same with server). Another feature details the possibility to migrate the BigPicture database from server to cloud. While all of them are scheduled to roll out in Q4/2021, none are ready at this point.

It seems that right now, JCMA for migrating apps is not of much use. We will need to wait before JCMA is fully functioning for the majority of add-ons, which might prove to be a challenge for both Atlassian and the plugin developers.