Hi, I am currently running Jira 4.1 -- moving to 5.04 on other hardware -- we have a large instance, and I want to minimize downtime once we flip the switch. I plan to develop the new jira in parallel with production -- we have too many customizations to warrant an in-place upgrade. I have the following rough plan in place -- does it seem reasnable/feasible? The reason I want to go with some sort of delta, as opposed to testing in development, and then doing a full data import on the night-of, is that I have tested that scenario already, and it takes about 4 hours. We have a huge instance with jira, crowd, and confluence.. I'd rather spend some time doing the bulk of the activity during a pre-flight window, and just import a delta for jira.
So -- the plan:
1. Preflight -- lock out all admins except myself in old jira, and do a full-xml dump. Keep admin lock in place until upgrade is complete -- to keep new projects, workflows, custom fields frozen until upgrade is done. Any new issues will be moved over as a delta.
2. import xml backup into new jira, copy attachments to new hardware location.
3. Test, etc.
4. Once ready for night of switch-over, make jira read-only, do a query to see which issues had been committed since full xml dump, and export those issues as csv, or xml, or something.
5. Import those issues to new jira instance -- whether by soap, jira cli, jelly script, etc.
I also have a few constraints for the new issues:
1. The issues need to maintain issue id numbers, comments, components -- basically everything.
2. Subtasks need to be moved over
3. attachments copied over.
So -- my main question is about step #5 -- what is the best approach for moving/recreating the issues between jira instances -- especially instances that have different versions? Seems to me that remote issue copy is not a possibility. I was thinking about exporting issues from Jira 4.1 as xml, and parsing them via a script, then do a csv import into Jira 5.04
Any best practices, advice, gotchas? I honeslty don't know whether to go with jira CLI, some soap API, the built-in csv import, etc. what I would like is to just download issue xmls, and upload same xmls into new jira -- but I understand that doesn't really work.
Thanks for any tips/assistance!
Community moderators have prevented the ability to post new answers.
When you export into .csv files you will loose important information like the change history or links. And even if you had that i can't see a way how to import that using one of the tools above. Likely this will require coding. I think you really should try to get the inplace upgrade running. Can you give some details why your customized version does not properly run the inplace upgrade?
As a follow up to Andy's note, there's a heap of information in this document on how to log in to a JIRA instance in scenarios similar to what you've described above:
https://confluence.atlassian.com/display/JIRA/Retrieving+the+JIRA+Administrator
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi wwells --
I don't know if this will help you, but this is what I did to get my old jira moved to new jira (including crowd).
1. In original crowd -- for crowd console application -- add remote ip of box it is moving too. Then, export xml.
2. Install new crowd on new hardware, and upload xml backup
3. In old jira - add a new crowd directory for new crowd location. Then xml backup
4. Install new jira in new location, use xml backup
5. If you still can't get into new jira --- shut it down, and copy over the osuser.xml and crowd.properties files from original jira, and put them in their respective directories in new jira -- tweak to look at new crowd.
6. Reboot Jira -- it *should* authenticate with crowd..
I might be missing some steps (still waking up) -- but I remember hashing around variations of the above, and I was able to get in. :)
I just wish there was a way to do partial imports/updates -- I mean, I know there are ways, custom coding, etc -- but I mean sanctioned built-in Atlassian ways! :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Bryan,
I'm pretty much in the same state as you. I am upgrading a system from JIRA 4.1.2 to 5.0.2 and I've been running into quite a few problems. We have a Crowd integration with all of our tools. I've tried to setup a new instance like you did and then import using the Restore from XML. The problem is that the original systems configurations are imported as well, locking me out of my JIRA instance. I've tried setting up a new admin account both from the system and within MySQL but neither have worked. I tried removing the integration portions, but that didn't work as well. Then I tried configuring the new instance to work with the old Crowd, but once again that didn't work. It seems that the newer JIRA is not compatible with my older Crowd.
We are currently working on another plan to see if we can't just backup our newer JIRA instance, take the production backup xml entityengine.xml data contents and copy/paste them into the newer JIRA xml and do a restore like that. Initial testing has been successful so far. At the same time we're setting up a newer Crowd instance to see if we can't get it working that way as well. Like you, we have a very large system and any way to do this without a lot of down time is preferable.
We chose to do it the same way as you because we also have to get certain projects off of our current network and move it to another JIRA instance on a separate private network. Add SSL and a PKI authentication to the mix and you can see the sort of fun we're having. If we have any further success I'll be sure to update you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I would steer away from CSV also, just last week I did a 3.13.5 to 5.03, heh, in that case, I was just after getting the data into a 5.0.3 compatible form for a simple input, in this case, migrating the issue away from complex workflows and issue type schemes, for the defaults, prior to loading into a standard 5.0.3...
Depending on what your customisations are, echoing Dieters comments, irrespective of template /other customisations, it should be perfectly possible to do an in place upgrade, in a temp server to build up the data. I admit though, its a PITA to roll through the versions, remembering the DB config tweaks and so on?
If time is really your enemy, consider setting up an interim JIRA, and migrate one project at a time?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
"If time is really your enemy, consider setting up an interim JIRA, and migrate one project at a time?"
I tried that and there was a problem associated with all of the customizations that had been done in our production system. When importing a project, any Issue Types, Custom Fields, etc.. that are being imported have to exist in the new instance. This includes both global and non-global customizations.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you are trying to retain your customizations, just do a full restore and delete projects that you dont want to migrate. All non-template customizations would be available for further project migrations as/when you can arrange.
If however you want to remove some of those customizations, eg setting default schemes, you can do that in a test restore, delete other unwanted projects (and perhaps custom fields), then do another backup. This backup, will, on use for single project restore, present less of a challenge to import?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Unfortunately, a full restore also retains all of the system configurations. So when I'm trying to restore from a much older version (4.1.2) to say (5.0.2) it doesn't allow me to login once the full import is completed. Your second part is what I've been trying to do for some time now, but without being able to login after the restore I'm stuck. However, what I've been doing is installing 5.0.2 on a test system and just doing an import of the 4.1.2 backup xml. Not sure if I should actually install 4.1.2 on the test system, try an import of the production 4.1.2 data, and if able to login, then perform an in place upgrade.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you have ldap auth, you just need to grab a copy of the osuser.xml file IIRC? Alternatively, create a known unique user within the initial 'full' restore, granted with admin privilege, that will exist in the _internal_ jira database, and therefore will survive after restore, even if your external auth is broken...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Community moderators have prevented the ability to post new answers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.