Skip to main content

4 min read

Taking the first steps with your Atlassian Cloud migration

Cloud migration
alert2 Icon
The content of this blog is no longer updated

If you’ve decided to make the switch from Atlassian Server to Atlassian Cloud, you might be feeling a little overwhelmed. It’s a big change and one that requires significant assessment, planning, preparation, and testing, all before migration even takes place. 

No move to Atlassian Cloud is the same, and it’s not always a linear process. One of the key considerations is choosing a migration strategy – either a big-bang, phased, or start-fresh approach. But once you know how you plan to migrate, it’s important to take your time, engage experts (an experienced Atlassian Solution Partner is ideal), and have solid foundations before you take the next steps. 

In this blog, we talk you through three big building blocks of migration: cleaning up your instance, testing, and communication, setting you on a successful path to Cloud.

copy_text Icon

Keep it clean

Just like moving house, migration gives you the opportunity to deep clean and declutter. You should see it as a positive that you get to evaluate your existing data. Don’t just think about volume – sure, the more data you migrate, the longer your migration will take – but it’s important to assess the value of what you’re bringing with you. Cleaning up your server instance in advance will make moving easier and ensure you have better performance and productivity once migration is complete.

Scrubbing up your server might include running scripts and negotiating with stakeholders about migration. For complex data that will take time to migrate, make sure you’re having these conversations well in advance, giving you ample time to put a plan in place. This is all part of establishing a confident comms approach to migration (see below), so you get in the habit of updating teams about how they will be affected as things progress. You might choose to delete all of your data and migrate only configuration and empty project containers too, giving you a clean slate.

Your Jira clean-up should include:

  • Fixing duplicate email addresses
  • Checking for any conflicts with group names
  • Removing unused apps or trial data
  • Identifying and removing unused projects and issues
  • Reducing data size and complexity where possible, including number of projects, custom fields, workflows, screens, users, and inactive users
  • Standardising any custom workflows to keep data complexity to a minimum
  • Reviewing any groups and permission schemes to figure out where you can simplify them

Your Confluence clean-up should include:

  • Removing any unused apps or trial data
  • Assessing what temporary pages, spaces, attachments, macros, or apps can be left behind
  • Testing larger spaces that have lots of comments or attachments
  • Minimising customisations
copy_text Icon

Time to test

Before you run your test migration, it’s a good idea to go through a pre-migration checklist, making sure your data and environment are prepped and ready. Atlassian has one for Jira here and Confluence here. 

Once you’ve ticked everything off, it’s time to take your instance for a test drive. A test migration is recommended, no matter your migration complexity or how many users you have. This phase will help you uncover any problems, understand how long migration will take, and get a migration runbook ready to go. There are three key tasks:


Whether you’re doing a big-bang or phased approach, you should back up your self-hosted instance before migration. If you have any cloud-site data already, you’ll want to back this up too. For Jira, there are two main options for backing up your database: using native database backup tools or using Jira’s XML backup utility. Atlassian recommends the former, because with XML backups aren’t guaranteed to be consistent, and Jira won’t report any warnings or error messages. For Confluence, you need a clear strategy to back up your database, install directory, and home directories using the tool of your choice. 


User acceptance testing (UAT) is a big part of your test migration. It lets your users recreate everyday tasks to make sure your cloud instance will work the way they expect. It will uncover issues that affect end users that you wouldn’t be able to spot otherwise. Pick testers from each team that will be moving to your cloud site, and get a good range of users, including less frequent ones. Make sure your testers can provide clear, constructive feedback, and that people from every major role are included.

Some general things to test include: links to other content, app links to other server products, apps or app data, and integrations with other products. For Jira, check your workflows, including any functions that rely on third-party apps, and try creating a new project, creating and editing issues, and uploading attachments. And in Confluence, get users to test that attachments are in place, and that apps and associated data are working too. 

Take screenshots and keep track of any changes your users experience – from new features and the user interface to changing bookmarks and user administration changes – it will help with communicating changes during and after migration.


The testing phase is also when you put together a step-by-step checklist, or runbook, that outlines everything that needs to happen during migration with associated instructions. It includes information like who owns each task, how long every task will take, and any dependencies that could hold things up. And as much as you hope not to need it, no runbook is complete without a mitigation plan just in case you need to roll everything back.

copy_text Icon

Get the word out

Any migration lives and dies by how the whole process is communicated to the people it impacts. From planning and prepping through to testing and migrating, it’s vital the right people are consulted and kept in the loop about how their work will be impacted at every stage. Once you’ve got timelines and task owners sorted, let everyone know what’s going to happen and when. 

Some things to include in your internal communications:

  • Migration timelines, including any downtime
  • The new site URL and sign-in instructions
  • Request that users avoid making any changes during the migration phase
  • Explain what will happen to the old site – what will people be able to access, if anything?
  • Contact information for user support
  • Any onboarding materials to help them get up to speed

Even with UAT, there will be issues that arise. Don’t be afraid to let users know, but give them an adjustment window so they have an end-point in mind. Keep everyone up to date about the upcoming migration with site-wide banners in Jira or Confluence. Most importantly, having a clear process for user feedback and support, both in advance and after migration, will help smooth the transition.

copy_text Icon

Make a move

As an experienced Atlassian Solution Partner, Adaptavist’s expert team is here to help make your move to cloud as smooth as possible. From selecting a migration model to suit your organisation and preparing your instance for the big move to working with your people to test that everything’s working as it should and holding your hand through migration itself.

To find out more about Atlassian Cloud migration, get in touch.

copy_text Icon