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

[Sara Nicholson]

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 · Accepted solution]

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.

[Sara Nicholson]

Hi Mark,

Thank you for responding... it is as I expected... you are correct about spending a "considerable" amount of time upfront AND starting from scratch to see if we could perhaps just use standard Jira automation rules to accomplish what we need won't work either because the import of automations doesn't even import our custom fields but rather identifies them as a deleted value or an ID #. So, I have to manually "fix" all of those as well. The migration tool doesn't even pull in our issue-type icons... just all very disappointing.. it isn't that we can't do the work or don't know how, it is all just disappointing when Atlassian is forcing customers to move to Cloud but doesn't have the tools to make the process smooth or time efficient, which is not a good experience for us but also severely affects the downtime of our Support Center for our customers.

We will have to deal with it but I so appreciate your time!

Thanks!
Sara

[Mark Segall]

Yes even Automation is like a different product.  Appfire offers a marketplace app called Configuration Manager for Jira that may be worth the investment to help with the migration.