• There are no suggestions because the search field is empty.
CONTACT

Migrating from Atlassian Cloud to Server or Data Center

By Rommel Marquez

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.

Server or Data Center: Which is Right for You?

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:

Consider a Data Center setup if:

  1. Your organization has more than 500 active users
  2. You need 24/7 uptime with minimal downtime (even with version upgrades)

           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

  3. Your organization requires a disaster recovery plan for your Atlassian instances
  4. You require a SAML/SSO solution for security purposes.
  5. You want seamless a integration with Microsoft Active Directory
  6. You want to keep your Atlassian products behind a firewall or a VPN

Consider a Server setup if:

  1. Your organization has less than 500 active users
  2. You want a seamless integration with Microsoft Active Directory
  3. You only need a single server deployment for each product

           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

  4. You want to keep your Atlassian products behind a firewall or a VPN

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!

Making the switch:

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.

Take Backups. Full Stop.

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.

A Note Regarding Next-Gen Projects

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.

ABT: Always Be Testing.

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:

Get my copy

Jira Option 1: Full Jira export

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.

Jira Option 2: Specific projects

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 Cloud

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.

User Acceptance Testing (UAT)

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.

Migration playbook

Ready To Do It Live?

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.

Plan for Downtime

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.

Prepare and Migrate

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!

Post Migration - Hypercare

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.