Case study | Migrating ScriptRunner to Jira Cloud

Work management

Cloud

Server

Migrations from Jira Server to Cloud are a hot topic within the Atlassian community. In this case study, non-profit focused marketing agency Firespring share their journey to Cloud.

Migrations from Jira Server to Jira Cloud are a hot topic right now within the Atlassian community, so we were delighted when Chad Scribner and Carmen Knudson from nonprofit focused marketing agency, Firespring, agreed to share with us their journey to Cloud. We take a look at the planning process, the challenges they encountered, and the calm on the other side.

"Adaptavist just laid it out. It was refreshing because you don’t always see that. They did a really good job of describing the difference between Cloud and Server."

Chad Scribner, Vice President of Engineering, Firespring

Firespring, based in Lincoln, Nebraska, provides strategic guidance activated through creative, marketing, printing and technology solutions to help businesses and nonprofits prosper. The growing team has been regularly recognised for excellence in their mission, including by Forbes as one of their 25 Small Giants in 2020. Whilst Firespring offers a huge range of services to help organisations promote themselves and deliver on their mission statements, over 3000 of their clients rely on their customisable Nonprofit Website Builder; a website product with a robust content management system (CMS) catering specifically for the needs of nonprofits. The system features online fundraising, event management tools and portals that allow customers to manage and order physical collateral.

It is this system that Firespring’s Jira instance centres around. The project management of the product — the development of new features, modules and other core product changes — is all done through Jira. The team behind Firespring’s Nonprofit Website Builder is made up of two technical mentors leading independent but collaborative dev teams. These teams use Jira in conjunction with Firespring’s QA Engineer and Project Manager to create an instance of around 30 users in a scrum-of-scrums model. Prior to the move, they had been on Jira Server for a whopping 10 years.

"Think about workflows and the way you do business, as opposed to testing individual pieces of functionality."

Chad Schribner, Vice President of Engineering, Firespring

Why the move to Cloud?

The initial decision to move to Cloud was driven by a desire to simplify maintenance. Firespring’s ethos is one of creating accelerated change for long term efficiency and performance and they carry this through to their product and project management.

‘We felt like the upgrade process of Jira Server was not the best,’ says Chad, Vice President of Engineering. ‘It requires an outage so I was doing it on evenings and weekends. There were a lot of times where it would break add-ons and it wasn’t completely clear why. That manual update was time for us, it was error-prone and it required an outage. The Cloud allows us to get rid of those outages for the most part.’

Before confirming their decision to move, the Firespring team carefully worked through some pricing models to compare the cost, looking holistically at everything from hosting and their product mix to their growing user base to get a true comparison.

Swapping Cloud caution for Cloud confidence

Cloud technology is transforming the way we work for the better. Also part of The Adaptavist Group, our colleagues at Adaptavist take a look at some of the biggest benefits for businesses making the move online here.

Read the blog

What advice would Firespring give to others about to migrate?

Regardless of your Jira instance size or complexity, there are some universal rules that apply when it comes to migration. The first? You don’t know what you don’t know, so give yourself sufficient time for discovery and testing. The second: not everything has to come with you; think about the organisational goals first, not the tech.

‘We spread the migration out over a few months and I think that was a good thing,’ says Chad. ‘You don’t necessarily know what problems you’re looking for or where the problems are going to happen. If you can, have a good amount of time and have a lot of eyes looking at it. Think about workflows and the way you do business, as opposed to testing individual pieces of functionality.’

What about migrating add-ons?

As part of the process, Carmen and Chad took a look at each of the add-ons installed on their 10-year-old Server instance to determine which apps were still in use, whether they had Cloud versions, and deciding which ones were indispensable.

‘ScriptRunner was one that was critical,’ they say. ‘We needed to have it and we thought that it would be very costly to not keep it.’

To anybody approaching a migration which includes apps, the Firespring team recommends diving into documentation early in the process. Some of the add-ons which did not make the cut for their migration were those whose documentation did not offer the necessary insights for simplifying the process. ‘The ScriptRunner documentation is very honest about the difference,’ says Chad. ‘Adaptavist just laid it out. It was refreshing because you don’t always see that.’

‘Adaptavist did a really good job of describing the difference between Cloud and Server—that there are some things that are missing in the Cloud version, explaining why that is, so we knew what to look out for. That kind of stuff really helped with the transition.’

How does Firespring use ScriptRunner?

One of Firespring’s main functionality requirements within ScriptRunner is the subtaskOf JQL function, which allows you to retrieve the subtasks from a parent task. As the broad-ranging capabilities of ScriptRunner go, it’s a humble function, but one with powerful implications for Firespring.

‘One of the main things that we use it for is to keep track of things that need to be done during a deploy that map back to a specific issue. Maybe we need to clear a cache or run a database migration,’ elaborates Carmen, Software Team Lead for the Nonprofit Website Builder. ‘So when that story is being worked, we add a subtask that basically says what needs to be done and then when we do a deploy, we run one of the ScriptRunner filters to get a list of all the tasks that need to be done as part of the deploy.’

‘That’s a really important one for us,’ agrees Chad. ‘We used to rely a lot on memory, or on the developer who made a change to do the communication, and when it would slip through the cracks then we would have deployment problems that would result in the phones lighting up or an outage. With ScriptRunner we can automate that; we can pull in a list of subtasks at deploy time so we don’t have those bugs that make it to live.’

The process of migrating from the Server version of ScriptRunner for Jira to the Cloud version presented unique challenges of its own, which Carmen candidly shared with us: ‘For me, one of the hurdles was my misunderstanding of the differences between Server and Cloud, the separate ScriptRunner interface and how those filters worked,’ she says. ‘It took me a while to understand that they sync to the other filters, that they were actually creating filters in the other area. But after those pieces got connected in my mind, it made a lot more sense.’

Migration documentation

After looking to the documentation to achieve clarity on the differences, Carmen and the Firespring team were able to easily replicate the automation that they needed in Cloud to ensure that their smooth deployments would continue.

View documentation

How long did the process take?

Overall, the team completed the entire migration process in three months, from planning to success. ‘Three months of testing and prep and a couple of hours of actual migration,’ laughs Chad. ‘The longest downtime was the process to upload the database, but it didn’t take us too long.’

How are things, post-migration?

‘Very smooth,’ smiles Carmen. User acceptance of Jira Cloud has been very high within Firespring, and Chad has also noted performance improvements compared to their former instance.

‘Sometimes we would have performance problems with the Server version of Jira, but I feel like we haven’t had those issues with Cloud so that’s been a positive,’ he says. ‘There are some things that look and flow a little bit differently but I haven’t heard any complaints or anybody asking can we move back!’

If you’re a nonprofit in need of a customisable CMS for your operations, check out Firespring’s Nonprofit Website Builder: we have it on great authority that their dev and release cycle is smooth and beautifully managed!

Get stuck into a trial like Chad

Use this free 30-day trial of ScriptRunner for Jira Cloud to explore the differences.

Try it free