Strategies for migrating from Atlassian Server to Atlassian Cloud

Evaluating whether it makes sense to migrate all of your legacy application data to the new system is key. 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 sometimes be quite effective. 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.

If you go 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 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 can 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, a phased approach results in an extended migration period. A staggered timeline implies a higher migration cost, greater efforts, and potential business loss 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.

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, this approach isn't viable if you still need access to old project/space data.