How are other Atlassian customers handling Jira's inability to export scriptrunner conditions?

Sara Nicholson_9gxoco

We are migrating from Server to Cloud. We have done numerous test migrations with different issues each time. It has been an extremely frustrating process with limited support from Atlassian. We are too far into our migration to hire a consulting company (which, in hind site, I would recommend to others in this situation - lesson learned) and tentatively plan to do our final cutover in 2 weeks.

One MAJOR issue we have is that Scriptrunner conditions do not migrate to the Cloud. So, with each migration, we have to manually edit every item that uses Scriptrunner (a large number of automation rules and workflow transition conditions).

We have asked Atlassian if we can export the workflow(s) (from Cloud) with all of the changes we have made, to Atlassian Marketplace (or just a file). This would allow us to save MANY hours of work. Then when we wipe our cloud test environment and do another test migration we would like to import those changes so we don't have to do the hours of manual labor. They can't or won't do this. We are a software company and we have developers who could actually do this, however, we don't have access to the database as we did on the server side. 

Is there anyone who would have any suggestions or recommendations on a way we could eliminate the hours of manual updates, capture this information, and be able to import them into our cloud environment?

Thanks!

Sara

Mark Segall

Hi @Sara Nicholson - You hit the nail on the head that Cloud Migrations can be quite complex when you have marketplace apps like Scriptrunner involved.  You are also correct that Atlassian's stance on these complex migrations is to lean on an Atlassian partner.

Scriptrunner is essentially a completely different product on Cloud vs Server/Data Center, mainly because on cloud marketplace partners are restricted to only what's available in the API. There's no way around the process so you need to either:

1. Spend considerable time upfront with each team understanding their use case.
2. Make the hard and unpopular decision to start from scratch on the use of such tooling and tell teams they need to justify any special customizations.

Ultimately, you need to make a decision on the two paths and perform all the work on your source environment to make it more cloud friendly before you take that step of migrating to cloud.