<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

Whether you like it or not, preferred database platforms within an organization will change over time.

David the DOT NET Dev really wanted Microsoft SQL Server in 2005 at a price tag of 1 million dollars a year, or Tom the Fortran Dev wanted Oracle back in 1976 for 10 million.

Organizations change with the times, employees and expertise change over time, and no-one wants unnecessary costs.

So, it is likely that a change in database platform will be in your Atlassian admins future.

Why might you want to change database vendors?

  • Someone started using Atlassian tools on that old computer under their desk. They set it up on MySQL because it is free and easy to install.  Now everyone wants to use it, but the company DB standard is Oracle. You don't want to lose the existing data, but the old computer won't support adding more users, so it has to be moved to the enterprise platform.
  • Oracle and MSSQL are expensive. MySQL and PostgreSQL, not so much!
  • Expertise with a platform has left the org and now the org favors a different platform.

Database migration is easy with Bitbucket.

If you've spent any time installing or even administering Atlassian tools you know that no 2 products are created equal.  Atlassian has separate teams working on the various products and a lot of the products have been adopted.

All tools, with the exception of Bitbucket, have the ability to backup and restore to a different platform. However, in my experience, that method doesn't work in most cases. See below for common problems with this approach and how we have overcome them.

Bitbucket is easy and as far as I've seen, reliable!


  1. Prep your empty destination database.
    1. Connecting Bitbucket Server to Oracle
    2. Connecting Bitbucket Server to MySQL
    3. Connecting Bitbucket Server to PostgreSQL
    4. Connecting Bitbucket Server to SQL Server
  2. From the Admin console, click on database.
  3. This will display the current database connection information and present you with an option to migrate the database.
  4. Fill in the details for the destination database and click migrate.

This process doesn't delete anything from the source database.  If the process hits an error, it will automatically revert any changes to the bitbucket.properties file.

If the process succeeds and for some reason or another you need to switch back to the original database, a backup copy of the bitbucket.properties file will be saved in the <BITBUCKET_HOME>/shared directory.

Simply rename the files to re-point.

Database migration is NOT easy with Jira! Use Isos and Jaminator!

  • For large instances the standard XML backup and restore is usually problematic and a lot of times plain doesn't work.
    • You can either put in a support ticket with Atlassian and wait for the back-n-forth to lead to a patch or different version of Jira, or attempt to migrate the database on your own.
    • Atlassian will likely find that the problem is with an add-on vendor and then point you to their support portal.
  • Data conversions with XML backup restore typically doesn't work.
  • Data type conversions are a challenging undertaking, and subject to change over time.

This is why we built our own tool that is highly tuned for the data types and object naming conventions Atlassian uses in their databases.

We support MySQL, Oracle, Microsoft SQL Server, and PostgreSQL.

Managing JIRA at Scale White Paper

See More From These Topics