Migrate all data at once

The 'Migrate all data at once' option is available in the Jira Cloud Migration Assistant (JCMA), versions 1.9.0 and later, for customers who want to migrate core product data and app data.

This feature may also be referred to as 'Bulk migration'.

Key benefits

Compared to the original Project-by-Project migration method of JCMA, the 'Migrate all data at once' feature of bulk migration:

• supports larger volumes of data migration to cloud
• migrates faster than previous versions of JCMA

The higher migration speed of this feature is made possible by using a direct import method on the cloud site, and makes larger migrations more viable for customers by considerably reducing the downtime required for migration.

Apps with existing automated migration paths in JCMA

A key focus of this feature has been to ensure compatibility with our Marketplace Partner’s existing investments into building automated migration paths for JCMA. As a result, we have designed the 'Migrate all data at once' feature to work in a way that's broadly transparent to your existing migration path.

This means that Marketplace Partners can use the same migration paths for 'Migrate all data at once' migrations, as was used by the original the Project-by-Project migration method.

How Migrate all data at once works

Functionally, a bulk migration using the 'Migrate all data at once' feature follows the same structure and has the same resources available to Marketplace Partners, as exists with the original Project-by-Project migration method.

• All Jira projects will be migrated, and containers representing each project will be available when calling the /container/{transferId}/page endpoint (API Reference)
• The listener-triggered webhook event which indicates the start of a transfer will be sent as normal.
• Mappings for all entities via both the /mapping/{transferId}/page and /mapping/{transferId}/find API endpoints will be available as normal (API reference). See the complete list of supported mappings here
• A new recent transfer will be available for polling reliant apps via the /transfer/recent as normal (API reference)
• The server-side listener is triggered, as it is with Project-by-Project method
• No changes are made to the:
  • duration/lifetime of a migration transfer.
  • progress reporting (API Reference).
  • pre-migration flow.

Triggering an 'Migrate all data at once' bulk migration can only be done to an empty cloud site, and the content is considered a replacement for any site that existed at that path in the past. As a result:

• apps required for the migration will be re-installed as a preparation step of "Migrate all data at once"
• no uninstall lifecycle event is currently sent when the site is prepped for the migration
• no license changes are made as part of this operation
• the reinstallation will be treated as a new installation that will have a new unique cloud key. You can find (more information here).

Re-installation

As the 'Migrate all data at once' bulk migration requires a blank site, all Marketplace Partner apps will have to be re-installed as part of the migration process. This will happen as part of a migration stage before a Marketplace Partner’s app is notified of a new transfer.

It is important to note that you will not receive an uninstall event as part of this process.

Your app should also be ready to handle multiple installation events via Atlassian’s Connect framework. Also, the license for your app will remain untouched.

Read more about why this is treated as a new install

Interoperability with the Project-by-Project method

As the bulk migration of the 'Migrate all data at once' feature requires a blank site, it can only support the initial migration a customer performs.

Customers can also:

• perform another bulk migration by first deleting their previously migrated data in the cloud site, and starting again.
• run a bulk migration, and then run multiple Project-by-Project migrations afterwards, overwriting the data in cloud.
  • Subsequent Project-by-Project migrations would result in new mappings being created that will have new IDs, and the continuation of the same ID being used on the server and cloud would be lost at this point.

Comparison with Site Import

The 'Site Import' feature uses the same direct import process as the 'Migrate all data at once' feature. However, some of the limitations of Site Import are that it:

• is an external tool to JCMA. This means that customers typically need to combine a range of approaches and tools migrate successfully.
• does not support the migration of users & groups, apps, and other features that JCMA supports.
• does not benefit from the increasing series of pre-migration checks, data corrections, and other improvements that Atlassian provides for JCMA.

As with Site Import, the 'Migrate all data at once' feature cannot migrate to a cloud site if it already contains data.

Consistent IDs between server & cloud

Currently, bulk migrations will carry over the server ID for nearly all entity types. However, this is not a contractual attribute and is subject to change in the future based on other requirements.

We expect customers in the short term to be able to use Site Import tooling where it already exists, rather than the JCMA path. However, this will cease to be possible in the future, and it is recommended that all Marketplace Partners prepare their automated migration paths to ensure that it works with this new 'Migrate all data at one' bulk migration method.

Testing

Read more about how to run a 'Migrate all data at once' bulk migration with app support

Support

Check out cloud migration methods for more information about different cloud migration methods supported by Atlassian or visit our support page.