There are several different ways to upgrade JIRA, and the method you choose to use depends on which version of JIRA you use and the type of environment you use it in. Use this table to determine which steps to follow to complete your JIRA upgrade:

If you need to move JIRA to a new server or use it in a new environment that has a different operating system, different database type or different location of attachment or index files, follow the instructions for Migrating JIRA to Another Server.

Required Uptime (SLA)

Hardware/Software Change

Operating System

JIRA Package

Current JIRA Version

Upgrade Process

High / Mission Critical

This method is recommended for enterprise environments where extended or unplanned downtime might negatively impact the business.

If you use JIRA in a non-mission critical environment, depending on your specific installation details, you use either the safe (no downtime) or manual method to upgrade.

If you are upgrading from JIRA 4.3.0 or later, you also have the option to use the upgrade capabilities built into the installer to perform a rapid upgrade of your existing JIRA installation - this method is the fastest way to upgrade - however due to its in-place upgrade method, having recent backups is crucial for this option.

113 Comments

I wanted to let you all know that we acknowledge the difficulties with the install and upgrade process and have a project underway to provide an improvement to the existing procedures. The scope includes both JIRA and Confluence, with the goal of reducing many of the pain points and simplifying the steps. We hope to have something new for you in the first half of 2011.

One further note is if you have some constructive feedback/thoughts/ideas you'd like to share during for this project, I'd invite you to participate in our User Task Force.

To make this process easier for me to complete and to make sure I do not miss anything i had to make up a script to give me a report of all the changes made to the existing Jira install from the released version.

So to use this you will need perl and a GNU compatible diff, and get the same version of jira you are currently running from the old version archive on atlassian's jira site.

perl jiradiff.pl /path/current-jira /path/dist-copy > diff-report.txt

This will produce a diff report of all the modifications that have been made to your current jira from the base version.

With this information I can upgrade a jira instance in less than 2 hrs and be ready to re-import the DB.

I could also add checks in the script to also scan the future jira version for files that I can just cleanly copy over then that would save some time and editing files.

So that leaves the majority of the time: checking existing plugins against the future version of jira for compatibility.

I agree with all what's said here about the upgrades. I am writing a document describing the process just to remind myself of all the steps, which are a few. I am continuously upgrading our evaluation copy of JIRA to see the last features and that's a lot of work.

I am a bit reluctant to upgrade our licensed production copy precisely because of this. I would understand that being a pain as it is people will minimize the number of upgrades, specially in production.

BTW, I got an error upgrading from 4.2.3 to 4.3

ERROR: column "protocol" does not exist

I fixed it by manually adding (from the definition in entitymodel.xml) these three fields to the mailserver table.

Yes, I'm quite sure of that. The funny thing is that the MailServer table was there, but was missing "protocol","istlsrequired" and "timout". SELECT statements during the migration were failing because these fields were included in the statement but not present in the table.

I'm sorry to hear you encountered issues with the EAP 4. A number of other early access customers have had positive experiences. We've tested the Linux console installer on Red Hat, CentOS, Ubuntu (amongst others) which are the most common platforms used by most of our user base.

What would be helpful in understanding the issues you encountered is if you could you either comment or reply to me via email some information on your OS and environment. Additionally what the mod/own permissions are on the .bin file you downloaded.

Anonymous

THis fixed it for me on Ubuntu: sudo aptitude install ia32-libs.

Seems to be an issue with the 64bit arc vs the 32bit. The installer calls for 'bin/unpack200"' which is not in that location in 64bit JRE. If you install the 32bits package as well it all works fine :)

Trying to upgrade to 4.4 from JIRA 4.3.4 Standalone on Linux, I've run the upgrade feature without complications. However, when trying to access the new JIRA installation, the JIRA setup is displayed, asking me for a database configuration (even though the JIRA_HOME/dbconfig.xml file was created with the correct configuration data). When I enter the configuration details for my existing JIRA database and test the connection, the setup wizard tells me "The database specified is not empty. Please specify an empty database for your JIRA installation."

Well yes, of course it's not empty - I'm upgrading an existing system. What are the proper steps going from here? I don't see this covered in the above section "Upgrading JIRA on Linux".

