How to speed up your Jira migration

Based on our experience with previous migrations, we’ve determined that right now, migrations usually proceed at the speed of 240,000 issues / 24 hours. That’s an estimation and may vary depending on your environment.

Factors that can slow down the migration

• Network quality

• Errors during pre-flight checks

• The number of issues in your projects

• The size of attachments

• The number of workflows and custom fields

• Whether all or only selected users are migrated

What you can do about it

This page explains what you can do to speed up the production migration and make sure that you can fit it into the desired time window, therefore minimizing downtime of potentially business-critical applications.

The tips below are split into changes that can be made early on, right before the migration, and during the migration.

Anytime before the migration

Prepare the source and target environments

When the migration assistant is started, the first step are the pre-flight checks. Many of these checks are related to your source and target environments, and check for example for users with invalid and duplicated email addresses or the right products installed in Cloud. If any pre-flight checks fail, you can’t proceed with the migration until you have fixed the related issues. To ensure that the checks run smoothly on the migration day, check:

• Have you archived any redundant sites or projects?

• Have you cleaned up or fixed any invalid or duplicated users?

• Have you installed all required Cloud products on the destination site?

• Have you set up the correct permissions?

• Do you have the right number of licenses in your Cloud site?

• Do you have a dedicated RDS enabled in your destination site?

Learn how to clean up your server instance before the migration

1-2 days before the migration

Prepare the network

The speed and quality of your internet connection are a big factor in the speed of the migration. To make sure your network is in the optimal state, check:

• Have you ensured that your network connection is stable?

• Have you ensured that no patches are being released during the migration timeframe?

• Have you ensured that no automated backup service or Jira indexing tasks are scheduled during the migration timeframe?

• Have you allowlisted the Jira Cloud Migration Assistant?

Pre-migrate the attachments

Attachments constitute a big chunk of the overall data size in the migration. To reduce the data size during migration, we recommend to pre-load attachments at any point prior to the migration, so that during the migration only the the difference (any edited or added attachments) will be migrated. This has multiple benefits:

• It can reduce the overall migration duration by multiple hours

• It can be done at any convenient point prior to the migration

• It does not cause any downtime

• It can be done simply by creating a migration plan and selecting “Attachments only”

Pre-migrate the users

Pre-migrating the users will save time during project data migration. You will have to eventually migrate the users and groups again, but it will skip the users already migrated and just migrate new ones (if any). This will be much faster. Here’s how to do it:

1. Create a new migration plan before the production migration (for large user bases, preferably 1 day before).

2. Skip projects and select None or Skip in every option except for users.

3. Select All users and groups.

4. Choose either Migrate users and group separately or Preserve group memberships, depending on your approach to user migration. Usually, migrating customers choose to preserve group memberships.

5. Run the migration plan.

Then, when you run the production migration at a later stage, only the differences in your users will be migrated. Note: The migration assistant will show that all users are being migrated, but actually it’s only the differences, which takes much less time.

Pre-run the pre-flight checks

The pre-flight checks are checks run by the Jira Cloud Migration Assistant to ensure that both environments are ready for the migration. These checks can run for multiple hours, and in a situation where every hour counts, reducing the overall migration time by even a few hours can make a difference. Therefore we advise to run the pre-flight checks at least one day before the production migration.

It is difficult to estimate how long the pre-flight checks will run for an individual migration. We recommend that if the pre-flight checks run for significantly more than 2 hours, you should check in with the Atlassian Support to see if the migration might be stuck.

Disabling some of the pre-flight checks

If you’d like to save extra time, we have dark features that let you disable some of the pre-flight checks. Disabling the pre-flight checks doesn’t eliminate the errors, so you’d have to be sure that your data is fully tested before the migration.

To learn more, consult your Cloud Migrations Manager on how to use these dark features and what are the potential risks.

When migrating

Migrate “All” instead of “Selected” users

Often, users are tempted to choose the option to migrate only users connected to the projects they’re migrating instead of all users. They see it as a simple way of cleaning up their user base and not take inactive or redundant users to Cloud.

However, if migration speed is of the essence, migrating all users is much faster than selected users. This may seem counter-intuitive, as selected users are usually a significantly lower number than all users.

However, when migrating selected users, Jira Cloud Migration Assistant needs to run every single time through the entire user database to identify whether this user is connected to any of the migrated projects or not, and this process take a significantly longer time than just migrating everyone.