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 Jira On Premise to Cloud

Colathur Vijayan_n47qq3

We have a On Premise JIRA System (v6.3.4a#6332-sha1:6293236), which has about 80000 issues, spread across 150 projects. These need be moved to JIRA Cloud which has other projects. These are my questions.

1. It is not clear from this link

if that methodology supports the On Premise version I have referenced. Please confirm.

2. From what I have seen the approach mentioned in the link above, expects JIRA Cloud to be clean. In other words for the use case I have mentioned, it would essentially wipe out our existing JIRA projects. Please confirm.

Accepted answers

Nic Brough -Adaptavist-

1. No, as it says in the doc, you must be on a very recent version of Jira. 6.3 is absolutely way too low a version, you will need to upgrade it to 6.4, then 7.0, then 7.13, and then 8.3 (8.0 may work, but I'd still recommend 8.3)

2. Correct, the import is "everything", so it will destroy what you have already. If you wish to merge, you will need to stop using the Cloud system, get a backup, download and import it into an 8.3, merge the other data in, then re-backup and upload the merged data

All comments

Nic Brough -Adaptavist-

Colathur Vijayan_n47qq3

Hi -

Thanks for a prompt reply. Couple of follow up questions.

1. What do these upgrade entail in general ? Are they simply "Click and Wait" type of seamless upgrades or do we need to perform upgrade activities (for example running upgrade scripts, redo our customizations etc.,) ? Downtimes ?

2. Can you suggest any approaches other than the upgrade ? For example would you suggest an approach where in we use the Jira Rest APIs, to get JIRAs from ON PREMISE Source System and create these on the CLOUD Target, programatically ? Any gotchas or limitations we need to worry about in this approach ?

Nic Brough -Adaptavist-

Downtimes for upgrades are complete - the systems will be offline while you upgrade.

In theory, they are "click and wait" - you point the new installer at an old Jira system and it runs through all the upgrades.

In real life, unless that Jira is quite simple, you're likely to have some problems, but nothing massive. Apps (especially ones that are very new and untested) can fail in interesting ways. You may have to patch up data or move things around to get an upgrade through. This has come a long way since Jira started - we used to have to do massive scripts and data amendments, but I have managed to do 7.0 to 7.13 with nothing more than "run installer and put some customisations back in place"

I can't give you approaches other than upgrade without losing data. Although, yes, you could use REST to poke issues in (or even import CSV), this will lose history, some comment history, possibly user data and and and...

Colathur Vijayan_n47qq3

Thanks a lot. Could please amplify on "I can't give you approaches other than upgrade without losing data." I did not understand that part. Are you essentially saying that the recommended approach for our use case, is to upgrade ON PREMISE Jira first and then use your migration methodology ? Please clarify one last time.

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-service-desk

cloud-migration