Strategies for migrating from Atlassian Server to Atlassian Cloud

When planning a move from Atlassian Server to Atlassian Cloud, one of the key considerations is deciding the right migration strategy to adopt. Organisations can run into huge problems when beginning a project without the due diligence and analysis to determine the correct migration approach. 

There’s no one-size-fits-all solution, and the right choice will depend on your specific business goals and scenarios. In this blog post, we’ve outlined the various migration strategies at your disposal to help you ensure best business value at the lowest possible cost and risk.

As the name suggests, this is an “all at once” migration where you migrate an entire data set to Atlassian Cloud in a single migration window, involving a predetermined downtime. You will first need to carry out an in-depth analysis of which data set to leave behind on your server instance, and which to move to Cloud. 

It is key to evaluate whether it makes sense to migrate all of your legacy application data to the new system. Take the time to really understand what data can be reused and what changes to the data might be needed. This will help you ensure that your instances are tidy and eliminate hidden legacy data challenges. 

For instance, you should avoid transferring unused workflows, custom fields in Jira, unused pages in Confluence etc. to the new system if you’re looking to minimise the risk and cost associated with the migration effort. Once a thorough evaluation is done, you can effectively switch over to the new environment immediately.

As daunting as it may sound, this approach can be quite effective in some cases. If your environment is reasonably small – say fewer than 5,000 users and 10 apps – then big bang might be the best approach. Your project can be completed faster, ensuring reduced migration downtime.

However, the main issues with this approach start to occur when the instances to be migrated are complex, users are numerous, there is a vast amount of data to consider etc. In such scenarios, a big bang approach would likely be unmanageable, demand a huge number of engineering resources, and cause a lot of problems.

A phased approach tackles the migration of data from the Server environment to Atlassian Cloud in clearly defined stages – rather than all at once.​ Each increment or update of the new environment undergoes testing to identify and resolve bugs before the next phase occurs.

If going this route, consider breaking it down by team or business unit and migrating them to Atlassian Cloud one by one. You can start by migrating minimal essential data to the new environment first, working out any issues or challenges and onboarding new users in each stage. 

As teams switch over to the new system, you need to identify the remaining legacy data that might be required for governance purposes, and store it in a format such as CSV that could be easily imported if needed.

For large-scale or complex Server instances, a phased approach is unquestionably the recommended strategy for migration. Small changes done over stages allow everyone in your team to get comfortable with the new system gradually, with the least amount of confusion and/or risk. You can identify issues and resolve them before they affect more areas of your organisation. The information that you learn from the initial phases can make the subsequent ones easier and smoother.

However, the outcome of a phased approach is eventually an extended migration period. The implication for a staggered timeline is higher cost of migration, greater efforts, and potential loss in business, if not planned well.

Also, it can be more complex to effectively manage the running of two systems in tandem during the transition, until the entire migration is complete.

This approach is used when you’re starting fresh and/or with no restrictions or dependencies on existing Server data. 

For instance, if you use Jira Service Management and are confident that you no longer require access to old tickets, you can opt for this method. Similarly, when you are spinning up a new team, this method can be a superb choice. 

The obvious advantage is that you get a chance to migrate to the new cloud environment immediately. It offers you a clean slate to streamline your migration to Atlassian Cloud since there is no compulsion to work within the constraints of existing systems or processes. However, if you still need access to old project/space data, this approach isn’t viable.