With the recent news of Atlassian focussing on their Cloud solution, as can be read in our blog, this brings up new opportunities and great benefits. No infrastructure maintenance, application maintenance, upgrades and database maintenance needed. TMC ALM has helped a lot of customers making their first steps in the Atlassian Cloud or with the migration of their server instance to the Atlassian cloud. If you read the Atlassian documentation, you only read the positive side of things. We have experienced that there are also some pitfalls which can be avoided. With this blog, we try to give you an honest overview so you can make the right decision for yourself.

The blog is divided into different topics, so you can pick the ones you would like to read:

• Migrating Content
• Plugins
• User management
• Pricing
• Challenges
• Other
• Roadmap

The scope of this blog are the Atlassian tools Confluence and Jira. We will provide examples on challenges when migrating these two products. We are here to help you with any Cloud related questions or remarks, you can contact us via this link.

Migrating content

To migrate the content, there are actually three possibilities.

1. The built-in Atlassian Migration Assistant
2. A full backup and restore of a complete instance
3. Combination of the first two

Our advice is to always use the assistance of an experienced Atlassian Partner that can offer a custom plan for your individual needs. Atlassian has also introduced the Atlassian Migration Program (AMP) to help you with all the challenges that a migration can pose.

Atlassian is pushing towards the migration assistant. The assistant can migrate users and content by space or project. Your version of Confluence should be fairly recent (5.10) and for Jira, you need at least 7.6.0. This goes for all server deployments. At this point in time, Data Center to Cloud migrations are not supported. If you have a Data Center version, it is possible to restore a backup to a test Server and install the Server version of Jira and do the migration from there. The migration assistant works nicely when you want to merge your data with an existing Cloud instance. All active users will be migrated too. Inactive users will not be migrated and @mentions to an inactive user will not be traceable any more. This is a decision made to comply with the General Data Protection Regulation (GDPR).

The other option, a full backup and restore was the way to go in the past, before the migration assistant existed.

Other scenarios can include the ‘merge’ of an existing Cloud instance with an existing Server instance. Or instances where add-ons are thrown in the mix. Potentially making this a challenging task to perform. As TMC ALM we have experience with these migrations. We are happy to advise in this matter or implement these migrations for you.

Plugins

In general TMC ALM is conservative when applying plugins. The Atlassian tools have limited functionality and plugins have a lot to offer, but there are also downsides. One of them is that the Server version of the Atlassian tool can differ from the Cloud version. Plugins for Cloud can be different than the Server versions. In Cloud, there are fewer possibilities to add functionality for plugins. At TMC ALM we see a lot of investment in Cloud add-on development, so we expect most gaps to be bridged in the (near) future.

Before performing a Server to Cloud migration, research needs to be done for the plugins you really need. We advise checking their compatibility and availability before taking any action. If the add-on is available, we advise to ask TMC ALM or (let us) contact the plugin vendor if a plugin data migration is possible. If the plugin is not available in the Cloud, you can look for an alternative. With an alternative, most likely your current plugin data is (partly) lost.

One of the most common plugins, Automation for Jira, is available for free with limited functionality in the standard plan of the Jira Cloud. You would need to upgrade to the premium plan for extended functionality.

User management

When you migrate to the Atlassian Cloud, all users receive an email to create an Atlassian account and set their password themselves. An Atlassian account can be used on all Atlassian Cloud instances.

It is not possible to do user management with your (Azure) Active Directory out of the box. If you had this on Server, maybe even in combination with a Single Sign-On (SSO) add-on, this functionality is lost. A different Atlassian product, Atlassian Access, is required to use this functionality. But it does support all Cloud products. With Atlassian Access, you can connect a full domain (e.g. @tmc.nl) to your Azure Active Directory and let users authenticate using SSO. Atlassian Access also provides user provisioning and multi-factor authentication. It is not possible to have only a limited number of users within the same domain authenticate using Atlassian Access.

Pricing

When you migrate to the Cloud, having an active Server license entitles you to a free Cloud trial license for the period your service license is active. At the time the Server license expires, you can purchase a Cloud license. This is only available for Atlassian products like Jira Software, Jira Service Desk and Confluence and does not apply to any plugin licenses. These need to be (re)purchased separately.

Since hardware, Server (OS), application, database management and upgrades are done for you the Cloud implementation can be tempting. If you look at the Total Cost of Ownership (TCO), Cloud is typically a smart and more cost-efficient alternative compared to an on-premise deployment. Licensing costs are influenced by the type of Cloud solution you need, either Standard, Premium or Enterprise as well as the add-ons you want to use. TMC ALM is happy to provide you with pricing details for your specific environment.

Challenges

As mentioned, TMC helped many customers to the Cloud. Have we always done so by following the (ideal) path Atlassian described in their documentation? Well, the answer is no. Besides all the subjects already discussed above, there were more (technical) issues.

• The Jira migration assistant could not be used when a kanban/scrum board contains a (quick)filter with a reference to an inactive user or to projects which is not part of the migration. This needs to be solved beforehand.
• Every user should have a unique email address throughout the application. this also needs to be solved beforehand.
• If you have a large instance to migrate with a lot of (big) attachments, then make sure to plan enough time for the data transfer. Do a test migration to get a feeling of how much time you need
• If you migrate Confluence and Jira to the Cloud, they most likely have (partially) the same user base. We came across the problem that the application which was migrated second had references to “null” instead of the user which was already available in Cloud. We solved this by using the full import instead of the migration assistant. Below are two screenshots of real-life scenarios.
  
  

Other

There are also other items you may want to consider before migrating to Cloud:

• Performance can be different from what you are used to. The Server is not in the company any more and page load times can be longer than expected. We have however seen serious performance improvements in the past months.
• The location of the data can be outside of the EU zone for Standard and Premium. If the users are working from Europe for instance, then Atlassian tries to locate the Server in Europe too. Data residency is only available for Enterprise at this point in time.
• Application upgrades are done automatically. This can be very convenient. The downside is that there is no opt-out (only delay when using the Enterprise plan). Users can log in and suddenly new functionality or changed behaviour becomes available. On the other hand, Atlassian chooses often to develop new functionality for Cloud-first, which will become available to Server or Data Center later on.
• Cloud has different functionalities then Server. Most functionalities differ very little but only have minor differences, but we advise you to test beforehand if you are depending on certain functionality.
• Cloud has a different user interface then Server. It is not unsurmountable, but users should be informed to avoid confusion.
• Atlassian is not doing backups for you. If somebody within your organization deletes content, you should have your own backup and restore strategy in place. TMC ALM can help you in prodivind tips, tricks and best practises for this.
• Add-ons availability and feature set may vary
• Tool integration can differ from the Server implementation including the REST API
• 10.000 maximum users

Roadmap

Atlassian is constantly improving its Cloud offering. Curious what’s in the pipeline and Atlassian will be offering: check Atlassian’s Cloud roadmap via this link: https://www.atlassian.com/roadmap/Cloud

Conclusion

Atlassian handles a Cloud-first strategy and is investing a lot in their Cloud proposition. Every day the gap between on-premise and Cloud becomes smaller and there are many benefits in migrating to the cloud. Even though the migration can be challenging in some cases, we at TMC ALM also believe that Cloud is the future for many of our customers. We are here to help you with all your questions and migration challenges, contact us if you have any questions or comments.