ETA: I've created a new database to see what happens. After the tables are added, the setup wizard is asking for further details (license key etc.). Comparing the new database to my existing JIRA database, the two databases are almost identical, except for an additional table, "votehistory", in the new database. This leads me to believe, that my database wasn't migrated at all during the upgrade process. I've now restored my previous 4.3.4 installation and so far it seems to be working, even though I did not restore the database from the backup made before I started the upgrade.

The fact that you're being prompted with the JIRA Setup Wizard after upgrading to JIRA 4.4 implies that your upgraded JIRA 4.4 installation was unable to access the dbconfig.xml file in your JIRA Home Directory. If JIRA 4.4 detects a dbconfig.xml file in your JIRA Home Directory, you should not see the JIRA Setup Wizard (or at least the DB Configuration step of this wizard) upon starting your upgraded JIRA installation for the first time.

Is it possible that your upgraded JIRA 4.4 installation is not correctly accessing your JIRA Home Directory?

the conf/server.xml file in your JIRA Installation Directory (if you have defined the value of this property specifically in the Tomcat app server running JIRA).

Also, please check if the location of JIRA_HOME (as an environment variable on your OS) has been defined correctly (and points to the JIRA Home Directory used by your upgraded JIRA 4.4 installation). Be aware (as we've now clarified in our documentation), the value of a JIRA_HOME environment variable overrides any definition of a jira.home property defined in (1) above.

Kind regards,
Giles.

P.S. If you're certain that your upgraded JIRA 4.4 installation is correctly accessing your JIRA Home Directory, then please submit a support request using the button at the end of this page. I'd also recommend attaching the following files:

Mac OS is not a supported operating system for the JIRA server […] because Oracle JDK and JRE (formerly Sun JDK and JRE), which are the only supported Java platforms for JIRA, are not available for this operating system […] we do not test JIRA with unsupported Java platforms.

It seems that any reference to running JIRA 4.4 on Mac OS X Server has been completely removed in the new version also. Just wondering if you had published any warning about this change more widely (e.g. in your email notifications) that we weren’t aware of?

We are a Mac shop and have been running JIRA on our Mac OS X Snow Leopard Server (10.6.8) quite comfortably, but aren’t particularly thrilled with the general “not supported” line/direction that seems to have crept in over the last couple of months.

Another related question: since Apple is not shipping Java with Lion or Lion Server, and getting Oracle to build it instead, will you “support” and “test” JIRA on Mac OS X Lion once that’s released… or are you basically saying to your userbase “don’t install JIRA on a Mac Server, even if it runs the latest official version of Oracle JDK and JRE” moving forward?

Some clear guidance here would definitely be appreciated---we’d rather not have to migrate off JIRA to another task/issues manager but obviously we’ll plan for that if we need to.

A couple of other customers have had the same question - I just posted some information here on when we removed support.

To your point, we could have been more vocal about the end of support - we posted the change and made the update to our documentation, but it clearly didn't get broad enough distribution because a few customers were surprised by the note when they looked at the JIRA 4.4 download page today. We don't have any explicit plans to reintroduce support for Mac OS X, but we continue to have a large number of customers like yourselves who run JIRA successfully.

Thanks for the reply Bryan, but confusion is probably putting it mildly. From the page history it appears that note was added two days prior to the release of version 4.3.4, where no such notice existed when we installed version 4.3.2 (our current version). It’s also since been added to the “Download JIRA” page itself, where it wasn’t previously (i.e. when we installed it). So then…

Are you saying that the version we purchased (which had no mention of Mac OS X Server being “unsupported”) is now treated as an at-risk product for some reason?

Are we any more “supported” by you if we simply stick with our current version, which we understood at the time to be “supported”?

Are you also still saying that even if/when Oracle JDK and JRE are released for Mac OS X Lion Server, that will still likely be “unsupported” anyway? (i.e. in effect, to be honest you just don’t intend “supporting” Mac OS X Server at all regardless?)

If that’s the case, it puts us squarely up the creek with our installation, and looking for alternatives… and having to pay up for a hosted JIRA instance won’t be one of them. I’ve been advocating JIRA due to its many benefits, and was responsible for getting it implemented in our workplace, but am left feeling pretty unimpressed right now.

Anonymous

Clear to me. Out the door with Jira and Greenhopper. Thanks for everything. My opinion... not very professional to just stop supporting a product on a platform that you've supported for a long time, without notifying your customers properly. You know... you have our email addresses. You might as well have used it to send important information.

I promoted Atlassian several years. That will stop now. Not that you care now that you have more customers than ever, since you changed your licenses to 10 bucks for small teams.

I have been using Jira@Greenhopper on Mac OSX for some time now. Will just migrate my data to some other tool that will run on Mac OSX.

Unfortunately we never intended/tested the upgrade path from the beta versions to the final release, but there is a workaround for the problem you are seeing.

When installer runs it first works out if it upgrades from a version earlier than 4.4 (eg. 4.3.2 or 4.3.1) it needs to perform certain migration tasks. One of the task is to transfer the db configuration from the old way (config defined inside <install-dir>/conf/server.xml and <install-dir>/atlassian-jira/WEB-INF/classes/entityengine.xml) to the new way (config defined inside <home-dir>/dbconfig.xml ) .

In your case installer rightly thinks that this version is earlier than 4.4 and assumes that the db would be configured in the old way and when it does not find the old way(because rc uses the new way already) it doesn't know what to do and exits.

As a workaround you can trick the installer by modifying <install-dir>/atlassian-jira/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.properties file and change the version from 4.4-beta1 to just 4.4 then the upgrade will work.

Anonymous

After the update, from 4.3 to 4.4, I get this exception when I run Jira.

java.lang.NoClassDefFoundError: com/atlassian/jira/startup/ApplicationPropertiesJiraHomePathLocator$1
at com.atlassian.jira.startup.SystemTenantJiraHomeLocator.<init>(SystemTenantJiraHomeLocator.java:12)
at com.atlassian.jira.startup.JiraHomeStartupCheck.<clinit>(JiraHomeStartupCheck.java:37)
at com.atlassian.jira.logging.MultiTenantJiraHomeAppender.<init>(MultiTenantJiraHomeAppender.java:27)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:330)
at org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:121)
at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:664)
at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:647)
at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:544)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:440)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:476)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:471)
at org.apache.log4j.LogManager.<clinit>(LogManager.java:125)
at org.apache.log4j.Logger.getLogger(Logger.java:118)
at com.atlassian.jira.startup.LauncherContextListener.<clinit>(LauncherContextListener.java:34)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

