Jira & Confluence upgrade process using installer - generall process question

[Rob Horan]

As Jira and Confluence have moved forward, the list of supported databases has changed.  Lets say you want to upgrade your applications the simple way - by using the installer and upgrading in place.  However, your upgraded version cannot work with the database you have in place.  How do you upgrade using the installer in scenarios like this?

For example, according to the Atlassian documentation you SHOULD be able to go from say... Confluence 5.6 to 7 in a single leap.  That doesn't seem to actually be the case.

[Daniel Ebers]

Hi Rob,

do you mean that your database if on an older version and not aligned with "supported platforms" for the newer version?

If so, you would have to upgrade database first to a newer version, it this what you meant?

(The documentation refers to the application, not to the database.)

Regards,
Daniel

[Rob Horan]

I mean assume you are using a db like MSSQL Server and version x uses SQL Server 2008 and version y, your target, does not support it. 

I assume you can't simply point the installer at the Atlassian application (Jira/Confluence) and tell it to upgrade the currently installed version since the db its connected to is not compatible.

You say you have to upgrade the DB to a newer version, but unless you upgrade your entire db server while keeping the URL and db name, user, and password the same, how do you do this?  I imagine you would have to create a new server and restore the DB on the new server, but when you go to upgrade your Atlassian app you're not given an opportunity to redirect to the new DB, so then all you're going to wind doing (I assume) is destroying the existing DB so that neither the source nor target version of your Atlassian application can use it.

[Daniel Ebers]

Yes, exactly like you said .. if other applications need the old version you need to install a new VM (or hardware, Amazon Cloud, whatsoever - does not matter) holding the DB with a more recent version to further contain Jira.

Before the particular upgrade of an Atlassian product like Jira or say Confluence starts you just point it to the new database host holding the live data for Jira/Confluence.
Until it is sure that everything works you can keep the old live database on old host, after a few days you can delete it.

[Rob Horan]

So the process, and the answer is:

• Back up the database
• Restore it on a DB server that the target version of your app supports
• Shut down your application
• Manually modify the DB config file on the file system to point to the new target DB
• Run the installer, pointing it at the current installation folder
• The application will connect to the correct DB when launching after the upgrade is complete

You mentioned documentation - I reviewed the upgrade docs and have found no information about this scenario. If you have a link to an Atlassian doc that outlines these instructions could you post it here?  Thanks!

[Daniel Ebers]

Yes, that's it. I would swap 1) and 3).
Because it will be easier to guarantee consistency when application is down while to dump/backup the database.

With documentation I meant the one for Jira.
For dump and restore of a database I'd refer to the database vendor's documentation to be honest. It might be that there is something available for Jira - but that would basically only repeat the steps from official database vendor documentation.

[Rob Horan]

Thanks - I assumed you meant Jira documentation. I'm not concerned about the DB portion.  I *am* concerned about the Jira/Confluence upgrade actions.  Honestly, the directions basically say let the installer do its thing, and not much else.  I have scoured the docs and found nothing even close to describing these kind of actions, and definitely nothing about manually editing files prior to running the installer.  That's why I was asking if you had a link - it would be really helpful to see what Atlassian has as a documented process for this scenario. 

I just don't think this level of detail in their documentation actually exists.

And the thing is this is a paid product - an EXPENSIVE product - created by a company that is wildly successful and can easily expand their documentation team.  It bothers me greatly that the documentation is so deficient.  The upgrade process documentation should have all of this laid out in plain and simple terms. Am I wrong for having these expectations?