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; } } }

What would happen if we import a project from older JIRA (tied to SVN) to a later version of JIRA that's tied to a later version of SVN?

Melissa B.

Here's the thing..

We originally had planned to upgrade our current 4.3 version of JIRA to the latest version of JIRA but our lead decided that we should just stand up the new version of JIRA (it's on Linux) rather than do an upgrade.

So, now we have our latest version of JIRA tied to a later version of SVN but we also are using our current 4.3 JIRA that's integrated with an older version of SVN. The lead now wants to try and import one of the projects in our current JIRA to the new JIRA. What happens to the code that's tied to the older JIRA issues in 4.3 when it's imported in to a new instance of JIRA that's already integrated with a new SVN?

Does the code have to be re-checked in to the new SVN once we import the project over to the new JIRA? We have a lot of JIRA issues in our older (4.3) version of JIRA and it seems like things would really get messed up having 2 instances of JIRA and SVN and trying to import from JIRA/SVN (old) to JIRA/SVN (new).

I'm not overly technical here so all input is appreciated on how to proceed forward.

Thanks very much for any help/guidance you can provide.

Melissa

Accepted answers

Adam Saint-Prix

As long as your issue keys are the same in the new version of JIRA and you configure the SVN integration to point to the same code base (with the related commit messages referencing JIRA keys) it should work fine.

Having said that the only way to find out for sure I'm afraid is to test it and see what happens.

Where it won't work is if you decide to change the issue key in JIRA. I can't think of a reason why it wouldn't work otherwise.

Regarding the import: one option to consider would be to copy the 4.3 data and use it to populate the 5.1.x version (latest version) with content. You'll basically be upgrading the 4.3 data, but in a completely separate instance. Why?

Importing a single project has a number of prerequisites (the project metadata - custom fields, workflows, screens, permissions, notifications, etc. have to already exist in the target instance for the import to be successful. This is to preserve data integrity, but can also mean a bit of effort.

A work around given your particular scenario is to upgrade your data (again, in a separate instance so you have the existing 4.3 data and an upgraded version in a 5.1.x instance).

At that point, it's just a matter of deleting projects, schemes, etc. you don't need. It depends on the size of your existing data set. Sometimes it's easier to import everything and then delete what you don't need rather than recreate metadata (schemes, custom fields, etc.) manually.

Hopefully that helps.

All comments

Adam Saint-Prix

Having said that the only way to find out for sure I'm afraid is to test it and see what happens.

Where it won't work is if you decide to change the issue key in JIRA. I can't think of a reason why it wouldn't work otherwise.

A work around given your particular scenario is to upgrade your data (again, in a separate instance so you have the existing 4.3 data and an upgraded version in a 5.1.x instance).

Hopefully that helps.

foiwrqoinx

Melissa B.

Hi Adam,

Sorry I didn't get back to you sooner.

Regarding your comment that the issue keys need to be the same when importing a project from one instance of JIRA to our new instance of JIRA, I had already created a shorter issue key nomenclature in our new JIRA because what we have currently is too long in our older JIRA so I guess this means I'll need to delete the project key and recreate it? will this require me having to delete the project all together?

Also, I wasn't sure by what you meant about pointing to the same code base in SVN? If our current JIRA is tied to an older SVN and our new JIRA is tied to our newer SVN then wouldn't that mean that it's a different code base?

Also, I've not yet figured out how to apply the same workflow in our new JIRA that we have in our current JIRA so you're saying that also has to exisst before importing to the new JIRA correct?

Please bear with me as as no one on my team is all that knowledgeable about JIRA so we're kind of stumbling through trying to figure out what the next steps should be.

Thanks Adam.

Adam Saint-Prix

Hi Melissa,

You will need to either update the commits so that they reference the correct project key or delete the project and recreate the key. The SVN integration relies on issue key being inked to a commit. It won't show up if the keys have changed from what is in the commit.

Regarding my comment about same codebase, so long as the committed code references the proper issue key you should be fine. Are you planning to deprecate the old version of that particular project in the old 4.x JIRA? There shouldn't be any issues with having the integration in two places so long as the issue key is unchanged.

Also, I've not yet figured out how to apply the same workflow in our new JIRA that we have in our current JIRA so you're saying that also has to exisst before importing to the new JIRA correct?

That's correct. And the same applies to the project custom fields, permission schemes, notification schemes, etc.

Our new workflow sharing plugin lets you migrate workflows, screens, custom fields and plugins required for a workflow, but I don't think it is compatible with the earlier version of JIRA you are running.

I'd suggest either the project import route which is documented here: https://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup

or upgrading your 4.3 data to 5.x and cleaning up projects, schemes, etc. that you don't need. You can still keep the old environment running, but you will need to update JIRA's configuration settings in the new environment to avoid any conflicts since you are replicating an existing instance (base url, mail handlers, other config elements).

The alternative is to start with a clean 5.1 instance and duplicate the project meta data for the one project you want to import and then import the project from backup as described in the linked doc above.

The project import option is cleaner and guarantees data integrity, but can be time consuming depending on the complexity of the project setup.

Melissa B.

Hi again,

Thanks Adam for the clarification. Right now there are some screen schemes and workflows that were customized for the current JIRA but this was all done before most of us were here so this is going to be extra challenging since I've never done anything like this before and I'm probably the most experienced JIRA user on the team and that's as a power user (not a JIRA Admin/Techie Guru). Oh boy.

For the new JIRA, I created some new custom fields to match what we had in our current JIRA (plus some additional ones that I thought were needed that were not in our current JIRA). I've also created some additional statuses which I guess means figuring out how to customize the workflow in order to incorporate the additional statuses (or transition states). So I'll have to collaborate with my colleague here and see what new trouble I can get in to.

By the way, we are using a clean instance of 5.1 and not planning on doing an upgrade so for a while we'll be using our older JIRA for our other projects but the new JIRA for our latest project and then at some point down the road look at importing the other projects in to our new JIRA instance. Note: We will only for now be looking at importing the 1 project from current (4.3) JIRA to 5.1.

Thanks Adam for any/all advice you've provided so far.

Welcome!

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

Quick Links

Find more posts tagged with

jira

import

svn