BigPicture is now on ! Enjoy enterprise-grade Program & Portfolio Management, now fully integrated with boards and workspaces.  Try it now
June 28, 2023

Getting ready to migrate Jira and PPM data to Cloud

Jira Portfolio-level Management Project Management
Jerzy Żurawiecki Content Specialist @BigPicture

Atlassian’s decision to end the support for Jira Server has huge consequences for its users. They have two destination options to transfer their data: Jira Cloud or Data Center. As cloud products are growing in popularity, Jira Cloud migration is the preferred solution for a large number of organizations.

But it’s not just about Jira data. Atlassian’s work management tool is often synchronized with other software. Project Portfolio Management is one of the most popular categories in the Atlassian Marketplace for a reason. After all, Jira Software isn’t equipped to view and aggregate data of programs and portfolios of initiatives.

Successful migration of PPM software is as crucial as transferring the contents of a Jira instance. Project Portfolio tools contain data that has strategic importance to an organization. And the way that information is structured is just as important.

If you use Jira Server and a PPM tool, you need to be ready to migrate before it’s too late. But don’t worry, this article will walk you through the preparation steps.

The post contains excerpts from our guide: “How to migrate your Jira PPM hub to Cloud stress- and hassle-free.” If you want to learn more about the migration of Project Portfolio and Jira data, download the guide here.

Jira Cloud Migration – time is running out

In October 2020, Atlassian announced that it would phase out the support of the Server model by early 2024. The company divided the changes into four phases, each separated by a year. That allowed the customers and vendors to prepare for the day when Atlassian would no longer support Server products. Below is a summary of the key dates and the associated events:

The last date has severe consequences for customers using Jira Server. Without technical support, businesses will be unable to solve any problems they might encounter while using the software. But the most critical aftermath of decommissioning Server products concerns the lack of security updates and bug fixes.

Without frequent security patches, Jira Server instances will be prone to data extraction by unauthorized entities. Data leaks threaten any business. But when the software’s creators abandon its safe upkeep, Jira admins and data security teams will fight an uphill battle to protect valuable information against hackers.

The importance of Project Portfolio Management Data

In the context of PPM, users have a lot to lose when their data gets leaked. Aside from employees’ personal information, Project Portfolio Management software contains data that outlines the future of the business: initiatives, programs, and portfolios, which are the results of strategic planning.

Some businesses use Jira to manage the creation and development of patented technology. Suppose the specifics of such sensitive materials got into the hands of competitors. In that case, the business in question could lose its competitive advantage, which would be reflected in the share price on the stock market. Based on these dire consequences, users might be highly motivated to move away from Server before the 2024 end-of-support comes into effect.

Getting ready to migrate Jira and PPM data can be a lengthy process, especially for large organizations. According to Atlassian, it can take “9 months or longer”, so it’s crucial to get the process started quickly.

Let’s make sure you have all your bases covered before transferring crucial data between Server and Cloud instances. One of the things that facilitate the transition is a decluttered instance. That’s what the next chapter is all about.

Pre-migration stack review

Most Jira users expand the software’s capabilities by adding third-party or Atlassian-built apps from the Atlassian Marketplace. While adding new software might be a regular occurrence in an organization, the review of the stack happens much less frequently.

Here are the main reasons for this state of affairs:

  • Jira admins are too busy with other tasks to spend large amounts of time on stack verification.
  • Larger entities employ hundreds, if not thousands of employees. Finding out who uses each app can be an enormous organizational challenge and a drain on resources in the short term.
  • There is no organizational incentive to review the stack of applications regularly. Especially when the upkeep of apps is not a large financial burden.

Reasons to review the stack

The transition from one hosting model to another is a great opportunity to review the organization’s stack of applications. Data from all the connected apps will have to be migrated, so trimming the unused software first will save a lot of time and effort in the actual migration process. Stack reduction can also improve the performance of the instance. The fewer apps and data to handle, the faster software will work.

The inherent differences between Jira Server and Cloud play an important role in the migration in terms of supporting applications. For instance, self-hosting users might encounter technical issues or blockers that do not exist in Cloud and vice versa. Functionality-wise, different hosting versions of the same app may offer varying features. Some vendors may have focused on Server versions instead of offering feature parity.

