How to migrate Jira data to another database type without the XML backup
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
When migrating Jira data to another database type, the advised approach is through the XML backup (as described in Switching databases). If unable to do so this way, an alternative is to use some external data migration tools.
Please note we have articles for each specific scenario:
Environment
All versions of Jira Core 7 and 8.
Solution
The strategy is to use the external migration tool to migrate only the data — not the entities definitions (tables, indexes, constraints, etc). We'll startup a temporary Jira instance to create all data structure.
This is to avoid case sensitiveness errors (lowercase vs uppercase table names, etc) like when migrating from Oracle to Postgres.
General step-by-step runbook
Setup the new database (as described in Connecting Jira applications to a database) and install a new Jira instance of the exact same version and JVM parameters* as the original instance you're copying data from. It can be an ad-hoc "test" installation as it's not going to be actually used — we're only doing this so Jira creates the database structure itself with the appropriate naming conventions for the new database.
The JVM parameters are important so the same character encoding and other attributes that affect data are the same. Parameters that don't affect how the database data's manipulated (like Xms, Xmx, hostnames, GC logging, etc) can be different.
You may use Developer Licenses or Evaluation Licenses to start the new instance if needed.
Install all apps or plugins you have on the original instance with the exact same versions on the new Jira. When an app's installed it creates it's own tables, indexes and constraints.
Stop the new ad-hoc Jira instance.
Use your third party data migration tool to copy only the data (not definitions) from the original instance.
It's advised to export data from the original instance while Jira's down, so we're sure no data's currently being updated and cause errors after it's imported (some constraints are not in the "DB level" but in the application).
You may need to edit the import file or script to make minor adjustments, like for some column data types or lengths.
Import the data into the new Jira's database.
It's OK if some tables aren't found. Confirm if they are from apps that have been once installed and uninstalled (Jira doesn't wipe the apps' database data when they'r uninstalled). This List of Jira Server AO table names and vendors may help you figure out.
Custom tables created by you for some rollback purpose or reports will fail too as they wouldn't've been created by Jira on the new database.
Update and delete data on the new database as advised in Creating a test environment for Jira if needed.
Create custom indexes you had on the source database if needed. Some customers identify the need for extra indexes to improve performance in tables they rely on heavily.
Start the new ad-hoc Jira instance and update the Licenses with the new proper ones if that's the case.
Validate if the data's showing up as you expect.
Was this helpful?