Is Zero Downtime Atlassian Cloud Migration A Myth?

The migration journey to Atlassian cloud is not rocket science, although it may come with its fair share of concerns for users. Those wondering about migration issues should know that making the switch does help. From lower workloads and more agility to better remote work and mobility (not to mention the cost savings), there are numerous advantages of these shifts. Yet, a few myths continue to prevail, which often hinder objective decision-making.  

General Myths about Atlassian Cloud Migration  

Some of these myths include the following:  

• The server and cloud are the same.  
• It is safer to keep data on the premises rather than the cloud.  
• The management of on-premise applications is more cost-effective than the cloud.  
• Big enterprises do not really use the cloud.  
• Production migration requires massive work.  
• Companies do not have to undertake cleanup before shifting to the cloud.  
• Apps are not available in the cloud and do not migrate to the same.  
• Migration does not offer flexibility as per organizational requirements.  
• Cloud migration cannot be tackled by the organization due to downtime and other issues.  

While these are myths that need to be busted once and for all, why shift to Atlassian Cloud in the first place? Here are some reasons that may merit the switch.

Reasons for Atlassian Cloud Migration 

Some of the key reasons include:  

• Enterprises with distributed teams across multiple time zones and locations.  
• Those using multiple apps that have integrations with other applications.  
• Those desirous of enhanced security as compared to the conventional data center/server framework.  
• Enterprises are seeking cost savings on servers, efficiency, performance, compliance, and scalability above all else.  

But what about downtime? Is zero downtime possible? Let’s take a closer look. 

Downtime While Migrating to Atlassian Cloud 

Keeping an eye on the downtime is necessary while migrating to Atlassian cloud. While this is important, knowing more about the concept of downtime is essential. It is the amount of time or time-frame for which the production server stays unavailable for your end-users. To put it simply, the disruption time in service is known as downtime in most scenarios.  

Is zero downtime a myth? Not at all, if you’re in the right hands.  

You can choose time-tested expertise in migrating Atlassian products like Jira Service Management, Jira, Confluence, Bitbucket, and others to Atlassian Cloud without complications. Expert teams will assess your present setup and give you an accurate assessment before migration is done with zero or minimal downtime.  

The process involves the following steps:  

• Evaluation by cloud migration experts, covering applications, present setup, data volumes, integrations, etc. Optimization is the core focus, with identification of duplicate user-profiles and apps that are redundant.  
• Impact study conducted by experts while listing out risk elements, if any are present.  
• An expected migration blueprint with timelines along with apps that will be migrated, integrations necessary, license optimization, and clean-up of data.  
• Implementation- The environment is prepared for successfully migrating to Atlassian Cloud based on requirements.  
• Dummy data is leveraged for a dry run to see whether there are any issues. If some crop up, they are fixed before another dry run.  
• Migration is executed along with final testing by experts.  
• Formal UAT is done by customers while reporting any issues. Once these are listed, they are fixed swiftly.  
• The migration is fully completed with Atlassian training and support solutions provided as required.  

Steps to Lower Migration Downtime 

While zero downtime is possible, there are a few steps that can also be taken to lower any negligible downtime that may otherwise crop up.  

Here are the steps worth following in this regard:  

• Running a test migration- This will help determine the length of time that the migration process will take and help document the procedures required to be followed in the in the runbook. 

You can review the same to ensure that your downtime is as low as possible. You should always account extra time for migrating and installing apps, data QA testing, setting up users, and other things contained in the runbook.  

• Cleaning up the Server Instance- The higher your volume of data for migration, the more complicated and longer your process in most cases. Cleaning up the Server Instance just prior to the test migration can help you ensure a smoother procedure along with lower issues in terms of performance.  
• Setting the Server to Read-Only-Based on your preferred migration blueprint, you may not need self-hosted instance access anymore. In case data is added to migrating pages by your users or there are other issues, then the same will require re-migration. Hence, this will lead to higher downtime on account of manual clean-up tasks. 

You should put the site into the read-only mode before migration. This will prevent any changes made by users during the process. You should remove permissions for things other than reading and check every space for the Confluence Server. In the case of Jira Servers, you should manually create a permission mode which enables just browse and applies the same for every project. Make sure you update banners for Confluence and Jira across the site, mentioning that the site is just read-only during its migration process. 

• Pre-Migrating Your Users- For those with a substantial base of users, all groups and users should be migrated minus any projects or spaces initially. It may be done while users are working in Server, meaning that there will be no downtime on account of exporting project or space data. This will ensure swifter migration with lower downtime when you come back for the migration of projects or spaces.  
• Pre-Migrate Attachments- These usually take up the biggest chunk of the entire migration procedure. You can choose Attachments only while selecting what you wish to migrate in the dedicated Migration Assistants option. This will only migrate attachments for the chosen spaces or projects.   

This helps by migrating attachments well in advance of space or project migration. It has lower risks and reduces downtime for the rest of the project/space data migration procedure. When you migrate later, the assistants will identify attachments that are already migrated and skip the same. This will save you downtime considerably.  

Achieve Zero Downtime with a Certified Atlassian Partner 

As can be seen, zero downtime is no longer a myth, provided you go with a Certified Atlassian Partner. Simultaneously, overall downtime, if it arises, can still be negated with a few smart steps. You should have a firm grasp over aspects including app changes, differences related to UI, newer URLs and login changes for users.  

Applying a site-wide banner may work in Confluence or Jira for redirecting those end-users still trying to access the self-hosted instance. A link should be provided to the new site for users. You should have a clear strategy to set up users and help them get started in the Cloud after the migration process. Simultaneously, you will also have to get the team transitioning effectively to Atlassian Cloud. Make sure that a system of gathering input and feedback is implemented with swift resolutions and decision-making. A little persistence and innovation will help you sail through the entire migration process without major difficulties.