At the moment when upgrade fails a lot of users simply point the old version of JIRA at the upgraded database. The actual problem is that most of the time this appears to work. The problem only surfaces when another upgrade is performed, this time properly - by exporting to and importing from to XML. As the export is performed using the 'old' version of JIRA, and hence using the 'old' entitymodel.xml file, records of the tables introduced in the the new version of JIRA are not exported.

When the export is imported, JIRA starts behaving 'badly' as some records that must be there are simply missing.

We need to trap any errors in the upgrade tasks and if one occurs put up a page that clearly reports the error and informs the user that they should fall back by importing the XML export into the old version of JIRA. We need to explicitly mention that simply pointing old version of JIRA at the upgraded database will cause problems!

If an autoexport was done by the upgrade, we also need to mention where it is located.

An alternative is to do the whole upgrade as one huge transaction. this way if something fails we can just roll back and the users can recover by just pointing the old JIRA at the database. The problem here is that some upgrade tasks have to manipulate a lot of data, and if the installation base is large the database can start running out of resources.