Taking the first steps with your Atlassian Cloud migration

Scrubbing up your server might include running scripts and negotiating with stakeholders about migration. For complex data that will take time to migrate, ensure you have 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.

Once you’ve ticked everything off, it’s time to take your instance for a test drive. A test migration is recommended, regardless of your migration complexity or number of users. 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.

Some things to include in your internal communications:

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.