Jira merge and beyond

Merging more than just the Jira base data: a how-to article on merging add-on data
16.07.2020
Tags

Have you ever wanted to merge two or more Jira instances? Have you ever wondered if you could merge add-on data as well?
We have been in this position a couple of times and know how to do it. Yes, we can merge add-on data - also for you!

Merge or Migrate?

Jira merge and beyond blog post

First of all, we must distinguish between two keywords:

  • Data Migration
  • Data Merge

Data migration is the process of selecting, preparing, extracting, and transforming data and permanently transferring it from one computer storage system to another. This means you transform the same data from one operating system or database to another, not adding, removing or updating the data. This can be done by many standard operations from Jira itself or the database or the operating system.

Data merge or Data integration involves combining data residing in different sources and providing users with a unified view of them. Two becomes one. Unfortunately, it is not as simple as said. But we have developed a way to merge the data as efficiently as possible.

We certainly can and will support you, also with data migrations - moving from or to Atlassian Cloud? or our managed hosting services? - but this article will focus on data merge and integration.

Many roads lead to ROME MERGE

Jira merge and beyond blog post

Before we can merge add-on data, we have to merge the Jira instances. There are a few add-ons in the Atlassian marketplace such as Configuration Manager or Project Configurator who can do that. With these add-ons you can transfer all configuration data such as issue types, workflows, custom fields, screens, permissions, etc. to your target system.

What are the preconditions before starting with the merge of the add-on data:

  • You need two Jira instances - in our example we will call it Jira A and Jira B. Target is merging Jira B into Jira A.
  • Jira A must contain the basic data of Jira A and Jira B (the basic data merge described above must be finished)
  • Jira A and Jira B must be accessible from one central point

Why can’t we just take the data from Jira B and add it to Jira A?

Because there are many references in the data pointing to objects in Jira B. Unfortunately, after merging the basic data, the objects in Jira A will get new identifiers. Example: Issue with KEY-123 on Jira B will have different IDs on both systems. If we simply add the data from Jira B to Jira A, the reference will point to a different object after the merge. The identifiers will not match and the system will be corrupted / will show wrong results.

Therefore, we have to translate or transform all references in the data from Jira B so that it matches the objects in Jira A. We usually use an ETL (extract, transform, load) tool for this purpose.

4 steps to success

  1. Collect basic data from Jira A and Jira B and create a transformation table
  2. Collect the add-on data from Jira B
  3. Transform the data of step 2 using the transformation table
  4. Insert the transformed data in Jira A

Step one and step two Jira merge blog post

Step 3 and step 4 Jira merge blog post

Ideally, we collect the basic data from both Jira’s directly from the database. Using the database will guarantee that we can collect all the data without having trouble regarding access or permissions. Technically it is also possible to collect the data using the REST endpoint of both Jira instances, but additional preparations regarding permissions and security levels are necessary, and on bigger instances, the process uses more time (and therefore requires a longer outage during the productive migration).

Proof of concept

We can confirm that this approach works and does the trick merge. We have already successfully merged massive Jira instances containing add-ons such as Zephyr for Jira Test Management from SmartBear and TM4J Test Management for Jira from SmartBear formerly Adaptavist. For both previously mentioned add-ons, we were able to merge the customers’ data in a short time with nearly zero lead time, and could reduce the outage to a very short time due to a nearly automated translation and migration process. The most consuming part of the merge process is acquiring the required access and permissions, testing and planning.

If you have another add-on with custom data to merge, we’d be happy to analyze the data structure and prepare a quote for you.


Cover image by Lance Grandahl from Unsplash