If you are an Atlassian Cloud customer utilizing any combination of Jira Core, Jira Software, Jira Service Management or Confluence, you have probably seen numerous benefits that come with the whole package. On the other hand, there are plenty of circumstances where a single Server or a multi-node Data Center setup is the best choice for your business. Some of the most common circumstances include more than 500 active users in your organization, add-ons that are not compatible with Cloud, or SAML/SSO integration requirements. If any of these apply to you, it may be time to move off Atlassian Cloud.
Consider this article, along with Atlassian’s official documentation, as a step-by-step guide for performing your migration.
The first thing you will need to do is decide between Server and Data Center. For a successful migration, you will want to be aware of the differences so you can choose what is right for your organization. Of course, not every Atlassian utilization is the same, and additional factors may play into the decision making process, but these are the things to keep in mind:
Example:
A high availability database server with multi-master replication for both applications
A two node instance for Confluence
A three node instance for Jira
Example:
A database can be hosted with each instance or on a standalone instance with both applications connected to it
A single server instance for Confluence.
A single server instance for Jira
Not sure which version to use? We're happy to help you weigh your options. Just send us a note and we'll get an expert on the phone with you to talk through your Atlassian environment, no strings attached!
No matter which setup you choose, the process of migrating is more or less the same. It is always a good idea to keep up on Atlassian's documentation, though. Russell Wilson has said, "The separation is in the preparation." The Professional Services team here at Contegix knows this is especially true in regards to migrations. Pre-work and practice will always set you up for success.
Always back up your cloud instance. Since the cloud instance is the source, you want to make a backup at every step in the process. You can generate cloud backups every 48 hours. If you need to generate another backup file sooner than 48 hours, you will have to contact Atlassian support.
The latest Jira Cloud releases use a next-gen project along with standard projects. These next-gen projects are not compatible with Jira Data Center or Server. These next-gen projects are not compatible with Server and Data Center. When generating your backup, if there are any next-gen projects in use, it will ask you to move these issues to a standard project. It is prudent to take a backup before moving these issues.
By now, you should have the following in place:
1.A test environment stood up with your preferred application installed Please try to utilize the latest version if possible. If using Jira 7, use the latest version, which is 7.13.2. If using Jira 8, use the latest version, which as of this article, is 8.0.2.
2.A database of your choosing (PostgreSQL and MySQL are preferred)
3.Licensing for your application(s)
4.A backup of your Cloud site downloaded somewhere safe
5.A runbook of everything to be done
6.Depending on export plan for each application, there are a few paths to explore. Jira Cloud has options:
This option is your best bet if you need everything from Jira, projects, attachments, and users. The native import tool in Jira allows you to import upon installation or at your convenience.
*Note: If your backup file is bigger than 2 gigabytes, unzip the backup file, move attachments and logos out, and recompress the backup folder with just the activeobjects.xml and entities.xml files before importing. You can always import the attachments separately.
This is a bit murky, since migrating specific projects from a Server or Data Center instance can happen with add-ons like Project Configurator or Configuration Manager. Unfortunately, these two are not available for Atlassian Cloud.
Moreover, logic would say that you could export the Jira Cloud project directly to your Server or Data Center instance. However, trying that will instantly stop due to version mismatches. Use a temporary instance to do a full migration only to export the desired project(s); you can then import it to your instance.
The other alternative to this would be a CSV export using the Exporter cloud add-on, as it can handle comments in issues as well. You can then use the native CSV importer in Jira to bring in the projects and issues. You will also need to import attachments specific to these projects separately.
Confluence exporting is a bit simpler than Jira. All you need to do is export the spaces you want to an XML file and then use Confluence's native XML importer.
Many times people gloss over UAT when it comes to these type of migrations. Contegix always recommends a UAT period in order for users to try out the test instance, check for any major differences between their existing Cloud instance and the new instance, and find any bugs. UAT is the best time to let us know if there are any issues, so they can be rectified and accounted for when it comes time for the production run.
Once you have installed the test environment, imported your data, put your users go through UAT, and addressed all bugs, it looks like you are ready for the production run.
Announcement banners are useful here so you can inform your users of the impending changes. In order to keep data from your Cloud instance intact, you may want to implement a restricted permission scheme that only allows a select few to browse projects and issues.
Your preferred method of importing is set. Your runbook outlines everything needed to ensure a successful import. You know how to address every bug brought up during UAT.
Use your preferred importing method and import!
Have your users repeat everything they did in UAT to make sure everything is working as expected. In this period, you will also want to be on standby in the event there are new issues to address. Once you have tackled everything, your users can use Jira and Confluence in their normal capacity.