Upgrade 4.1.1 -> 5.1 not behaving as expected

[Malachi Burke]

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

[William Wells]

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.

[Malachi Burke]

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 :)

[Janet Albion]

Hi Malachi,

I would suggest to create support ticket for this so that the support tema and review the case much further. attach the entirety of the JIRA logs so that it can be review.

-Janet

[Janet Albion]

Hi Malachi,

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.

-Janet

[Malachi Burke]

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

[Malachi Burke]

After doing a clean restart, I see no errors in the log. Looks like that was a false positive from my ill fated attempt to import the XML settings from 4.1.1

[Malachi Burke]

Is there anything else we can try?

[Janet Albion]

Hi Malachi,

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:

1. backup JIRA 4.1.2 installation and home directory
2. backup the JIRA 4.1.2 database
3. install the JIRA 5.x
4. migrate or copy over the configuration files as listed in the section 3.2
5. point the new JIRA 5.x to the existing JIRA 4.1.2's home directory
6. connect JIRA 5.x to the JIRA 4.1.2's database
7. start JIRA 5.x
8. once upgrade is completed, ensure that every features works (especially user management) since there are a lot of changes between JIRA 4.1.2 and JIRA 5.1

I would strongly advice to perform the upgrading in staging environment first. It's safer and it will reduce the risk of fatal problem.

Good luck.

-Janet

[Malachi Burke]

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