Migrating Jira ScriptRunner for Server to Cloud: Revisited

<p>It has been nearly two years since we <a href="https://www.highwaythreesolutions.com/blog/scriptrunner-for-jira-migration-evaluation">last wrote about migrating ScriptRunner for Jira</a> and there have been significant changes in the JCMA, the extent to which Adaptavist has been able to streamline the migration to cloud, and closing the gap on feature parity between<strong> ScriptRunner on server vs cloud.</strong></p> <figure class="wp-block-pullquote has-text-align-left has-border-color has-cyan-bluish-gray-border-color has-black-color has-text-color has-background has-small-font-size" style="border-width:3px;border-radius:15px;background-color:#abb7c291"><blockquote><p>TL;DR: Migrating ScriptRunner for Jira from server to cloud is much smoother than it used to be.</p></blockquote></figure> <p>We recently helped a client migrate from Jira server to cloud who were heavy users of ScriptRunner for Jira. We used the <strong>JCMA and the app migration pathway</strong> for ScriptRunner was straightforward and worked with no errors.</p> <p>What we really liked was that the app data migrates, even for items that will require updates in the cloud post-migration. This makes it straightforward to verify that all the app data has migrated. (As opposed to when an app migration will selectively only migrate the app data that is relevant in the cloud.) In the latter case you are left wondering what got left behind, and what may be missing that requires a different cloud approach. Given how the ScriptRunner for Jira data migrates, you are able to <strong>dive right into your post-migration changes</strong> as the original server data is available in the cloud.</p> <p>We don’t want to mislead anyone; migrating ScriptRunner for Jira still requires<strong> manual intervention </strong>and you will need to plan ahead to determine appropriate runbook steps and prepare a post-migration update plan. Having said that, Adaptavist has you covered with excellent documentation and support. To be clear: where intervention is required, it is a result of changes in the Jira cloud API and the Jira cloud architecture, not because Adaptavist isn’t trying hard enough.<span style="text-decoration: underline;"> App vendors are at the mercy of the hooks Atlassian has made available.</span></p> <h2 class="wp-block-heading">What did it take to migrate?</h2> <p>As mentioned, the ScriptRunner for Jira data migrated automatically using the JCMA, but we did need to take steps to get everything working in the cloud. Here is an overview of those activities:</p> <figure class="wp-block-image"><img loading="lazy" decoding="async" width="1024" height="633" src="https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog--1024x633.png" alt="Convert server scripts to work in the cloud Evaluate workflow modifications and adopt alternatives Evaluate filters and modify where necessary Manually configure script variables in the cloud Fix Listeners, Scheduled Jobs, Behaviours, and Workflows to use converted scripts" class="wp-image-2118" srcset="https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog--1024x633.png 1024w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog--300x186.png 300w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog--768x475.png 768w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog--1536x950.png 1536w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog-.png 1940w" sizes="(max-width: 1024px) 100vw, 1024px"></figure> <p></p> <ol> <li>Convert server scripts to work in the cloud</li> <li>Evaluate workflow modifications and adopt alternatives</li> <li>Evaluate filters and modify where necessary</li> <li>Manually configure script variables in the cloud</li> <li>Fix Listeners, Scheduled Jobs, Behaviours, and Workflows to use converted scripts</li> </ol> <p><strong>The biggest disappointment was the gaps in the workflows</strong> using ScriptRunner scripts. Casting blame aside (I’m certain this is more about how Atlassian has designed the workflows than Adaptavist failing to include functionality), this is an area that required the most analysis and the greatest number of changes in the cloud. Alternatives were a mix of using automation rules and leveraging Jira cloud workflow functionality – this was deemed easier then writing new scripts to achieve what existed on server.</p> <figure class="wp-block-pullquote has-text-align-left has-border-color has-background" style="border-color:#abb8c3;border-width:3px;border-radius:15px;background-color:#abb7c291"><blockquote><p>We recommend anyone migrating have a very close look at the <a href="https://docs.adaptavist.com/sr4js/latest/scriptrunner-migration/migrating-to-or-from-cloud/feature-parity">Feature Parity table </a>provided by Adaptavist.</p></blockquote></figure> <p><strong>The biggest surprise was the impact on saved filters</strong>. Initially we were so focused on the workflow analysis we almost missed that many of the saved filters for this instance were using ScriptRunner JQL functions that either didn’t exist in the cloud or had a different keyword in the cloud. Thankfully the filters with missing JQL functions were not in use any longer, but for others planning a migration do not forget to review the details outlined in the previously mentioned Feature Parity table, along with the <a href="https://docs.adaptavist.com/sr4js/latest/scriptrunner-migration/migrating-to-or-from-cloud/migrate-from-scriptrunner-for-jira-server-to-cloud/pitfalls">Pitfalls</a> description.</p> <p>Important note: <strong>Any place a ScriptRunner script is referenced or groovy script code is embedded will require an update in the cloud</strong>, even though the related entity will migrate. For example, Listeners will migrate automatically with the JCMA, but the script code will need to be updated in the cloud. These Listeners will be automatically disabled in the cloud and flagged has having incorrect script code.</p> <h2 class="wp-block-heading">Recommended approach when migrating</h2> <figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="633" src="https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog2--1024x633.png" alt="" class="wp-image-2119" srcset="https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog2--1024x633.png 1024w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog2--300x186.png 300w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog2--768x475.png 768w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog2--1536x950.png 1536w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2023/08/Script-Runner-Blog2-.png 1940w" sizes="(max-width: 1024px) 100vw, 1024px"></figure> <h4 class="wp-block-heading">1. Understand app usage on server</h4> <p>Go through all the available ScriptRunner for Jira server features and take stock of what you are using. And for each feature in use, do an inventory of the scripts. Pay attention to where scripts are saved as files and where script code is embedded; it will be easier when converting the scripts if you have consistently used script files instead of embedding. You should consider updating where scripted code is embedded if you have a lot of occurrences of this nature.</p> <p>It is easier to convert when the ScriptRunner code is in separate files because you can convert them ahead of your migration and have them ready to upload to the cloud. With embedded groovy code you have to wait until after the data is migrated to do the conversion. This will likely extend the migration downtime and will complicate your Migration Runbook.</p> <p>Pay close attention to workflows and don’t forget to get an inventory of filters using ScriptRunner JQL functions. We find it easier to do the filter analysis by extracting the searchrequest table from the database and then looking for rows with JQL strings that match various conditions. In this case it would be looking for rows (i.e. filters) that are using any of the ScriptRunner functions that have changed or do not exist in the cloud.</p> <h4 class="wp-block-heading">2. Prepare for migrating</h4> <p>Apart from the analysis, planning and capturing steps for your runbook, preparing for migrating will likely be focused on converting the scripts that you will need in the cloud. Adaptavist provides a <a href="https://docs.adaptavist.com/sr4js/latest/scriptrunner-migration/migrating-to-or-from-cloud/migrate-from-scriptrunner-for-jira-server-to-cloud/rewriting-scripts-for-cloud-hints-and-tips">very good guide</a>.</p> <p>We also used this time to do the in-depth analysis for the workflows that had been configured to use ScriptRunner scripts, especially for the functionality that has to be adapted or modified in the cloud.</p> <h4 class="wp-block-heading">3. Migrate using the JCMA</h4> <p>This step is straightforward – make sure you have selected to migrate the ScriptRunner app and you choose the option to include app migration in your JCMA migration plan.</p> <h4 class="wp-block-heading">4. Run ScriptRunner JQL keywords synchronization</h4> <p>After you have migrated your Jira data, you will need to start the process for the keywords synchronization. It doesn’t start automatically, and depending upon your data footprint this can take many hours. We recommend starting it very close after the JCMA is done. It runs in the background so you can start it and forget it.</p> <p>There can be errors with the synchronization related to permissions so do check back to review any projects that could not be included in the synchronization.</p> <h4 class="wp-block-heading">5. Create ScriptRunner variables</h4> <p>Variables are not included in the data that is migrated automatically via the JCMA so you will need to re-create these in the cloud. For this migration we were able to create some well ahead of the migration as they were based upon standard fields. For others we had to wait until after the JCMA migrated data in order for custom fields related to migrating apps would automatically create them.</p> <h4 class="wp-block-heading">6. Fix migrated data</h4> <p>As mentioned in the previous section, you will need to go in and modify any migrated ScriptRunner configurations in order to either copy and paste converted script code OR upload script files (with converted script code).</p> <h4 class="wp-block-heading">7. Create ScriptRunner behaviours</h4> <p>At the time we did the migration, behaviours were not included in the app data migrated via the JCMA. In our case we had to recreate the ScriptRunner behaviours in the cloud that were defined on server. We had converted the associated scripts ahead of time (during preparation) so re-adding the behaviours was straightforward: create the behaviour with the same settings as server and upload the appropriate, converted script.</p> <h2 class="wp-block-heading">Final Word</h2> <p>Both Atlassian and Adaptavist continue to be committed to improving the migration process and over the past two years we have seen many good changes that have simplified and streamlined the server to cloud migration.</p> <h3-contact-form data-subject="To learn more about our Atlassian consulting services, stay in touch" class="wp-block-h3-block-h3-contact-form h3-contact-form"></h3-contact-form>