Reduce your migration downtime

In general, the more data and users you have, the more downtime you can expect when migrating from Server or Data Center 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’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.

Run a test migration

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. Learn more about test migrations

Clean up your instance

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

Set user permissions to read-only

Depending on the migration strategy you choose, your users may no longer need access to your Server or Data Center 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, work through each space and remove all permissions for anything other than read. For Jira, 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. Learn more about permission schemes

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 or Data Center after the migration, be sure to remove this setting after your migration is complete.

Learn how to add a banner in Jira

Learn how to add a banner in Confluence

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 or Data Center, 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 how to migrate Jira users in advance

Learn how to migrate Confluence users in advance

Pre-migrate attachments

Migrating attachments is typically the longest part of the 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 or space data migration into different stages has the following benefits:

You can migrate attachments weeks or months ahead of the project or space migration. This is a low-risk process and significantly reduces the time window for the remaining project or space data migration.
When you migrate all project or 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.

We recommend that you migrate attachments before migrating other project or space data. This is because if you migrate attachments after migrating project or space, some attachments may not link correctly on the cloud because the system requires you to have the media on the cloud before your project or space data. To ensure you don't lose any attachments or media data, we strongly recommend you migrate your attachments as a pre-migration task.

Jira Cloud Migration Assistant	Confluence Cloud Migration Assistant
When you choose your migration options, select Projects, then choose Attachments only:	When you choose what to migrate, select Attachments only:

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.	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.

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.

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:

for migration planning information, visit the Atlassian Migration Program website
for technical issues or support with strategy and best practices, get in touch with our support team
for peer advice, ask the Atlassian Community
for expert guidance, work with an Atlassian Partner

Was this helpful?

It wasn't accurate

It wasn't clear

It wasn't relevant

Still need help?

The Atlassian Community is here for you.

Ask the Community