How to speed up your Jira migration

Based on our experience with previous migrations, we’ve determined that right now, the max throughput of Jira Cloud Migration Assistant is 3,700,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 number of 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 your 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.

General recommendations

Here are general recommendations:

Review hardware requirements and allocate CPU resources

This recommendation applies to large instances, with over 500 users. The migration speed for smaller instances shouldn’t cause a very long downtime, but you can still use this information to improve it.

Review the hardware and sizing requirements. Meeting them makes sure that your migration speed is optimal. In general, we recommend a minimum of 16 CPUs for each node. Adding additional nodes (for Data Center) and additional CPUs will increase the speed further.

Jira sizing guide

Jira Data Center infrastructure recommendations

AWS infrastructure for migration

If you require testing or setting up an environment for the migration using AWS, consider the following recommendations. This will accommodate more than 1 million issues.

CPUs and project parallelism

The number of CPUs control how many projects we can migrate in parallel, that’s why we recommend to have at least 16 CPUs. If you add more, we’ll allocate them dynamically to migrate projects or issues to achieve the best performance.

In some cases, users allocate fewer CPUs for their test migrations than they would for the production ones. If you’re looking to just measure the migration time, bear in mind that with fewer CPUs, your test migration will be slower than the actual one later on.

How we allocate CPUs?

The table below illustrates our approach to utilizing all CPU cores to enhance the speed by processing data in parallel. While some numbers may vary based on the number of projects in a plan, we ensure that the thread count doesn’t exceed the available CPU cores (except the first scenario).

Network recommendations

We don’t have strict requirements for bandwidth, but we’ve observed that 250 Mbps improves the data upload, attachment upload, and communication between server and cloud, resulting in overall faster migration.

Update the migration assistant

We constantly release improvements to migration speed, that’s why it’s important to always update the assistant. For example, in version 1.10.17, we released improvements that significantly increase the data throughput. You couldn’t use these changes if you migrated on an earlier version.

When updating the assistant, make sure that the new version is compatible with your current versions of Jira, database, and any apps you’re using.

Disable non-essential tasks on the server

When running the migration, disable all tasks and activities that might consume additional resources, such as:

• Antivirus scan

• Taking Jira backups (XML)

• Full reindexing

• Automation or apps that might be updating issues in bulk

• Other non-essential tasks

As much as possible, keep the resources available to the migration only.

Run the migration in low-traffic or off-hours

Schedule and run the migration during off-house to reduce the server and network traffic. This also allows your IT team to focus solely on the migration and be available when any problems arise.

Best practices for creating and running migration plans

We’ve observed that the following best practices significantly improve the migration speed:

• Don’t run multiple migration plans at the same time.

• Projects within a migration plan are migrated in parallel. For faster migrations, we recommend that you include multiple projects with similar issue count in a single plan. Typically, the total migration time equals the time it takes to migrate the largest project.

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

Learn how to migrate Jira attachments in advance

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 a summary of 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.

Learn how to migrate Jira users and groups in advance

Pre-run the pre-migration checks

The pre-migration 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-migration checks at least one day before the production migration.

It’s difficult to estimate how long the pre-migration checks will run for an individual migration. We recommend that you should check in with the Atlassian Support if the pre-flight is running for a significant amount of time, for example:

• Small instances: Over 2 hours

• Medium instances: Over 4 hours

• Large instances: Over 6 hours. In this case, it’s common for pre-flights to take time to complete.

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.