nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Migrating 3k issues from JIRA 6 to JIRA 5.1.x

Kai Gottschalk

Hi *,

I've the challenge to import one JIRA project (~3k issues) from one JIRA (6.0) to another JIRA (5.1.x) at short-term. Updating the 5.1.-version is not a short-term option.

Afaik, the project-import from XML-backup seems to be not possible as of the missing downwards-compatibility of the exported data.

Our first approach was to have a CSV-export of all 3K issues, manual copying the attachments, modification of the csv (adding the attachments, see here). I am aware that this has a lot of prerequisites (users, customfields, resolutions, links, etc. have to be considered).

But then we realized that we cannot be the only/first ones, having this challenge and so I want to ask if there is no easier solution on simply getting only issues and attachments migrated from JIRA 6 to JIRA 5.

Acceptance criteria for receiving the karma-bounty:
Provide an easy technical solution which allows us to move 3K issues (incl. attachments) from JIRA 6 to JIRA 5.

Accepted answers

Nic Brough -Adaptavist-

Oooh, I don't think anyone is going to win that bounty.

Quite simply put, there's no "easy" solution to this. You're going to need to extract, manipulate and import data in quite a lot of detail, and it's intensive, hard, complex work.

Most people who ask to "downgrade" end up skipping it and upgrading, or living with two separate systems until they can do. It's usually just not worth the effort for anyone to do it.

My approach would be to extract the issue data you need from version 6 in XML - that will contain all the data you need (except the attachments) in a machine-readable format. You can then process that into a shape that can be used to upload it. Jelly is one option, and REST another. You will need to do the configuration in the target system first, so adding any missing custom fields, projects and schemes etc, and then amend the Jelly/REST to map things (e.g. customfield_10010 in the source needs to be customfield_10025 in the new)

Another approach might be to take a full backup of the 6.0 system, load it into a development 6.0 system, remove everything that you don't need from it, then export that as XML. Hack the XML so that it thinks it's a 5.1 export, then import into development 5.1, then export what you need and import into the tartet 5.1. Problem here - I don't know how big a job it is to downgrade the xml.

Or you could wedge things in with SQL. Last time I was asked to do that, I gave an estimate of 6 months (Jira 4.1 down to Jira 3.12. The estimate for upgrading 3.12 to 4.1 was one month)

All comments

Nic Brough -Adaptavist-

Oooh, I don't think anyone is going to win that bounty.

Quite simply put, there's no "easy" solution to this. You're going to need to extract, manipulate and import data in quite a lot of detail, and it's intensive, hard, complex work.

Or you could wedge things in with SQL. Last time I was asked to do that, I gave an estimate of 6 months (Jira 4.1 down to Jira 3.12. The estimate for upgrading 3.12 to 4.1 was one month)

I am not sure if this is going to work, and if it might casue other issues for you along the way on the target instance. You could try to set up a dummy 5.1.x instance, create an export on the JIRA 6 instance, use the information in this KB article to change the build number and try to import the data to the 5.1.x dummy instance. In case you are using plugin, try to turn off as many of them as possible. Once this has been completed, you can try to generate a new export on the dummy instance, and perform a project import on the 5.1.x target instance. Though you do not deem it to be an easy solution, using the csv import option with the additional work you have to put in, might prevent any incompatibility issues, while upgrading the target instance to JIRA 6 would by far be the best solution to reach the goal you are after. Down the line, I am afraid that there is no easy technical solution to your request.

In addition to both our comments, I wonder what the reason is behind wanting to import the project into a lower version of JIRA, especially if upgrading the target instance is not a short term solution. If you consider it to be a term solution, you might want to consider moving the upgrade forward. Depending on your requirements, you could also set up some application links between a JIRA6 instance containing the project and your current instance, and use an instance of crowd for user authentication to both of them. Then once you decide to upgrade the 5.1 instance, you could perform the merger at that time. Just spitballing here.

Nic Brough -Adaptavist-

Yup, nightmares all round. Except jumping from 5.1 to 6, that's by far the nicest thing to do here.

David Pinn

The easy solution here is to get somebody to do it for you. ;-) But seriously folks, you already know about the CSV import approach, so I'll add my two cents worth on two other approaches.

1. It is entirely possible to run large-scale migrations using Jelly. I've done moderately complex migrations of upwards of ten thousand issues, including attachments and inter-issue links. You can use XSLT to massage the XML export data into Jelly tags, which you can look at and validate before running the import stage. The advantage is that a lot of your development work can be done inside a tight feedback loop (run your XSLT, check the Jelly tags that were output, fix errors, rinse, repeat), and does not involve running and re-running the import into JIRA. The disadvantage is that Jelly isn't the most gorgeous language to work with. XML as a programming language? what were they thinking?!

2. If you have Java development skills, you might write an add-on for JIRA that reads the XML export data, and adds the issues to JIRA using JIRA's public Java API. You have the ultimate flexibility here, and all the power of a fully-fledged and well-documented API. This would be my preferred route, but your choice will depend on how comfortable you are with Java development and add-on development.

Kai Gottschalk

Hi Nic (as well as all commiters),

why I do not like the fact there is no easier way, than you suggested (although it was almost clear for me), I really liked:

- the style of your answer ("Oooh, I don't think anyone is going to win that bounty.")

- that you (and the other commiters) tried to explain the drawbacks of the different solutions.

Most likely we will indeed change our plans and upgrade the target instance to JIRA 6 first. Afterwards we'll have an XML-export of the source-JIRA, harmonize the userbase and, manipulate the XML (entity ID mapping) and import the project "back" into the target-JIRA.

I voted up your answer - so that this question will be marked as answered, to ensure your initial statement

Oooh, I don't think anyone is going to win that bounty.

will proven to be wrong :-)

Cheers
Kai

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

csv

jira

import

restore

backup

jelly

xml