During the stack review, step one is compiling a list of all the software added to Jira. Once your list is ready, it will serve as a starting point for evaluation. Then, it’s time to divide the apps into two categories:

  • The ones that will be included in the Cloud instance,
  • The ones that will no longer be a part of the stack after the transition.

Stack verification quiz

Take a short quiz to determine the usefulness of each app in your Jira stack and whether it will be included in the Cloud instance moving forward.

Aside from classifying currently installed software, the quiz should help you locate areas where the stack lacks functionality. In some cases, you might need to find suitable replacements for discarded apps.

How to prepare for the migration of Jira and Project Portfolio data?

Thorough preparation is key to a successful migration. There is plenty to look out for, document, and understand. Don’t worry, we have broken down the preparation process so you can follow it step by step and get ready to migrate your PPM software to Cloud.

Assess the configuration of the source instance

The first step is to document all the elements of the source app configuration. Creating a complete list of the configuration scope takes some time, but it is invaluable for a number of reasons. Firstly, it helps select all the configuration components to be transferred to Cloud. Secondly, it will serve as a reference point once the migration is complete.

To make the assessment easier, Appfire has created a worksheet covering all the configuration categories from projects to epics, roles, workflows, statuses, security schemes, permissions, users, and a lot more. Download the Jira Migration Configuration Assessment worksheet here. The worksheet was originally featured in Appfire’s Ultimate Guide to Jira Migrations – an exhaustive source of knowledge for all Jira migration-related topics.

Back up PPM and Jira data on a staging instance

Once the configuration scope is selected, it’s time to secure the data of the Server instance. Back up the database, the file system, and the attachment directory. While the two tools are synchronized during everyday use, the backup process must be performed separately. Here are the steps you need to follow to back up Jira and BigPicture data in a safe environment:

  1. Create the BigPicture backup.
  2. Create the Jira backup.
  3. Restore the Jira backup on a staging environment.
  4. Install BigPicture on a staging environment.
  5. Restore BigPicture backup on a staging environment.

Clean up duplicates and redundancies

Just like apps, not all project and portfolio data from Server should find its way to the target instance. The pre-migration spring cleaning improves the performance of the software since there is less data to process.

The exact elements that could be duplicated vary with each Jira instance and use case. But, in the case of redundancies, one common denominator is the lack of use among users. Verifying whether a given project type or configuration is used in a large organization might seem like a hassle.

However, there are apps that streamline this process. For instance, Power Admin for Jira points out unused custom settings, such as screens, workflows, or custom fields, among others.

In fact, you can also consider removing or archiving entire projects, programs, or portfolios. In organizations that have used a PPM tool for an extended period of time, there might be countless initiatives that have been closed and accounted for years ago. Their transfer to Jira Cloud makes very little sense.

Run health and performance tests

The last step before migration aims to determine whether the source instance has no errors. It is crucial to verify that the settings, database, index, and file system are healthy and ready to migrate.

There are multiple ways of analyzing the health of the source application:

  1. Jira’s built-in Instance Health feature.
  2. Jira’s built-in Integrity Checker.
  3. Appfire’s Integrity Check for Jira.

As for performance testing, the app must have enough processing power to export large amounts of data. Jira Admins have multiple testing tools at their disposal. Atlassian recommends Gatling, but other options are also available. The list of the most popular tools can be found here.

Jira PPM data pre-migration checklist

To support your preparation for the upcoming migration, we have prepared a handy checklist that covers all the relevant steps. Once all the checks are finished, it’s time to migrate your PPM command center to Cloud.

Preparation is key. It’s vital to assess the Server instance, back up data, remove any duplicates or redundancies within the app, and run health and performance tests prior to migrating any Jira app to Cloud.

Hopefully, the article will help you get ready for Jira data migration better. But that’s not the end of the road. Picking the appropriate moment to migrate the Server instance without interrupting operational continuity, using the right migration tool, and post-migration checks – all of that matters significantly.

Our guide covers all these aspects. But most importantly, it contains a step-by-step guide to migrating BigPicture using Atlassian’s Jira Cloud Migration Assistant.