Currently the Sprint data is stored in a server timezone specific way, thus backing up the data and restoring it on a server with different timezone results in Sprint start/end/completion dates to be wrong. This can also result in the grey guideline in the Burndown chart appearing incorrectly - it can look like it is "lost". For example it will show purely on the x-axis instead of crossing over from y to x.

Either store the values in UTC millis since epoch or use Date column type (to be validated whether this solves the problem correctly).

Workaround

In order to restore the times back to their last known working form, the below process can be used for the new server:

1. Generate an XML backup from the previous server, or obtain the last-known working one and copy it to the new JIRA server.
2. Schedule a downtime window.
3. Stop the new JIRA server.
4. Either:
   • Set the JVM timezone argument, e.g.: -Duser.timezone=GMT, as in Setting Timezone in JIRA.
   • Change the System Time of the server that the JVM is running on (the JVM will default to that time).
5. Start the new JIRA server.
6. Import the XML backup from the previous server.
7. Test the charts and JIRA.

If the server is unable to be rolled back, the below can be followed, however this is not the recommend method and may cause additional problems due to time inconsistencies.

1. Schedule a downtime window.
2. Export the XML backup.
3. Stop JIRA.
4. Either:
   • Set the JVM timezone argument, e.g.: -Duser.timezone=GMT, as in Setting Timezone in JIRA.
   • Change the System Time of the server that the JVM is running on (the JVM will default to that time).
5. Start JIRA.
6. Import the XML backup.
7. Test the charts and JIRA.