A must read for Atlassian Cloud to Server migrations (and vice versa)

Often companies start with Atlassian Cloud because it's cheap, it's easy and simple to set up, no hardware is needed and maintenance (both for the application and the environment) is handled by Atlassian. However, at some point, these applications (like Jira and Confluence) start to spread with more teams adopting the tooling and new requirements needing to be met. 

To name a few example requirements:

• Specific functionality is needed that is only available through customization (or Marketplace Apps that are unavailable in Cloud)
• Advanced U
• user management needs to be done via Active Directory (a centralized, multi-application user directory)
• Access to the applications needs to go through the company's network or VPN
• Data needs to be stored on self-managed hardware because of compliance/regulatory issues
• A customized domain name is needed (other than xxxxxxx.atlassian.net)

I would invite you to find out more about the pros and cons of Cloud and Server here, in order to make sure you can make an informed decision. If you are still unsure about what's best for your organization, feel free to contact us.

In any case, you should be aware that Atlassian Cloud and Server products are completely different from a technical point of view. One of the biggest consequences of this, is that Marketplace Apps are often only available for one of the platforms. But even when they are available for both Cloud and Server, they can offer different features and they can be very different in the way they work. 

Atlassian Marketplace Apps

As stated above, there are significant differences in Marketplace Apps for the Cloud and Server platforms. For the On-Premise (Server) installations, App developers are able to make use of the internal Java API. This allows Apps to make customizations in the look and feel for example, but also to native Jira features. This can be very beneficial, but also introduces some level of risk. On the other hand, when Atlassian hosts the products for you (Cloud), Marketplace Apps can only make use of the standard (connectivity) endpoints Atlassian offers, limiting the extent of possible customizations. Another considerable difference is that the Apps themselves are hosted on a separate platform (under the App developers' responsibility), possibly in a different region, which can have compliance and/or security implications.

Jira Cloud App Architecture

Jira Server Architecture

Additionally, because Marketplace Apps are not allowed to use the same infrastructure as the product for which they provide the extra functionality, the data is stored separately and it is this that fact often leads to difficulties during migrations from the Cloud to an On-Premise environment.

How does data storage work for Server installations?

Unlike Cloud Apps, Server Apps store most of the data in the same database as the product itself - in AO (Active Objects) tables.

An example of local tables that Marketplace App Tempo Timesheet uses to store their data.

Understanding that data storage differs between Server and Cloud, that Atlassian does not allow Apps to do it the same way on both platforms, brings us closer to understanding why migrations between the two platforms can become difficult when Apps are involved. This is a rather serious issue as it can result in data loss when migrating from Cloud to Server or vice versa. 

The migration

A migration between Cloud and Server should always start with a backup. Creating a backup of your data and moving it between the platforms is no rocket science.

Atlassian's documentation is quite good, so be sure to follow the instructions carefully. Do note that before migrating, the Server instance should probably be updated to the latest version.

What is this, I don't even?

Something to keep in mind when moving from one platform to the other is that the look and feel can be different and there could even be features that are available on the platform but not on the other (yet, perhaps).

Here's an example: When mentioning an Issue key in comments on JIRA Server, show the status next to the key - like in JIRA Cloud (https://jira.atlassian.com/browse/JSWSERVER-16104)

It's not that Cloud is always ahead of Server though, jira.atlassian.com's #1 voted feature, priority schemes for projects, has been shipped for Server in November 2017 but is still not available for Cloud (https://jira.atlassian.com/browse/JRACLOUD-3821).

 

These kinds of differences may mean you will need to provide information to your users... For example, it could be that some buttons are located elsewhere.

The migration of Apps

Below is a list of 8 popular Apps and some of the issues we've faced with them during migrations.

1. Tempo Timesheets

Tempo actually states on their website that a migration between the platforms is something they don't support, see this article. 

However, when migrating to Server, mostly Tempo Teams are migrated. You might see that some teams are missing or your teams miss some members. The biggest issue here is that, if you're using Tempo Teams as a custom field in issues as well, all of your issues are probably linked to the wrong Tempo Team...

The same applies to Tempo Accounts. Tempo offers to export/import accounts, see this article, but again, after the import all accounts could be linked to the wrong projects and to the wrong issue.

The workaround here is to export all of your issues using Teams and/or Accounts to CSV using the issue navigator on your source platform and to import these on your target platform. When you're mentioning the issue key and summary in your columns, it will simply update all of your

issues.

This also applies when doing an XML backup/restore between Server installations.

For worklogs, it's a different story. Tempo used to make use of the Jira API to write back worklogs to Jira itself, nowadays they're actually saving this data elsewhere which results in most of your logs being written to a newly created user "Timesheets".

To fix this, we're making use of Tempo Cloud's REST API to fetch the worklogs of users, insert them via Jira's Server REST API and to remove the worklog from the user Timesheets. 

2. Tempo Planner

Cannot be migrated between the platforms

3. Tempo Budgets

Not available for Cloud

4. Insight - Asset management

Not yet available for Cloud

5. Jira Suite Utilities (JSU)

This is a special one. Atlassian actually offers all the features from Jira Suite Utilities on Cloud as native features (extra postfunctions, conditions and validators), hence why they're not listed as Cloud App. If you migrate to a Server installation, it's likely you'll have to purchase (yes, it's even a commercial App) it and you'll have to re-configure many of your postfunctions, validators and conditions.

6. Jira Misc Workflow Extensions (JMWE)

Again, for this App you'll have to re-configure your conditions, validators and postfunctions but also be aware that the same postfunctions, are configured different on both platforms.

Example on Cloud

Example on Server

7. Zephyr

Cannot be migrated between platforms and no API available to fix it manually which results in a loss of test cycles and results. 

8. Script Runner

Scripts need to be rewritten.

Since there are 3000+ apps in the Marketplace it's impossible to list them all, contact us to help you investigate your currently used apps to check if they're compatible on both platforms and if there are migration possibilities.

I don't want Atlassian Cloud but I don't want to host it myself either...

There are plenty of Atlassian Partners, like us, that offer secure, full-service managed hosting solutions. Avisi offers Atlassian applications as a service which allows for a wider selection of Atlassian Marketplace Apps, custom domain names, integrations and so forth. We can also take care of a migration from Server or Cloud to our managed hosted solution for you!