• Products
  • Documentation
  • Resources

Reduce your migration downtime

This information applies to both the Jira Cloud Migration Assistant and Confluence Cloud Migration Assistant.

In general, the more data and users you have, the more downtime you can expect when migrating from server to cloud. We can't provide an exact estimation of downtime because it depends on your internet speed, what data you're migrating, and other variables.

We recommend running a test migration to work out how long to expect your migration to take, document the specific processes you’ll need to follow in a runbook, and review to make sure your production downtime is minimal. Remember to factor in any additional time for things like installing or migrating apps, setting up users, QA testing your data, and anything else you’ll need to factor into your migration runbook.

We’ve put together this guide that walks you through some of the key strategies to reduce downtime and complete migration within your desired timeframe.

Clean up your server instance

The more data you migrate, the longer and more complex your migration is likely to be and could affect cloud performance later on. Use your migration as an opportunity to clean up your server instance before running your test migration.

To ensure successful migration of your server data, use cleanup tools such as the Database Integrity Checker (native to Jira Server) and Instance health (available for Confluence and Jira). Learn how to clean up your server instance

Review your Jira data

It’s good practice to archive inactive or completed projects so they don’t clutter your Jira instance. Learn how to archive projects

Review your Confluence data

Consider removing or leaving behind anything that is not being used. This could include specific pages, entire spaces, attachments, macros, or apps. Learn how to gather usage statistics from Confluence

Set your server to read-only

Depending on the migration strategy you choose, your users may no longer need access to your self-hosted instance. If your users add data to migrating pages, spaces, or issues, this data will need to be re-migrated. You will have to do manual cleanup work that increases downtime.

Put your site into read-only mode prior to migrating to prevent your users from making changes during migration. For Confluence Server, work through each space and remove all permissions for anything other than read. There is no explicit "read-only" mode in Jira Server, but you can do it manually by creating a permission scheme that only allows "browse" permission and applying it to all projects.

Update your site-wide banners for Jira and Confluence stating that your site is now read-only during the migration. If you have users continuing to work in server after the migration, be sure to remove this setting after your migration is complete.

Pre-migrate users

If you have a large userbase, we recommend migrating all your users and groups without any spaces or projects first. This can happen while your users are still working in server, as no space or project data will be extracted (meaning no downtime). Then, when you come to migrate spaces or projects later, it will be a faster migration with shorter downtime. Learn more about migrating a large userbase 

Pre-migrate attachments

Migrating attachments is typically the longest part of migration. With the Confluence Cloud Migration Assistant, when you choose what to migrate, you can select attachments only. Breaking your attachment and space data migration into different stages has the following benefits:

  • you can migrate attachments weeks or months ahead of space migration. This is a low-risk process and significantly reduces the time window for the remaining space data migration.

  • when you migrate all space data in a later migration, the migration assistant will recognize any attachments that have already been migrated and skip over these. This saves you a significant amount of migration downtime. The migration assistant will still migrate new attachments, and also remove the links for any attachments that have been deleted. 

We’re working on functionality for the Jira Cloud Migration assistant to migrate attachments only for selected projects. Currently, this feature is available via Atlassian Support

Pre-migration strategies

Jira Cloud Migration Assistant

Confluence Cloud Migration Assistant 

  • Sort projects by “last updated” on the project selection page. This can help you focus on which projects to migrate before others.

  • Migrate archived projects either ahead or after the migration so you don’t increase migration downtime for the active projects that matter to current users.

  • You can choose to migrate all or some of your projects. If you have lots of projects and attachments, you might want to break the migration up by active and inactive (not being used) projects. This will allow you to have smaller downtime windows. It will also minimize the impact of duplicated entities on active projects. Learn how the Jira Cloud Migration Assistant links your data

  • When you choose what to migrate, you can select attachments only. This will only migrate the attachments related to the selected spaces. We recommended that you migrate attachments before migrating other space data. This can help reduce the time window for the remaining space data migration.

  • On the space selection page, filter the list or search for particular spaces that you want to migrate before others.

  • If you have lots of spaces and attachments or you are on Data Center, breaking your migration up into a few smaller migrations will reduce your downtime windows.

Get your users started in cloud

Allowing your users to easily transition to their spaces, pages, and issues in cloud is critical to any migration. Make sure you’ve understood and prepared for all the major changes such as how users will log in, new URLs, changes to apps, and UI differences. 

Depending on your migration strategy, you can apply a site-wide banner in Jira or Confluence to help redirect end users who are still attempting to access your self-hosted instance. Link out to the new cloud site URL so they know where to go. Learn how to get your users started in cloud

To successfully transition your team, think about creating a clear process for collecting feedback and answering questions about the move to cloud such as office hours or a chat room.


Additional Help