• Products
  • Documentation
  • Resources

Reduce your migration downtime

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 your migration may take, document the specific processes you’ll need to follow in a runbook, and review these 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’ve included your migration runbook.

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

Clean up your Server instance

The more data you need to migrate, the longer and more complex your migration can become. Cleaning up your Server instance before running a test migration can result in a smoother migration, fewer performance issues, and productivity gains in the Cloud. Learn how to clean up your Server instance before migration

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. For Jira Server, there is no explicit "read-only" mode, 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 exported (meaning no downtime). This will enable a faster migration with shorter downtime when you return to migrate spaces or projects later. Learn more about migrating a large userbase

Pre-migrate attachments

Migrating attachments is typically the longest part of migration. When you choose what to migrate in the Migration Assistants, you can select Attachments only. This will migrate the attachments related to the projects or spaces you select only. Breaking your attachment and project/space data migration into different stages has the following benefits:

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

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

Jira Cloud Migration Assistant

Confluence Cloud Migration Assistant 

When you choose your migration options, select Projects, then choose Attachments only:

Attachments only for selected projects

When you choose what to migrate, select Migrate attachments only:

Attachments only for selected spaces

Pre-migration strategies

Jira Cloud Migration Assistant

Confluence Cloud Migration Assistant 

  • Sort projects by Last updated on the project selection screen. 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.

  • Use filters to locate inactive projects on the project selection screen. You can show projects that haven’t been updated in the last 30 or 90 days.

  • 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

  • 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're 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. Provide a link to the new Cloud site so they know where to go. Learn how to get your users started in Cloud after migrating

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.

More information and support

We have a number of channels available to help you with your migration:

Additional Help