Documentation for JIRA 6.4 (This documentation includes the project navigation sidebar). Not using this? See below:
(JIRA 6.4 without sidebar documentation | JIRA 6.3.x documentation | JIRA Cloud documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

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 ChangeOperating System
JIRA PackageCurrent JIRA VersionUpgrade Process

High / Mission Critical

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

For information on upgrading to JIRA Data Center, please see Installing JIRA Data Center.

AnyAnyAnyAnyUpgrading JIRA with a Fallback Method

Low – Medium

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.

Neither operating system, database or home directory will be changed.MS Windows / LinuxStandalone4.3.0 or laterUpgrading JIRA Using a Rapid Upgrade Method
4.2.x or earlierUpgrading JIRA Manually
WARAnyUpgrading JIRA Manually


AnyAnyUpgrading JIRA Manually

If you plan to skip multiple major versions of JIRA when you upgrade, please review the Skipping Major Versions when Upgrading JIRA for important information on the recommended way to skip versions.



  1. 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.

    (info) 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.

  2. 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 /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.

  3. Un outil de mise à jour s'impose!

    Update Tool FTW !!

    Merci :)

  4. 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.

     protocol      | character varying(60)  |
     istlsrequired | character varying(60)  |
     timeout       | numeric(18,0)  

    1. Are you sure that you haven't reused entitymodel.xml from your 4.2.3 system? MailServer table has been just introduced in the 4.3 release the protocol is defined in there.

          <entity entity-name="MailServer" table-name="mailserver" package-name="">
              <field name="id" type="numeric"/>
              <field name="name" type="long-varchar"/>
              <field name="description" type="very-long"/>
              <field name="from" col-name="mailfrom" type="long-varchar"/>
              <field name="prefix" type="short-varchar"/>
              <field name="smtpPort" col-name="smtp_port" type="short-varchar"/>
              <field name="protocol" col-name="protocol" type="short-varchar" />
              <field name="type" col-name="server_type" type="short-varchar"/>
              <field name="servername" type="long-varchar"/>
              <field name="jndilocation" type="long-varchar"/>
              <field name="username" col-name="mailusername" type="long-varchar"/>
              <field name="password" col-name="mailpassword" type="long-varchar"/>
              <field name="istlsrequired" type="short-varchar"/>
              <field name="timeout" type="numeric" />
      1. 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.

        1. That sounds very strange. Is there any chance you could share with us your log file covering the upgrade phase, so we can learn a bit more about the problem?

          If possible, can you create a support request and mention our conversation in here.


          1. Yes, sure. Thanks a lot for your interest Bogdan.

            Created a support issue



            1. From info provided by Daniel we were able to reproduce this problem locally and find the cause of the provided error.

              If entitiengine.xml is missing the required scheme parameter when integrating with Postgres, during the ugprade process JIRA is unable to create its tables correctly.

              We have described this problem in more details in our KB page - Missing 'protocol' Column Error After Upgrade.

  5. There were a million errors like this in the logs too, for many entities. A problem with mixed/lower case perhaps?

    2011-03-17 15:20:00,843 main WARN      [core.entity.jdbc.DatabaseUtil] Entity "FavouriteAssociations" has no table in the database
    2011-03-17 15:20:00,843 main ERROR      [core.entity.jdbc.DatabaseUtil] Could not create table "favouriteassociations"
    2011-03-17 15:20:00,843 main ERROR      [core.entity.jdbc.DatabaseUtil] SQL Exception while executing the following:
    CREATE TABLE favouriteassociations (ID NUMERIC(18,0) NOT NULL, USERNAME VARCHAR(255), entitytype VARCHAR(60), entityid NUMERIC(18,0), SEQUENCE NUMERIC(18,0), CONSTRAINT PK_favouriteassociations PRIMARY KEY (ID))
    Error was: org.postgresql.util.PSQLException: ERROR: relation "favouriteassociations" already exists

    1. If you still experience this problem, can you please create a support request at and provide us with some more details on the problem:

      • log file covering the upgrade process,
      • entityengine.xml,
      • any other modified configuration files
  6. ...

    Incidentally, the so-called "Console Wizard" binary download (1) was not executable - why not? (2) Errored with "The architecture or bitness (32/64)

    of the bundled JVM might not match your machine". You test this stuff, right? You spin up an image and go through an upgrade yourselves before writing the documentation? 

    1. Hi Patrick,

      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.

      Thanks in advance.

    2. 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 :)

       The architecture or bitness (32/64)

      1. Starting from the next milestone we will ship both 32 and 64 bit packages.

  7. Anonymous

    I am having the same issue as Patrick with the "Error unpacking jar files. The architecture or bitness (32/64)"

    Here is my server info:

    Ubuntu 10.10 (maverick - 64bit)

    I will go ahead and just run it on a CentOS instance instead for now. The Ubuntu just has a little less overhead. 

    of the bundled JVM might not match your machine."Error unpacking jar files. The architecture or bitness (32/64)
    of the bundled JVM might not match your machine.

  8. 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.

    1. Hi Juerg,

      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?

      1. Please check the value of the jira.home property in either:
        • your file (in your JIRA Installation Directory), or
        • 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).
      2. 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,

      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:

      • dbconfig.xml
      • server.xml
  9. Hi,

    I noticed that on 25 May 2011 a note was added to the JIRA 4.3 Mac OS X Installation Guide saying:

    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.

    Xander Plooy
    Technical Team Leader, XCOM Media

    1. Xander,

      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.   

      Apologies again for any confusion caused,

      Bryan Rollins
      JIRA Product Management

      1. 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…

        1. 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?
        2. Are we any more “supported” by you if we simply stick with our current version, which we understood at the time to be “supported”?
        3. 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.


      2. 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.

  10. Anonymous

    I tried to upgrade my Jira Beta installation (v4.4-beta1#644-r153810) to the release version 4.4 but I have this error message : "An error occurred when parsing your installation directory"

    Any Idea ? Thxs, Clément.

    1. Hi Clément,

      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/ file and change the version from 4.4-beta1 to just 4.4 then the upgrade will work.



      1. Anonymous

        We are getting ready to upgrade from 4.4-rc1 to 4.4.1, should I make this change as well?

        1. Yep, you should make this change.

  11. Anonymous

    Exactly the same problem for me - running JIRA 4.4-beta1-#638.

    When choosing the upgrade option in the installer it correctly detects the path of the existing jira installation and then as soon as you confirm this it fails with:

    nice spelling of 'upgrade' too :)

    Any suggestions?

    1. See the workaround I have described for the problem.

      Thanks for catching the spelling mistake, we'll fix it.

  12. 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>(
            at com.atlassian.jira.startup.JiraHomeStartupCheck.<clinit>(
            at com.atlassian.jira.logging.MultiTenantJiraHomeAppender.<init>(
            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(
            at org.apache.log4j.helpers.OptionConverter.instantiateByKey(
            at org.apache.log4j.PropertyConfigurator.parseAppender(
            at org.apache.log4j.PropertyConfigurator.parseCategory(
            at org.apache.log4j.PropertyConfigurator.configureRootCategory(
            at org.apache.log4j.PropertyConfigurator.doConfigure(
            at org.apache.log4j.PropertyConfigurator.doConfigure(
            at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(
            at org.apache.log4j.LogManager.<clinit>(
            at org.apache.log4j.Logger.getLogger(
            at com.atlassian.jira.startup.LauncherContextListener.<clinit>(
            at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
            at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)


    1. Anonymous

      I fix the problem. I have jira-home directory inside jira installation directory.

      1. I'm glad you found the cause of the issue and just to reiterate, locating your JIRA Home Directory inside your JIRA Installation Directory is not recommended.

        1. Anonymous

          I have the same problem after running the upgrade script (on Linux). I've tried changing the JIRA home directory, but that didn't work.

          The class is there:

          What's the deal?

        2. 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.

  13. I performed an upgrade from JIRA 4.3.4 today to JIRA 4.4 on my Ubuntu Linux 10.04 system.  This JIRA instance is hosted behind my Apache web server and uses SSL (I access JIRA using

    The installation wizard is "nice", but it didn't migrate the following settings from my existing conf/server.xml in the <Connector> section under <Service name="Catalina">

    • scheme
    • proxyName
    • proxyPort

    The installation wizard also didn't migrate the additional setting from my existing conf/server.xml in <Engine>, <Host>, <Context>

    • path
    1. Hi Troy, thanks for mentioning your problems it will definitely help us to improve the upgrader.

      The issues you described are discussed under

  14. 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. 

  15. 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.

    1. +1 ... I had a similar experience with the directory names. (I had, after all, followed Atlassian's guidance on naming directories after the JIRA version).

    2. Burke, Michael,

      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.

      1. 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. (smile)

        1. Anonymous

    3. +1

      I ran the installer to upgrade from 4.3.4 to 4.4.  The upgrade process is perfect (smile)  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:

      1. Stop JIRA
      2. Rename the installation directory
      3. Edit bin/ and adjust JAVA_HOME to the new directory name
      4. Edit /etc/init.d/jira and adjust BASE to the new directory name
      5. Cross fingers
      6. Start JIRA

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

      1. etc/init.d/jira is one of a reason why we decided not to change the name of the installation directory (smile). 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.

      2. Thank you very much for posting this change.

        Atlassian Support - It would be nice in the future if the upgrade script would just rename the directory for us (smile)


  16. Anonymous


       I've tried to update from 4.3.4 to 4.4 in Test Environment, but the update fails immediately with the already seen message:

    An error occurred when parsing your installation directory. Unfortuantely the installer will be unable to continue with the automated updgrade.

    My installation folder is:

    C:\Program Files\Atlassian\JIRA 4.3.4

    What could I do to bypass the problem? If possible I would not try to reinstall Jira by scratch and then reimport, copy files, etc.


      Marco Barbaro

    1. Hi,

      it is definitely possible to do the upgrade the old way i.e. export data from the old version install a new version of JIRA and import the data into it.

      You might want to contact support to figure out why the new upgrader didn't work for you.

    2. Hi Marco,

      Try either the Upgrading JIRA Manually (which involves an 'in-place' upgrade of your JIRA database) or Migrating JIRA to Another Server (which involves lengthier XML exports and imports of your JIRA database).

      Having said that, I'd also recommend contacting support to work out why the upgrade wizard didn't work for you.


      1. Thanks to both Anatoli and Giles,

           however I've opened an issue to the support (code 88141)


      2. I've also filed a support incident:   Trying the manual upgrade tonight, after hours.

  17. Hi!

    Can I find instruction for upgrading from JIRA 3.13.5 to 4.4? Can i do this action from one step? Or I need upgrade to 4.0, and later to 4.4?

    1. Hi Max,

      Since you're upgrading from JIRA 3.13, please follow the Migrating JIRA to Another Server procedure to upgrade to JIRA 4.4.

      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.)


  18. There are several caveats with the new upgrade application:

    • 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" (tongue) 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.
    1. François,

      Thanks for listing the caveats, especially the fisheye problem - I don't think we mentioned it anywhere. Some background for 'installing everything in the old directory' : .

      1. 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 (wink)). 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.

    2. More bugs in the new upgrade installer:

      1. 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.
      2. 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.
  19. Anonymous

    As I just completed the upgrade on Linux a few remarks regarding the upgrade-tool:

    • Filesystem ownerships are not preserved. After completing the upgrade all files were chowned 403:root (I fixed it by issuing

      "chown -R jira: /opt/atlassian-jira-*-standalone/logs && chown -R jira: /opt/atlassian-jira-*-standalone/temp && chown -R jira: /opt/atlassian-jira-*-standalone/work")

    • Jira is started as root? That certainly resolves the wrong permissions, but it's certainly not what's considered to be best practice..
    • The context path (./conf/server.xml) is not preserved - this is really annoying if you have more than just Jira running on the host ore are using AJP to put the bundled Tomcat "behind" Apache
    • AJP config is not preserved

    Maybe this could be adressed for future versions of the upgrade tool?

    (Also the "reusing of the old directory" is quite annoying if one did include the version in the path.. but that was already commented above)

    1. Jira is started as root?

      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 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.


  20. Anonymous

    Hey guys, how about detailed upgrade instructions for OSX as well?

    1. Hi there,

      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.

      If you do want to follow upgrade instructions for Mac OS X, the Upgrading JIRA Manually or Migrating JIRA to Another Server procedures might suit your requirements.



  21. 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).

    1. Anonymous

      I upgraded from JIRA 4.4.5 to JIRA 5.0 32bit on the same machine, then moved it over to the new 64bit server. No problem at all. 

      1. Going directly from JIRA 4.4.5 32bit to JIRA 5.0 64bit should work as well.

        1. Anonymous

          What's the process for this?  Install to new folder (Program Files instead of Program Files (x86)), then move all contents of the old JIRA folder?  Or upgrade existing and leave it in the x86 folder?

        2. 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.

    2. 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?

  22. Anonymous

    It could happen that after an upgrade, the administration section is completely blank other then the page header menus, every single link on the menu returns a blank page. The following solution has proven to resolve this particular issue: Error Creating New Ticket or Accessing Administration Section After JIRA Upgrade

  23. Anonymous

    We are planning an upgrade from Jira 4.4.3 to version 5.x,

    ánd a migration to a new server.

    If I understand this correctly, the best way to handle would be:

    • upgrade 4.4.3 -> 5.x on the old machine
    • install 5.x on the new server
    • backup (upgraded) version on the old server + restore on the new machine

    Is this correct? Any feedback would be much appreciated.

    1. 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.

  24. 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.




    1. Hi Vitaly,

      not quite sure what you mean by

      initialize just MySQL  DB upgrade procedure

      Can you please create an issue for support and we will help you out.

  25. Two issues here that stick out for the installer:

    • 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.



    1. Hi Rob,

      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 confluence Open  and we will try to implement this in the future.

      1. Oh, if only server.xml was an XML file designed to be machine-modifiable with a stylesheet or similar. O WAIT (smile)

        Having read that discussion, colour me unconvinced. This is something that needs a little effort put in. The installer/upgrader as it is creates as much work as it saves.

  26. Anonymous

    i just did an upgrade form 5.0 to 5.0.3 and he upgrade somehow messed with all of my notifications.

    now everyone gets notifications about everything that goes on for any ticket. it's a little annoying especially since i don't really know how all the notifications were set.


    1. 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.

  27. Upgraded from 4.4 to 5.0.5 ..

    Using the automated updates, I have to say I'm extremely impressed. Everything was upgraded smoothly, including our custom html templates.

    Only thing that didn't make it was conf/server.xml

    Every previous upgrades had always been a pain in the arse, not this time.



  28. Anonymous

    Trying to upgrade Jira standalone 4.4 (4.4#649-r158309) to Jira 5.0.5 using atlassian-jira-5.0.5-x64.bin.

    O/S is linux

    complete output of upgrade process is:

    [jira@servername tmp]$ ./atlassian-jira-5.0.5-x64.bin

    Unpacking JRE ...

    Starting Installer ...

    You do not have administrator rights to this machine and as such, some installation options will not be available. Are you sure you want to continue?

    Yes [y, Enter], No [n]

    This will install JIRA 5.0.5 on your computer.

    OK [o, Enter], Cancel [c]

    Choose the appropriate installation or upgrade option.

    Please choose one of the following:

    Express Install (use default settings) [1], Custom Install (recommended for advanced users) [2], Upgrade an existing JIRA installation [3, Enter]

    Existing installation directory:


    An error occurred when parsing your installation directory. Unfortuantely the installer will be unable to continue with the automated upgrade.

    Finishing installation ...

    Help please - there are no log files or anything that give any clues where to start. I've successfully upgrade this instance from a 3.x release to its current 4.4 version with no issues.


    1. Hi, can you please contact support and we will help you.

      1. Anonymous

        I have now - would have done that yesterday but the site was down.



  29. Anonymous

    I am a trainee. I must upgrade the JIRA with Terminal on Linux. But i know nothing about JIRA.

    How can i do ? Can you help me ?


    1. Hi, if you follow the instructions on this page you would be able to upgrade JIRA (with terminal on Linux). If you encounter any problems you can contact atlassian support.

    2. I'm in it. Someone could help me? I need to upgrade JIRA JIRA 4 to 5

  30. Anonymous

    How come this documentation relates to 5.2 when the download is 5.1.1 ?

    1. Apologies for that - it looks like the links from the JIRA download page (for JIRA 5.1.1) have erroneously lead you to the documentation for 'JIRA 5.2 Latest'.

      We'll be addressing this issue soon. Please check out the following pages in the documentation for JIRA 5.1.x versions:



  31. I need to upgrade JIRA 4 to JIRA 5. Someone could help me? 

    1. Hi Rodrigo, please contact support and we will help you with the upgrade.

  32. Hi,

    I've got JIRA version 4.4.1 which is installed on my Windows Server 2008 32 bit, so if I'm upgrading my OS into 64 bit Windows Server 2008 R2 Web Server edition, what is the benefits of going with JIRA 5.1.4 (Windows 64 Bit Installer) ?

  33. Anonymous

    Our amazon instance of JIRA crashed and all we have is JIRA 4.4.3 database.

    Can I upgrade JIRA with just the old database and no JIRA_HOME?

    1. Anonymous

      You need the database or a backup (xml export) of your instance for a restore. If your instance was configured for automatic backups (and it should be be default I believe) then you can look in:

      If this wasn't set, then I would suggest reading through the Automating JIRA Backups guide for when you get your instance back up and running again.


      1. Sorry, wasn't logged in - Also, you might want to find out if there were backups of your database taken by whoever hosts your database.

  34. After upgrade from 5.1.8, JIRA can't start, log show:"./bin/ 1: eval: localhost: not found".

    My server is ubuntu 12.04.

    1. Horizon, can you please contact support and we will help you out (would need some more info about the problem).

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

    (warning)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



    1. Updated. Thank you.

      Kind Regards,

  36. For the standalone installer, can you disable it automatically starting JIRA after the upgrade completes?

    If we can, I could have the db backup run while the installation completes, copy back in my configurations and then manually start the service when I am ready.

    1. +1 but I think it should be a question in the installer setup:

      Would you like JIRA to start after the installation completes? (y/n):

      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 file and others. Then I start JIRA and run through the OOB wizard and choose to restore a previous xml backup.

      My $0.02.

    2. JRA-31371 - As an Administrator I Would Like Not to Start the JIRA Service After Installer Completes Closed  

  37. 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. 


  38. Anonymous

    "If you are upgrading from JIRA 4.3.0 or earlier, you also have the option"

    Maybe JIRA 4.3.0 or later?

  39. Hi, How is the correct way to upgrade JIRA from 3.13 to 6.1 version?

  40. 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).

  41. I have a system Jira 4.4.5 + Confl 4.1 + Crowd 2.3.6 onDemand.
    For how many steps I (effective) upgrade system to Jira 6.3, Confl 5.5.3, Crowd 2.7.2 and move to another server (the cloud)?

    At first move to another server and update there?
    Or updated first, and then transfer?

    Update - I can update all applications immediately to the latest version?
    Or should each application step by step to upgrade to the next version, until we arrive at the last?

    1. Hi Ilya, 

      Upgrading all applications in one step should work. Is you target to move to our hosted offering? Can you please contact support and we will help you out.

      1. 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.

        1. Hi Ilya, everything we offer is described on our website. - 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.

  42. 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/
    2014-08-21 08:32:42error
    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(
    	at com.atlassian.jira.workflow.CachingWorkflowDescriptorStore.getWorkflow(
    	at com.atlassian.jira.workflow.JiraWorkflowFactory.getWorkflow(
    	at com.opensymphony.workflow.config.DefaultConfiguration.getWorkflow(
    	at com.atlassian.jira.workflow.OSWorkflowManager.getWorkflow(
    	at com.atlassian.jira.workflow.OSWorkflowManager.getWorkflows(
    	at com.atlassian.jira.upgrade.tasks.UpgradeTask_Build813.doUpgrade(
    	at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeTaskSuccess(
    	at com.atlassian.jira.upgrade.UpgradeManagerImpl.runUpgradeTasks(
    	at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgrade(
    	at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeIfNeeded(
    	at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeIfNeededAndAllowed(
    	at com.atlassian.jira.upgrade.UpgradeLauncher.checkIfUpgradeNeeded(
    	at com.atlassian.jira.upgrade.UpgradeLauncher.start(
    	at com.atlassian.jira.startup.ActiveServicesLauncher.start(
    	at com.atlassian.jira.startup.DefaultJiraLauncher$
    	at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrEnqueue(
    	at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrWhenDatabaseActivated(
    	at com.atlassian.jira.startup.DefaultJiraLauncher.postDbLaunch(
    	at com.atlassian.jira.startup.DefaultJiraLauncher.access$100(
    	at com.atlassian.jira.startup.DefaultJiraLauncher$
    	at com.atlassian.jira.startup.DefaultJiraLauncher.start(
    	at com.atlassian.jira.startup.LauncherContextListener.contextInitialized(
    	at org.apache.catalina.core.StandardContext.listenerStart(
    	at org.apache.catalina.core.StandardContext.startInternal(
    	at org.apache.catalina.util.LifecycleBase.start(
    	at org.apache.catalina.core.ContainerBase$
    	at org.apache.catalina.core.ContainerBase$
    	at Source)
    	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    	at java.util.concurrent.ThreadPoolExecutor$ Source)
    	at 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(
    	at com.atlassian.jira.workflow.CachingWorkflowDescriptorStore$WorkflowCacheLoader.load(
    	at com.atlassian.cache.memory.MemoryCacheManager$3$1.load(
    	at com.atlassian.cache.memory.DelegatingCache$DelegatingLoadingCache.get(
    	... 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(
    	at com.atlassian.jira.workflow.OfBizWorkflowDescriptorStore.convertGVToDescriptor(
    	at com.atlassian.jira.workflow.OfBizWorkflowDescriptorStore.getWorkflow(
    	at com.atlassian.jira.workflow.CachingWorkflowDescriptorStore$WorkflowCacheLoader.load(
    	... 42 more
    Caused by: java.lang.IllegalArgumentException: action with id 1 already exists for this step.
    	at com.opensymphony.workflow.loader.WorkflowDescriptor.addAction(
    	at com.opensymphony.workflow.loader.WorkflowDescriptor.addCommonAction(
    	at com.opensymphony.workflow.loader.WorkflowDescriptor.init(
    	at com.opensymphony.workflow.loader.WorkflowDescriptor.(
    	at com.opensymphony.workflow.loader.DescriptorFactory.createWorkflowDescriptor(
    	at com.opensymphony.workflow.loader.WorkflowLoader.load(
    	at com.opensymphony.workflow.loader.WorkflowLoader.load(
    	at com.atlassian.jira.workflow.WorkflowUtil.convertXMLtoWorkflowDescriptor(
    	... 45 more


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

    Where to begin?


    Burkhard from Germany

  43. I'm going to do an upgrade from 6.1.2 to 6.3.10:  Does JIRA check add-on compatibility and warn me if my target version will have incompatible add-ons?

    1. You can check this in JIRA by going into Administration -> Add-ons -> Manage add-ons and choosing "JIRA Update Check" at the bottom.

  44. 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.

    1. 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. 

  45. This page is referenced in JIRA upgrade as a page which should have information on migration customisations.  I don't see a thing about that here.


    Your previous JIRA installation contains customisations (eg server.xml) that
    must be manually transferred. Refer to our documentation more information:

  46. So do I just run the new installer to upgrade from 6.3.x?

  47. same here:

    Your previous JIRA installation contains customisations (eg server.xml) that
    must be manually transferred. Refer to our documentation more information:
    JIRA 6.4.8 can be accessed at http://localhost:8080