I've tried moving the JIRA Home and Installation directories, but that didn't work. I still get this NoClassDefFoundError on start up. ApplicationPropertiesJiraHomePathLocator must be referring to something that is not in the classpath, because as I posted below (anonymously), the class exists.

Anonymous

Just an FYI, if you change the name of the <JIRA Install Directory>/atlassian-jira directory, the upgrader will fail saying that the directory is "not a valid existing JIRA installation directory". Don't think this was specifically stated anywhere, but the sub-directory has to be named "atlassian-jira" to get it to work.

Just ran the 64-bit Linux installer to upgrade a small instance on an Ubuntu server from 4.3 to 4.4. I answered a few questions and upgraded JIRA successfully in 1-2 minutes. Nice!

The only thing that surprised me was that the installation went into the same directory – i.e., 4.4 was installed into /usr/local/jira-4.3/ where my previous installation was located. It would be nice to have the option to install into a new directory. For example, upgrade from /usr/local/jira-4.3/ }}into {{/usr/local/jira-4.4/. Maybe other folks use a single directory, but I prefer to use versioned directories and keep /usr/local/jira as a symlink to the current version.

It was quite tough for us to decide if we wanted to install the new version on-top of the old one or create a new version-named directory. On one hand if the old directory has the version number in its name then upgrading on-top will mean the new version will sit in the directory named after an old version. On the other hand customers may have existing scripts, services, custom created menu shortcuts on windows or other environment settings that depend on the existing name of the directory. At the end we decided that preserving the environment and not breaking the existing scripts is more important and we went with the on-top upgrade option. We have also changed the suggested installation directory name for the installer - now it doesn't include a version number.

How about a separate question? e.g., if JIRA was detected in /usr/local/jira-4.3/, then you'd get these two questions:

Location of existing installation to upgrade [/usr/local/jira-4.3/]?

Destination for upgraded version? [/usr/local/jira-4.3/]?

Subsequent versions of the installer could try to be smarter and, if a version number detected in the current location, would suggest a folder with the new version in that case.

People who want to install directly over the existing location just need to press Enter one extra time. Those of us who use versioned installs & symlinks won't be surprised where the new version ends up.

Anonymous

I ran the installer to upgrade from 4.3.4 to 4.4. The upgrade process is perfect Now, having version 4.4 installed in /home/jira/atlassian-jira-4.3.4-standalone/ is awkward. I know where I live (for now), but this is definitely confusing. I finally renamed the installation directory to /home/jira/atlassian-jira-standalone as follows:

Stop JIRA

Rename the installation directory

Edit bin/permgen.sh and adjust JAVA_HOME to the new directory name

Edit /etc/init.d/jira and adjust BASE to the new directory name

Cross fingers

Start JIRA

This worked for me. I hope I didn't miss anything. Comments are welcome!

etc/init.d/jira is one of a reason why we decided not to change the name of the installation directory . We just don't have control over non-atlassian scripts that might point to the installation directory and therefore would break if we change its name.

Your steps will work fine. If you have some other scripts that point to the old installation dir you will have to change them too.

There's no need to upgrade to an interim JIRA version before upgrading to JIRA 4.4, although the Migrating JIRA to Another Server procedure is more involved than the one described above.

Once you're on JIRA 4.4, however, upgrades to future versions of JIRA should be faster and relatively straightforward — i.e. based on the procedure above. (This is assuming you haven't customised your JIRA installation too much and you're using the JIRA Standalone distribution.)

if you run the JIRA Upgrade Check before upgrading, it will tell you to disable certain plugins, upgrade JIRA and enable those plugins after the upgrade. However, if you make the mistake to disable Fisheye as recommended (e.g. from JIRA 4.3 to 4.4) then the new JIRA will "start" in a locked state, complaining that it needs Fisheye. See How to Enable the FishEye Plugin from the Plugin Administration Screen if you are stuck with this one (but you'll have to update one record manually in the database as explained in the comments, the URL trick won't work).

The installer deletes the original directory before checking if there's enough space to perform the upgrade. It should check this before making any deletion.

If the installer tells you that files have been added/modified/removed, get them before it deletes the original directory (otherwise you'll have to unzip them from the backup).

If you were using the previously recommended stable symlink to the current JIRA installation directory, the new installer breaks that in installing everything in the old directory.

The Fisheye problem is a real UX bug, because if you follow the instructions provided within JIRA, you end up in a very difficult situation (having to delete records manually in the database isn't pleasant).

As for the directory name issue, I perfectly understand the reason for not changing it. It's a one time issue, once you understand how it works it's a matter of changing your habits (which might be more difficult than renaming things on the server ). I've just updated from 4.4 to 4.4.1 and it was a much more pleasant experience, so this one's going to be soon forgotten.

There remains one caveat that I faced again today: the upgrade does not properly pass through the proxy details in conf/server.xml which forces to stop and restart JIRA after carrying the modifications. Ideally you should allow the admin to copy the modifications during the update (may be showing diffs between the old and the new file), or at a minimum suspend the upgrade process and let the admin modify some key files before starting the upgraded JIRA instance.

If your existing JIRA 4.3 application lives in a symlinked location, and you specify the symlink when asked for its location (instead of the script-assumed default of /opt/JIRA), then the ZIP process to archive your old install creates a .zip file with nothing in it but the symlink. Fortunately for me, I don't trust installers and I had made my own backup copy of my 4.3 install. Otherwise, it would be long gone, and the changed or added files I need for 4.4 (e.g. Crowd integration, Tomcat config) would be hassle to redo.

The script notifies you about modified and added files, and tells you it will update other modified files itself. But it does not correctly tell you it will not fully update your Tomcat configuration (e.g. HTTPS-only mode on port 443), and so you lose that piece of configuration with no notification. You will have to go back and fix conf/server.xml yourself by hand.

Sounds like a bug. When upgrading from 4.3 to 4.0 we actually try to preserve the ownership of the files and then start the process as the user who owns the files. Obviously id didn't work for you as "all files were chowned 403:root" . After changing the permissions you might want to set the username in the user.sh file if you start it as a service (i.e. if you run the start command as root), it will just switch to jira before launching the process.

re: modifications of the server.xml

We actually do warn in the documentation that only port numbers get migrated over from server.xml . Obviously, it is not the ideal behavior - this issue tracks the possible solutions and elaborates on why the current approach was chosen.

Anonymous

Just so that you're aware, we don't focus on writing documentation for platforms or configurations that we don't support. Our Supported Platforms page indicates that Mac OS X is not a platform supported by JIRA and our Java section on the JIRA Requirements page indicates why we don't support this operating system.

Anonymous

What's the recommended upgrade path from JIRA 4.4.3 32-bit to JIRA 5.0 64-bit (on a Windows 2008 R2 x64 OS)? I assume the path has to change, so the manual method would be required. But would it be better to upgrade to 5.0 32-bit first, then install a new 5.0 64-bit and move the contents of the 32-bit installation folder? Seems like that would be easier (if it works).

Anonymous

I went ahead and tried this (it's a vm not in production yet). First I upgraded to JIRA 5.0 32 bit successfully. Then I stopped the old instance and installed the 64bit version to the new path. I copied all of the data from the old data home directory (program files (x86)\atlassian\application data\jira) to the new path (same but without x86). replaced the server.xml, web.xml, and cacerts files (because i configured ssl). start the new instance. That's all I had to do.

I am wondering what the advantage of upgrading to 64bit would be. I belive the 64bit VM mainly alows you to assign more memory to Jira. As Jira does not seam to need more than 1 or 2 GB of memory I do not see the point.

Can any of you tell me why you wanted to upgrade to 64bit? What are the advantages?

I would say this depends on the number of projects and isssues you have. If it is possible to perform the jira-XML-export in acceptable time I would just create an export on the old server and import this data on the new server. Upgrading the old server should not be nessesary.

An other way might be just connecting the new 5.x server to the old 4.4.3 database. I think this should trigger the db update skripts.

Both alternative should be simpel enough to test before performing the upgrade.

Is there a way to initialize just MySQL DB upgrade procedure for JIRA 4.3 -> 5.0 migration? I remember it was exist in 3.x -> 4.x migration.

Why I need this? I successfuly upgraded and tested my JIRA to 5.0 on test server. Now I want to finish Jira migration, i.e. sync MySQL DB and attachments from the old server and redirect users to the new Jira.

If the upgrade does not carry over changed or installed files for customisations, it's not really an upgrade, but a fresh install that happens to do a backup before hand. Ideally, there should at least be an option for these files to be copied back in after the upgrade. They should, at least, be tarballed up so that they're not clobbered by the upgrade.

Starting the Jira instance immediately after the upgrade is also non-optimal, especially if there are other server config issues to tweak, and certainly if (as above) the config tweaks, custom plugins, etc have not yet been copied back into place. There should at least be an option to not restart immediately after the upgrade.

Thanks for your comment. During the upgrade we do transfer over some modifications (e.g. port numbers), however in general case we cannot migrate all the customisations. Simply copying those customised files can potentially lead to problems as the old files may not be compatible with the new version. Here is the discussion of why some particular files cannot be migrated.

Starting the Jira instance immediately...

This came up several times, please vote on
CONF-24414
-
On upgrade if we found there are modz in the system we cannot handle we should give the customer an option not to start confluenceOpen
and we will try to implement this in the future.

Sorry to hear that.It could be the new Autowatch feature, and not a change in your notification settings.

If it is not autowatch, we'd love to get down to the bottom of this problem, and so would you please raise a support ticket? If you have not used our support services before please sign up for a new account.

In topic 3. Performing the Upgrade, would be great if you remove this deprecated note:

Note: Please note that for JIRA 5.2 Installer, there is a known bug: JIRA 5.2 Installer Service is using Tomcat 6 instead of Tomcat 7. Please refer to JRA-30518 - Authenticate to see issue details and workaround. This will be fixed in JIRA 5.2.1

For me, I install JIRA as a fresh new install for my upgrades since I find that the upgrade part of the installer doesn't work right for us. Then I manually added our plugins to the plugin folder, make my customizations to the setenv.sh file and others. Then I start JIRA and run through the OOB wizard and choose to restore a previous xml backup.

Anonymous

I have a general query regarding an Upgrade of JIRA from 5.15 to latest version (v6)

A general rule when proposing to upgrade is to ensure the version is stable and that major bugs have been identified and rectified, what I am asking is what version of JIRA 6 would be a good time to upgrade? I have stated to my development team that we should wait until a certain amount of bugs have been fixed, but I wanted a comment from Atlassian.

We have two JIRA instances (5.2.5 and 5.2.6), and I hope to upgrade shortly to 6.1.

Are there any issues to take into account if one of the instances remains at the 5.2.x version, and the other upgrades to 6.1? For instance, we use the "JIRA to JIRA Issue Copy" plugin to make remote copies from one instance to the other, and ran into problems under 5.2.x, where one instance had more (or fewer) custom fields than the other (due to the JIRA instances being at separate company departments, each with its own workflow - it is a no-go to try and fit everything into one JIRA configuration).

Hi! Thanks for the quick reply! We now expect our ability may try to move the decision on their own, in our Russian supplier Jira - company TeamLead. What are your terms? We need hosting. migration and upgrade solutions.

Hi Ilya, everything we offer is described on our website. https://www.atlassian.com/software/jira/try/ - you will be able to add Confluence+JIRA+... when you set it up. If you are planning to migrate or have specific needs please talk to our support and they will help you out.

I've tried to upgrade from 5.2 to 6.3.4. At the end the installer says "Your installation of JIRA 6.3.4 is now ready and can be accessed via your browser. But in the browser I see the following:

An error occurred performing JIRA upgrade

The data before the upgrade has been exported to /data/atlassian/application-data/jira/export/jira_autoexport_20140821_083236.zip

2014-08-21 08:32:42

error

Exception thrown during upgrade: java.lang.RuntimeException: com.opensymphony.workflow.FactoryException: Error converting XML to workflow descriptor.: root cause: action with id 1 already exists for this step.
com.atlassian.cache.CacheException: java.lang.RuntimeException: com.opensymphony.workflow.FactoryException: Error converting XML to workflow descriptor.: root cause: action with id 1 already exists for this step.
at com.atlassian.cache.memory.DelegatingCache$DelegatingLoadingCache.get(DelegatingCache.java:270)
at com.atlassian.jira.workflow.CachingWorkflowDescriptorStore.getWorkflow(CachingWorkflowDescriptorStore.java:68)
at com.atlassian.jira.workflow.JiraWorkflowFactory.getWorkflow(JiraWorkflowFactory.java:37)
at com.opensymphony.workflow.config.DefaultConfiguration.getWorkflow(DefaultConfiguration.java:89)
at com.atlassian.jira.workflow.OSWorkflowManager.getWorkflow(OSWorkflowManager.java:197)
at com.atlassian.jira.workflow.OSWorkflowManager.getWorkflows(OSWorkflowManager.java:116)
at com.atlassian.jira.upgrade.tasks.UpgradeTask_Build813.doUpgrade(UpgradeTask_Build813.java:38)
at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeTaskSuccess(UpgradeManagerImpl.java:693)
at com.atlassian.jira.upgrade.UpgradeManagerImpl.runUpgradeTasks(UpgradeManagerImpl.java:542)
at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgrade(UpgradeManagerImpl.java:471)
at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeIfNeeded(UpgradeManagerImpl.java:413)
at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeIfNeededAndAllowed(UpgradeManagerImpl.java:348)
at com.atlassian.jira.upgrade.UpgradeLauncher.checkIfUpgradeNeeded(UpgradeLauncher.java:106)
at com.atlassian.jira.upgrade.UpgradeLauncher.start(UpgradeLauncher.java:54)
at com.atlassian.jira.startup.ActiveServicesLauncher.start(ActiveServicesLauncher.java:42)
at com.atlassian.jira.startup.DefaultJiraLauncher$3.run(DefaultJiraLauncher.java:133)
at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrEnqueue(DatabaseConfigurationManagerImpl.java:324)
at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrWhenDatabaseActivated(DatabaseConfigurationManagerImpl.java:214)
at com.atlassian.jira.startup.DefaultJiraLauncher.postDbLaunch(DefaultJiraLauncher.java:115)
at com.atlassian.jira.startup.DefaultJiraLauncher.access$100(DefaultJiraLauncher.java:31)
at com.atlassian.jira.startup.DefaultJiraLauncher$1.run(DefaultJiraLauncher.java:78)
at com.atlassian.jira.util.devspeed.JiraDevSpeedTimer.run(JiraDevSpeedTimer.java:34)
at com.atlassian.jira.startup.DefaultJiraLauncher.start(DefaultJiraLauncher.java:73)
at com.atlassian.jira.startup.LauncherContextListener.contextInitialized(LauncherContextListener.java:71)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4992)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5490)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: com.opensymphony.workflow.FactoryException: Error converting XML to workflow descriptor.: root cause: action with id 1 already exists for this step.
at com.atlassian.jira.workflow.CachingWorkflowDescriptorStore$WorkflowCacheLoader.load(CachingWorkflowDescriptorStore.java:143)
at com.atlassian.jira.workflow.CachingWorkflowDescriptorStore$WorkflowCacheLoader.load(CachingWorkflowDescriptorStore.java:132)
at com.atlassian.cache.memory.MemoryCacheManager$3$1.load(MemoryCacheManager.java:132)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3573)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2350)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2313)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2228)
at com.google.common.cache.LocalCache.get(LocalCache.java:3970)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3974)
at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4834)
at com.atlassian.cache.memory.DelegatingCache$DelegatingLoadingCache.get(DelegatingCache.java:264)
... 32 more
Caused by: com.opensymphony.workflow.FactoryException: Error converting XML to workflow descriptor.: root cause: action with id 1 already exists for this step.
at com.atlassian.jira.workflow.WorkflowUtil.convertXMLtoWorkflowDescriptor(WorkflowUtil.java:437)
at com.atlassian.jira.workflow.OfBizWorkflowDescriptorStore.convertGVToDescriptor(OfBizWorkflowDescriptorStore.java:170)
at com.atlassian.jira.workflow.OfBizWorkflowDescriptorStore.getWorkflow(OfBizWorkflowDescriptorStore.java:49)
at com.atlassian.jira.workflow.CachingWorkflowDescriptorStore$WorkflowCacheLoader.load(CachingWorkflowDescriptorStore.java:139)
... 42 more
Caused by: java.lang.IllegalArgumentException: action with id 1 already exists for this step.
at com.opensymphony.workflow.loader.WorkflowDescriptor.addAction(WorkflowDescriptor.java:681)
at com.opensymphony.workflow.loader.WorkflowDescriptor.addCommonAction(WorkflowDescriptor.java:247)
at com.opensymphony.workflow.loader.WorkflowDescriptor.init(WorkflowDescriptor.java:620)
at com.opensymphony.workflow.loader.WorkflowDescriptor.(WorkflowDescriptor.java:65)
at com.opensymphony.workflow.loader.DescriptorFactory.createWorkflowDescriptor(DescriptorFactory.java:135)
at com.opensymphony.workflow.loader.WorkflowLoader.load(WorkflowLoader.java:79)
at com.opensymphony.workflow.loader.WorkflowLoader.load(WorkflowLoader.java:47)
at com.atlassian.jira.workflow.WorkflowUtil.convertXMLtoWorkflowDescriptor(WorkflowUtil.java:433)
... 45 more

Under "Custom modifications" the installer tells I have to manually transfer the customisations.

The installation script for the standard installer (atlassian-jira-6.3.10-x64.bin) needs one thing changed at the end.

If you have Custom Modifications to server.xml, then the installer should NOT automatically start up Jira. If you have "customisations (eg server.xml) that must be manually transferred." then of course you would rather not have JIRA start up before you can manually transfer those customizations back into the server.xml file. In order to do that, you first have to SHUT DOWN JIRA after the installation script has just started it up. This is annoying because I have to give it a good 2 to 3 minutes before I shut it down so that I don't create a race condition.

Should be a simple check to see if custom modifications are detected, in which case, DO NOT automatically start JIRA.

I couldn't agree more. I keep forgetting to mention this or raise a ticket every time I perform an install. I essentially have to wait for the upgrade to fail, shut down JIRA (and Confluence), make my changes, then start it up again. A simple "Would you like to start the Jira/Confluence/etc... service now?" would be a great addition.