Upgrading Jira 5.2 to 6.4 in a new environment

[Dan Landerman]

Greetings,

I'm fairly new to supporting JIRA and have been asked to upgrade our existing 5.2 systems to the latest version on new servers. I have reviewed the various documented upgrade methods and I'm still not entirely sure which approach best suits our situation.

The current 5.2 prod environment is running on a Windows 2008 (32bit) with the database on Oracle 11g (RAC). We'd like to set up the web tier on new 2012 R2 servers with a 12c backend if possible. As far as I can tell, the business owners are not necessarily concerned with preserving any JIRA settings or config that are outside of the database but definitely need their existing data intact. More or less they want a clean installation with all of their data. Since this is being set up on all new servers there is no risk to existing prod or test environments during the upgrade.

My questions are:

1) Which upgrade methodology sounds correct for this scenario?

2) What, if anything, do I need to have copied over from the old (current prod) web servers to the new ones in this case?

3) At what point in the suggested upgrade approach will I need a copy of the old (current prod) database? and

4) When is the database itself upgraded as part of the process? What changes are being made there?

To me, looking at the 'Upgrade with a Failback' sort of looks like the approach I want but it seems to me that all I need to do is install JIRA and point the new installation to the old database. I'm not sure that sounds right to me.

Any help would be so greatly appreciated, thanks in advance!

[Nic Brough -Adaptavist- · Accepted solution]

To start with, break this down into two parts.  Moving servers and upgrading JIRA.  Work through them both separately, and if you're confident, you can plan to merge the plans

https://confluence.atlassian.com/display/JIRA/Migrating+JIRA+to+Another+Server

https://confluence.atlassian.com/display/JIRA/Upgrading+JIRA

[Dan Landerman]

Thanks Nic. I had reviewed both of the documents previously and I was really looking for some more guidance here. It kind of sounds like you are suggesting maybe two installations of the 6.4 software on the new servers? One is the clean install and the other is the an installation run against the backup of the current prod such that it upgrades the database. I can then point the clean install at the upgraded data. Is this correct? I apologize if I'm not understanding or making this more complicated than it needs to be. Thanks for your help.

[Nic Brough -Adaptavist-]

Not quite, but you're close. The reason I think of it as a two-parter is to keep it simple, and provide breaks. A move and upgrade is potentially quite a long task and if it breaks you're into rolling all the way back. If you do one part first, then if the second one breaks, yo can roll back to the end of the first instead of having to redo the whole lot. But, doing them at the same time does have advantages. Because you have a new server to work with, you can do a lot of preparation and have a simple migration route with easy rollbacks. I would: - Set up the new server with 5.2 on it and test that I can migrate a copy of production on to the new server. - Install 6.4 on the new server and test that I can upgrade the copy of production to it (I'd be strongly tempted to actually clone the 5.2 and upgrade the clone as per docs, to prove that I can create an upgraded system without touching the original - Once fully tested, you then scrub the installs off (or move them so you can keep them for reference later) and prepare the server for live Once I've got those tested and I'm comfortable with them, your "go live" plan becomes - Shut down current production - Copy it over to new machine - Upgrade it - Sanity test - Point network entries etc to new machine If that fails, your rollback is a doddle - Point network entries back to old server and restart the old system