Migration - JMCA is not migrating ScriptRunner data

[Salih Tuç]

Hey guys,

I am trying to learn migration details from DC to Cloud. For that purpose, I created a simple scenario in my DC trial in my local machine which contains basic Jira projects, workflows as well as Scripted Field, Listener and Jobs that created via ScriptRunner.

I know the "App migration" part in migration assistant is on "Beta" but from this documentation ; I was expecting to see the custom ScriptRunner implementations in Cloud after the migration. However, even if the App migration logs shows "all data for ScriptRunner is migrated", there is no change in ScriptRunner on Cloud.

What should I do in this case? Am I missing something or the only thing is creating custom scripts manually?

[Trudy Claspill]

Hello @Salih Tuç 

Welcome to the Atlassian community.

Are you using a version of the ScriptRunner app that is equal to or newer than the version mentioned in the documentation you referenced?

Which elements mentioned on that page as ones that should migrate are actually missing from your Cloud environment?

[Salih Tuç]

Hey @Trudy Claspill ,

ScriptRunner version is the latest (8.15.0), Jira version is the 9.4.11 (which was the latest LTS atm) and the JCMA is also the latest (1.10.3).

Actually, no data from ScriptRunner migrated. But in my case, I created one Scripted Field, one Job and one Listener in the ScriptRunner before the migration.

P.S. The ScriptRunner at the cloud site just has two sample Listeners in it; other than that it is all empty.

[Trudy Claspill]

I recommend that you contact ScriptRunner support about this, and it would be great if you report back here what you learn.

Support contact information can be found on their marketplace listing:

https://marketplace.atlassian.com/apps/6820/scriptrunner-for-jira?hosting=datacenter&tab=support

[Nic Brough -Adaptavist-]

Hi Salih,

To add to what Trudy said, there is a big problem with Scriptrunner migrations, although the cause is actually that Server/DC and Cloud are simply very very different products.

Scriptrunner sits on top of the Atlassian applications, and hence is also two very different products.  With a lot of stuff that cannot be automatically translated.  JCMA can "migrate" (meaning "rewrite") some stuff, but if you've done a lot of clever stuff, with it, there's no way it can.

The second warning box on https://docs.adaptavist.com/sr4jc/latest/scriptrunner-migration/migrate-from-scriptrunner-for-jira-server-to-cloud is the short version, but have a skim through the rest of the page to see what challenges you have.

Or raise the request as Trudy says - we're fielding a lot of migration requests and are more than happy to talk to you about it.

[Salih Tuç]

Hey @Nic Brough -Adaptavist- ,

Actually, all the things you said is already on my mind and surely I am expecting (and understanding) mismatches and "partial" migrations.

But, the thing is, none of the components are imported :) I mean I can understand not to import some custom clever stuff but I have doubts if we can't migrate a Scripted Field which is created by sample from ScriptRunner (issue picker example).

By the way, please do not understand me wrong, I just want to learn about details and capabilities of migration assistant. But as a customer, I was expecting to see the migration of some custom functions, fields, etc (even if they do not work in cloud and I need to rewrite them). But basically, it is just ignoring all things from ScriptRunner in Jira DC.

If this is the case, I think there should be no documentation that mention this:

The following features are migrated from Jira Server to Jira Cloud when using the Atlassian Cloud Migration Assistant.

And if there is a (partial or not) support but it is not working for me, I want to learn what did I do wrong.

[Nic Brough -Adaptavist-]

Scripted fields are one of the "custom clever stuff".  Cloud does not support scripted fields in the way server/DC does, and the scripts behind them would need to be migrated manually to support the way Cloud does scripted fields.

It is not ignoring all things, it is taking what it can.  But because Cloud and DC are so very different platforms requiring different technologies, and SR is very complex, there's no way it can translate most of SR's functionality - it needs a human to translate them.