I've tried to do an in-place upgrade from 4.1 to 5.1.
- I install 5.1 in a separate folder
- I copy 4.1.1 folder to 4.1C
- I copy jiradb_4.1.1 DB to a DB named jiradb_5.1
- I use config.bat in 5.1 to point at 4.1C
- I use config.bat in 5.1 to point at jiradb_5.1
When I start JIRA 5.1 it appears to upgrade the jiradb_5.1 database.
I am then met with Step 2 of 4 JIRA setup page. This is not what I expected. If I proceed with the wizard, then the jiradb_5.1 is emptied out and it looks like a fresh installation.
I've read a lot, certainly not all (there is so much to read...) but can't find any clues about this. Can someone please advise me what I'm doing wrong? Thank you
For JIRA 4.1.2 to be upgraded to the JIRA 5.x, you need to follow the steps outline in the Upgrading JIRA Manually. However, please be extra careful with the configuration files like osuser.xml that you need to copy over to JIRA 5.x before the upgrading start.
Generally the steps are like below:
I would strongly advice to perform the upgrading in staging environment first. It's safer and it will reduce the risk of fatal problem.
So I'm using 4.1.1 and not 4.1.2. I don't know if that makes a difference here.
As nearly as I can tell, my steps match your steps except that I point to a copy of the jira DB instead of the original. It makes me nervous to point to the original DB, as obviously it is a live and not staged DB. Is there a problem with this variation?
We have next to no customization. We have the SVN plugin and the Greenhopper plugin, but we are going to leave Greenhopper behind and plan to configure the SVN plugin over again from scratch. Should this be OK?
So from my perspective, I have basically followed the recommended steps you have given me. Could you give me some more clues?
EDIT: The non-DB portion of this I am performing on a snapshot VM, making it very similar to a staging environment. I've already had to roll it back once
There should not be any much difference with upgrading JIRA 4.1.1 or JIRA 4.1.2 to JIRA 5.x.
Pointing the JIRA 5.x to the database copy of JIRA 4.1.1 is also correct ;) Reviewing the steps that you had, I am not very sure if you have the JIRA 5.x pointing to copy of the JIRA 4.1.1's Home Directory . You might want to check this.
By the way, is there any error in the logs during the upgrade process ? If the steps are correct, it might have encountered some problem that cause the upgrade process incomplete.
I use to config.bat file to change the directory from the native 5.1 to the copy of the 4.1.1 directory. Is this the correct way to point at the JIRA 4.1.1 home directory?
Checking the log, there is an error which I can only presume suggests a malformed XML somewhere or another, but I can't tell which XML it's complaining about. It won't fit in the comment so I am updating the OP with it
This appears near the very end of the logfile upon startup, but this may be due to me trying (unsuccessfully) to import the old site's XML config/export file. Let me retry cleanly and look at the logs
There are differences between 4.1.2 to 5.1 with the configuration files. For instance, I do believe that the osuser.xml file is no longer present or needed in the newer version because those instructions were placed in the seraph.xml. However, when upgrading at intervals you need to understand where those types of changes were made. That's why you have to at least read through each of the enhancement level documents (4.1, 4.2, 4.3, 4.4, etc...) to understand where those changes were made. If you are integrating any of the other Atlassian tools you will need to understand the compatibilities between each version as well. For instance, Crowd 2.0.7 will no longer work with JIRA if you upgrade that to 5.1. Understanding your sequence of upgrades is necessary to ensure that you don't run into problems along the way. (i.e., upgrade Crowd first because it can be backward compatible with the older versions of the other tools). From within the Upgrade documentation it states that if you're using Confluence, and you upgrade to JIRA 4.3, you have to have Confluence upgraded to at 3.5 at the very least BEFORE completing the JIRA upgrade.
As someone stated earlier, it is highly advisable to perform a test upgrade in a staging environment to ensure that you are not messing up your production environment. This isn't always an easy process though, but I still recommend it. It was a good idea that you had created a separate database with your production system, but I would setup a separate VM altogether and point it to that new DB and modify your configuration files on that VM. You don't have to install the same version of JIRA initially on the new VM either. I installed Crowd 2.3.2 (even though our production system is still running at 2.0.7) and imported the data into a new DB and it just upgraded the data there when I brought it up.
Although contradicatory to my statement above about setting up the new DB, I'm curious why you did so when you are doing an in-place upgrade. The idea is that you install the new version of JIRA and update the data in the existing database. While you could import the xml backup, you shouldn't have to if you just point to the existing database. Correct me if I'm wrong, but you shouldn't have to create a new database or dump everytime you upgrade.
To test this, you could rename your current JIRA_HOME directory to something else and startup JIRA again. Then when you hit step 2, instead of doing an Import from XML, just setup your db settings to look at your existing database. (Note: You could manually setup the db settings in the /apache-tomcat/conf/Catalina/localhost/jira.xml file too.) On Windows I believe you can change this using the config.pl script (I think that's the name of it) Just some thoughts though.
One thing you might want to check as well is that your licenses have been updated. If you're trying to use your existing 4.1.2 licenses with the 5.1 it won't work. They did change the licensing scheme at 5.
Thanks you have provided a lot of useful information. In a sense I was just overwhelmed with the documentation, as we have next to no customizations - only greenhopper & the svnplugin - and we're dropping greenhopper.
I definitely wanted to setup a separate VM however on ESX 4.0 server it's not quite the easiest procedure to do that - although snapshotting is simple enough.
I technically didn't do a 'new' DB I cloned the 4.1.1 DB because I didn't trust the upgrade process would a) go smoothly and b) be a safe operation on live data. It turned out both a and b were true, so +1 for risk aversion as it clobbered a lot of data.
I will definitely keep my eyes open for the license format as well. I'm working with Atlassian directly now on this and quite honestly it's extremely frustrating the littany of steps and attempting to understand what the correct ones are. But I don't give up easily :)
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG