server migration to new version

[cloudistics]

I'm working on an upgrade for our suite (bitbucket, Jira, Confluence) And i'm wondering  whats the best way to proceed. Can i stand up the newest version of each and migrate the data from the old version on the old server, or should I stand up identical versions on new boxes and upgrade the new boxes afterwards?

[Dave Theodore [Coyote Creek Consulting] · Accepted solution]

Depends on which versions you are going from and to.  If your tools are fairly modern, you can probably go directly to the latest version. If they are pretty far back, you may need to do an interim upgrade to another old version, and then upgrade to the latest.  Read the upgrade notes for the product you plan to upgrade and you should find out what the upgrade path is.  Some 3rd party Apps also have specific upgrade procedures too, so it would be worth researching this for each App that you use, as well. Database versions can often have support removed for them, as well. Be sure to research the "supported platforms" (google search for this: "jira 7.12 supported platforms" for example) and make sure the database version you are running is supported.  If you're unlucky, you will need to upgrade your database too. This process varies, depending on which database technology you are using and how far back you are. It would be a good time to set up the Bitbucket Backup Client as well, if you haven't already. You need to use this to back up Bitbucket, and not just back up the home directory and DB.

As far as the process goes, I would recommend setting up a development instance that is an exact copy of your production instance.  Perform the upgrade there and identify a repeatable process that you can use during your production downtime. This also gives you the opportunity to measure the time it takes, so that you know how much down time to ask for. I would not recommend performing the upgrade on your production servers for the first time without testing.

I hope that helps!

[cloudistics]

thanks for the info. I'm going from

• confluence 6.1.2
• jira 7.9.0
• bitbucket 4.14.4
• postgres 9.3.16

i'll look up their guides.

Can the Jira XML backup be run while the server is up?

[Dave Theodore [Coyote Creek Consulting]]

You actually have to kick off the XML dump while the tool is live. It is one of most resource intensive things that the tool does, so I would recommend kicking it off under a change control. If the tool falls over while running the backup, you are covered. 

[cloudistics]

Can you clarify this step please?

3. Extract the file and upgrade Jira

1. ...
2. Edit the  <installation-directory>\atlassian-jira\WEB-INF\classes\jira-application.properties file to point to your existing Jira home directory. Make sure that you deleted the dbconfig.xml file, otherwise Jira will try to connect to your existing database.

What does it mean by my existing Jira home directory? is it referring to my actual original install? that's on another server. i'm standing a new one up.

[Dave Theodore [Coyote Creek Consulting]]

The Jira home directory is where Jira stores it's non-database data.  It's also where the database configuration is.  You can look at your existing jira-application.properties file to see which directory is used. Also, be sure to check your setenv.sh file and server.xml, which are located in the Jira installation directory. One of both may have been modified, so you will want to make the same modifications to the files on the new version.  If you log in to the UI admin interface and look at "System Info," there is a section called "Modified files." It will show you all files that were modified, so you can check each one to make sure you don't miss a configuration setting that you have now.

[cloudistics]

so am i not supposed to copy the whole folder into the new install?

[Dave Theodore [Coyote Creek Consulting]]

No. Don't copy it at all (except for maybe making a backup copy somewhere.) When you edit the jira-application.properties file and paste in the directory location, Jira will look there when it starts up.  When it sees the existing data and configuration files, it will use them.  It will connect to the database and see that the database is not the same version as it is, then upgrade the schema.  It would be a good idea to back the database up before doing the upgrade, in case you need to revert.  

[cloudistics]

thats the part i don't understand. when i edit the new properties file what am i putting in there exactly? The existing folder is on another server entirely. Am i supposed to copy the existing folder to the new server somewhere temporarily? i feel like there's a step missing.

[Dave Theodore [Coyote Creek Consulting]]

Here's the doc on how to set the Jira home directory. It's basically just the jira.home variable and the path to the home directory.

[cloudistics]

we're not on the same page here. let me go step by step:

1. Back up

1. Create an XML backup of your database.

2. Back up your installation directory and home directory.

 from my existing jira environment, (lets call it Jira-live). Where am i backing up this data to? am i copying from Jira-live to Jira-new? 

3. Extract the file and upgrade Jira

1. Extract (unzip) the files to a new directory. 
   

This will be on the Jira-new server.

1. Edit the  <installation-directory>\atlassian-jira\WEB-INF\classes\jira-application.properties file to point to your existing Jira home directory. Make sure that you deleted the dbconfig.xml file, otherwise Jira will try to connect to your existing database.

I'm assuming it means i'm editing Jira-new\~~\jira-application.properties. but when it says point to your existing home directory, Which existing Jira home directory? is it talking about my back up i copied to Jira-new? the current one on Jira-live? i'd have 2 at this point.

[Dave Theodore [Coyote Creek Consulting]]

Answers:

1. Just tar them up where they are.  The whole idea is to be able to restore to the last known good easily in the case of a failure.  If you really want to be cautious, copy them to another server.  It really doesn't matter where they are saved, though. I would recommend doing a database dump with the native backup client rather than doing an XML dump, since it's faster, but it doesn't make that much difference.
2. (actually 3) Let's assume you have things installed generally per the Atlassian documentation paths. This will mean that your paths are something like:

Jira installation directory:

/opt/atlassian/atlassian-jira-7.9.0

Jira home directory:

/var/atlassian/data/jira

Let's say you want to upgrade to Jira 7.13.0 and want it to run from the same directory as 7.9.0 does now. You would install extract the new Jira version in to /opt/atlassian/atlassian-jira-7.13.0. Then edit /opt/atlassian/atlassian-jira-7.13.0/atlassian-jira/WEB-INF/classes/jira-application.properties. Add the following line to the file (or modify the existing line):

jira.home = /var/atlassian/data/jira

When you start Jira, it will read the jira-application.properties file. It will see that you have defined a home directory and it will look to see if data is there. If it is empty, it will create the structure and cause the setup wizard to run in the UI.  If it is not empty, it will validate the integrity of the home directory and start up with the configuration that is in there.  If something is wrong, it will complain with a generally useful troubleshooting error.  

If something blows up, you revert your database from the dump you did prior to your change control and start up Jira 7.9.0 to back out.  Make sense?

[cloudistics]

got it, thank you for your patience!