Jira is one of the most popular project management tools on the market. As its popularity grows, so does the number of add-ons available to improve its functionality. However, when it comes to migrating from Jira Server to Cloud, it’s important to evaluate and prepare the add-ons to ensure a smooth transition. In this blog, we’ll discuss the best practices for evaluating and preparing add-ons when migrating Jira from Server to Cloud. Read on to learn more!
What Part do Add-ons Play in Cloud Migrations?
The first thing you need to do is have the full picture of your instance. This ishould be relatively easy and something an Atlassian Admin or your Technical Account contact at your company can provide.
Companies that fail to migrate from Jira Server to Jira Cloud tend to fail in the same, common ways. s. As an Atlassian Solution Partner, we have seen Add-ons delay Cloud migrations for months.
Why?
Jira is the most extensible collaboration platform you can find, and it relies on a marketplace of 5000+ add-ons to augment or add to Jira feature sets. Add-ons can become just as important as the core issue tracking that Jira does natively. There is a large variety of add-ons that add to Jira’s native capabilites by doing this such as reporting, that often keep executives happy in the platform, to add-ons that handle test cases that can be critical for Quality Analysis teams. The list of add-ons available in the Jira platform are endless.
The average Jira instance has over 10 add-ons, and if you are looking for like-for-like capabilities in a Jira Cloud instance, then you need to know what impact there would be. Your users are counting on it!
Why are Add-ons Problematic for Companies Migrating from Server to Cloud?
Jira Server add-ons follow a different structure and architecture than that of Atlassian Cloud. Atlassian Marketplace vendors have done an amazing job over the last 4 years providing Cloud variants for their add-ons. Atlassian stressed a cloud-first approach for the Marketplace, and it’s responded. However, it is not all that simple if you’re speaking of performing a Cloud Migration.
- Are to find a like-for-like Server/Cloud variant of an add-on. Migration limitations are commonplace, and you will lose some level of data. The value of that data may vary from organization to organization, but it needs to be known and addressed before the Migration. It may be solved by manual data conversion, are you ready to do that?
- The developer may have varying degrees of Cloud Migration documentation and support.
- Lastly, you may not have a Cloud variant for a critical add-on, in which case, you need to have some tough conversations about what it does, whether a substitute Add-on exists, and whether the substitute is agreeable to the user base.
How to Approach Evaluating Your Server Add-on Stack? What Add-ons do You Have?
The first thing you need to do is have the full picture of your instance. This ishould be relatively easy and something an Atlassian Admin or your Technical Account contact at your company can provide.
Review Your Add-on Usage & Criticality
When it comes to reviewing how you use your add-ons and if they’re critical, at Trundl, we like to use the Admin Toolbox for Jira. It let’s us find out how critical or important an add-on is in our portfolio in an objective way.
A project manager may say… “I need that Add-on!” But are they really using it? This lets you know. You can run a command on the database and query each add-on in question for the number of work events it’s been tied to in recent months. You can see where it’s been used in…
- Post Functions
- Conditions
- Validators
- Properties
- Triggers
Review the Add-on’s Cloud Migration Documentation & Raise a Ticket
Most Marketplace add-on developers want to help you. Cloud Migrations are common, and by now they should have helpful documentation and contact information.
Any well-organized Marketplace vendors will be a part of Atlassian’s App Migration Platform (AMP). Raise a ticket and they will respond. The App Migration Platform was set up to help communication between the Marketplace vendor and the Add-on’s user base. Cloud Migrations are serious projects, so getting the vendor’s responses for your use case is a good thing to have a record of. If they are not officially participating in AMP, the vendor’s contact information should have a dedicated Cloud Migration query path. They are used to a lot of technical questions. Cut & paste for them could mean success vs. disaster for you. It needs to be part of your due diligence. Your Jira stakeholders may have firm opinions on that list when you share it, and depending on their influence, their opinion could determine what steps you need to take next in your migration plans.
Lastly, if the App Migration Platform is not there, ask if it’s part of their future roadmap. You might get lucky and it will coincide with your migration plans!
The Easy Migration Scenario
The App developer recieves a move ticket from you, and based on migration timing, they move the data from each Server app to its Cloud variant on your Cloud instance. The Marketplace vendor will actually be performing the Migration for their App, not Atlassian. You just need to allow for the developer to access your data, procure the Add-on (licensing), and manage cut-over timing to coincide with your larger Migration plans for your entire instance.
This assumes you are accepting (and fully aware of) the Migration Limitations and your team is going forward with the Migration.
Prepare for More Complex Migration Scenarios
Below are some single app scenarios we at Trundl have encountered with Atlassian Customers. These are isolated, archetypal use cases. Most Migration use cases will have compounded versions of the below (multiple combinations), but we hope they inspire you in creating a total Migration plan that makes the Add-ons a less risky part of your project.
- Scriptrunner Example: Using another Add-on to move/convert at risk data
-
- In Scriptrunner, the behaviors configuration (used for manipulating fields) does not migrate to the Cloud variant. Atlassian does not support them.
- Power Scripts, alternatively, has “live field” scripts which are much friendlier to Jira Cloud for similar functions of Scriptrunner.
- JMWE Example: Finding an Alternative Add-on
-
- Jira Misc Workflow Extension is a powerful automation scripting Add-on that makes workflows more powerful, however, their Cloud variant does not allow for groovy scripting as part of the migration. Instead, it uses Nunjucks expressions/scripting.
- You can review how to convert the Groovy Scripts to Nunjucks (limited community knowledge)
- If the data conversion is insurmountable, you can look into alternative automation apps, such as JSU Automation Suite or Jira Workflow Toolbox.
- Xray Example: Manually Recreating Data for the Migration
-
- Xray is a very popular test case management tool for Jira. While it has a Cloud variant, there is no direct way to migrate historical test cases to the Cloud when moving from Server.
- The solution for migrating this data? An option may be to use Xray’s Python tools to recreate the test cases.
With 5000+ Add-ons in the Atlassian Marketplace, you will likely face many other scenarios. You may need to use an API to recreate data, or you may need to drop an Add-on completely. Migration Project Managers need to get ahead of these variables. It takes research and it takes, at times, serious negotiations with users on what’s possible and not possible.
Need help on handling add-ons in your cloud migration?
Book time with Trundl to get a perspective. We can help with Atlassian licenses as well.
