Migrating to Atlassian Cloud - 10 hard won lessons!

We've migrated several customers to Atlassian's Cloud. Many customers want to have a pure SaaS offering, whereby they do not need to run any systems at all, but simply consume the service. Here are some of the lessons learned.

These customers range from small instances, which can be done relatively quickly, to the merger of multiple server instances with thousands of users within a corporate environment, all moving to a single Cloud instance for Jira and Confluence.

Firstly, Atlassian's Cloud offering is not an identical implementation to Server or DataCenter. It has diverged, and the Apps architecture has major differences. There is data portability between the platforms, but Apps may not have a corresponding equivalent, and the functionality may differ even if one exists. User authentication is different - Atlassian Cloud relies on unique email addresses, there is the concept of Organizations, managed domains, and Atlassian Access if SSO is required - no more LDAP! Also, the user interface is not identical.

In short - a successful migration to Atlassian's cloud needs careful planning and UAT (user acceptance testing). 

In terms of our approach - the "DQ" in BDQ actually stands for Data Quality. In the past, we wrote data quality tools to assist with data migrations, so this is an area we are familiar with. To summarise, you cannot trust the data, until it has been checked and loaded successfully. "It should load, so there is no need to spend time testing" is a phrase invariably followed by "We weren't expecting that!". Also, it is usually the case that migrations need to take place in known, short timescales (e.g. a weekend), so that a system can go live in an orderly fashion. Migrating to Jira Cloud, Confluence Cloud or any other Cloud offering doesn't have to be painful, but plan to succeed.

To make the process as smooth as possible, we like to work in the following way. 

• • First - establish who the team is, and identify collaboration and communication channels.  There is lots of detail in migration projects, various issues will crop up, decisions must be made, and it is important to know who is dealing with it. We will typically establish a Jira project and Confluence space for the project, and potentially a Jira Service Desk instance for UAT testing - see below.
  • Have regular stand up meetings to keep the project moving. It is important to have a decision maker who can decide on matters such as which plugins to remove, how to deal with external users, which projects should be archived/removed, whether users should be de-activated and so on.
  • If there is a large user base for UAT, we may add Jira Service Desk into the equation. This gives us a portal plus a dedicated email address, and a single place to triage feedback and issues.
  • Decide scope. Which instances are going to be migrated? Users, projects, add-ons? How are we going to manage user authentication going forwards? Do our plugins contain data, and is there a migration path? If and when you need to reach out to the userbase, get their feedback into the service desk and collate it.
  • Security should be engaged - they may/will have views on user authentication and data transfer techniques. Do not let unforeseen security policy issues stall your project!
  • Having decided upon the scope, make sure that the team extracting and transferring the data knows exactly how to do this, and what mechanisms to use. We often use a temporary, dedicated, secure AWS instance if the customer has not got their own facilities. 
  • We should now be in a position to do a first trial migration. We add some of our own scripts and tests in at this point to minimise problems. Keep a runbook (Confluence is a good place for this) to record all special steps, and timings, starting from extraction to completion, so we know what is  required to get it over the line.
  • Based on the results of this trial, we may need some more iterations. However - we should be approaching the production of a UAT instance.
  • We strongly recommend UAT testing. I mentioned earlier that the UI has changed a little, Apps will have changed, authentication has changed, and there will almost certainly be a few other things that need dealing with. UAT helps to iron out problems before go-live. Get a sample set of representative users and provide them with a generalised test plan. Get the UAT test results back in via the Jira Service Desk, and feed these results into your run book. Webinars to explain the differences can make a big difference. Communicate!
  • Assuming that problems are known, resolutions tested, timings and transfers understood, we should now be in good shape for the final migration. 
  • Choose a time and execute the final migration, as per the run book. Go live!
  • There's bound to be some post-live questions, so make sure that you are available to give your users some initial support, so that everyone has a great experience.

Finally - communicate! Keep your users and Cloud migration team informed, and you will have a great Cloud experience!

We can help

If you want help migrating to Jira Cloud or Confluence Cloud, please just get in touch.

About BDQ

BDQ is a digital transformation specialist founded in London. We combine great products with highly experienced consultants to help our customers manage tasks, automate work and collaborate more effectively.