Handling Custom Workflows, Fields, and Plugins During Jira Server → Cloud Migration

[carl]

I’m preparing to migrate our Jira Server instance to Jira Cloud and want to ensure a smooth transition. Some of our projects have custom workflows, fields, and plugins, and I’m unsure how these will behave once migrated.

My main concerns:

Will all custom workflows and statuses migrate correctly?

How should I handle custom fields or plugins that aren’t supported in Jira Cloud?

Are there pre-migration checks, tools, or best practices to ensure nothing breaks?

How can we test migrated projects before going live to avoid disruptions?

[Trudy Claspill]

Hello @carl 

Welcome to the Atlassian community.

I recommend that you start by reviewing the Cloud Migration materials provided by Atlassian. 

https://support.atlassian.com/migration/resources/

You need to review the features and customizations in your system against the documentation provided by Atlassian and the plugin vendors. In many cases there are capabilities that are not supported in Cloud or cannot be automatically migrated.

Next, for each plugin that you have find the listing for that plugin in the Atlassian Marketplace. Determine if it has a Cloud version. Check the Support section in the header to see if it says "Cloud Migration Assistance". Check the Support tab to see if they provide information about how to migrate to the Cloud and Feature Parity information.

With regard to elements that are not supported in Cloud you need to come up with a plan for addressing those. If you still need that data or feature in Cloud you need to look for an alternative way to get that. You may need to change to using different features in your on-premise instance before the migration, if you want to try to migrate the data and capabilities. Or you may need to look at manual process for recreating the data and capabilities in Cloud after migration.

You asked if there are premigration checks, tools, or best practices to ensure nothing breaks. The fact is something will likely break if you have never done a migration to Cloud before. For that reason it is strongly recommended that you do test migrations to help you discover the problems that you have missed in you preparations.

You can set up a trial of Jira Cloud to use as a destination for your test migration along with installing trials of the plugins you want to try to migration. I recommend that you make plans to do at least 2 test migrations as learning experiences.

For testing the results of the migration I recommend that you get some of your experienced users to run "day in the life" testing where they attempt to do the things they would normally do daily, along with productions of any reports that they use periodically.

Take time to think about if you really need all the data migrated to Cloud. For old data, do you need to migrate that? 

Consider the plugins that you use and the cost of having comparable plugins in Cloud. Do you really need all those plugins? Do you have multiple plugins that overlap in the functionality that they provide?

Have you looked at security concerns? Does the nature of your work raise concerns about data security or regulatory standards? Explore the data security and compliance information for the Atlassian product and each plugin that you want to use in Cloud.

Migrations to cloud are not a small undertaking. The amount of data you have, the complexity of your customizations, and the plugins that you have added can add to the challenges.  

If this sounds overwhelming, consider engaging with an Atlassian Solution Partner that specializes in Cloud Migrations. You can find such in the Atlassian Partner Directory.

(Disclosure: I work for Praecipio, an Atlassian Platinum Solution Partner with a specialization in Cloud Migrations, serving North America.)

[Artem Taranenko]

Additionally, have a look at the JCMA (Jira Cloud Migration Assistant) app. Atlassian have created this app to help you seamlessly move your out-of-the-box Jira data and configs into the cloud.

[Artem Taranenko]

Hi Carl,

Oh boy, the short answer is that you've got to check quite a bit of things. I'm writing a series of articles on DC to Cloud migration, and the instance assessment process would be the same for Server to Cloud.

Here's my article on app cloud readiness (https://community.atlassian.com/forums/Jira-articles/Assessing-Your-Jira-Data-Center-Apps-for-Cloud-Readiness/ba-p/3154724), and another on pre-migration clean-up (https://www.linkedin.com/pulse/lift-shift-mess-your-jira-data-center-cloud-uhivc/).

In addition to that, all your Power Suite SIL scripts and ScriptRunner scripts, plus any other Java or Python scripts that touch the API would need to be rewritten for Cloud.

This is because there are key differences in architecture between on-prem versions and Cloud.

**Key differences include:**
- No P2 plugins running inside Jira
- No direct access to Jira's internal Java APIs
- No direct database access
- A different REST API surface and a different authentication model

I've written a two-part guide on how to tackle customization assessment, but it won't be published for another week (I'm publishing one article a week). If you want to reach out to me on LinkedIn, feel free.