Changelog

The App Migration Platform is adding support for sending transfer-settled event for Connect and Forge platforms when a transfer gets settled.

Additionally for Forge migrations, the listener-errored event payload will include additional details of the transfer error that occurred, such as the type of exception and stack trace to facilitate easier debugging.

From Sep 6, 2024 , the App Migration Platform can handle Forge App Migrations originated from P2 plugins (server/data center)

Please check our updated docs. And in case you have previous experience with P2 to Atlassian Connect migrations, we have a special page highlighting the differences between the two.

We've removed the deprecated ‘Migrate all data at once’ option from the Jira Cloud Migration Assistant (JCMA).

This change was made to better meet the needs of large and complex migrations. The feature was a monolithic solution with technical limitations that prevented it from scaling to meet the needs of enterprises (those with more than 100,000 users).

There are no actions developers need to take in response to this change.

For more details, see the March 25, 2024 deprecation notice.

The App migration platform has updated its maximum file size limit to 25 GB, rectifying an error in the platform's documentation that previously indicated a limit of 50 GB.

Starting from CCMA 3.9.17 and JCMA 1.11.12, all App Migrations will use accelerated transfers if the new endpoints are reachable.

Depending on the global region in which the App Migrations are being executed, this new feature can translate to up to 5x faster data uploads.

To ensure maximum impact, customers are advised to review their firewall policies according to this page.

Starting from Jun 1, 2024 , the send migration progress endpoint will reject requests containing more than 65,536 characters on the message field.

Starting from JCMA 1.11.0 and CCMA 3.9.6, you can programmatically retrieve the progress of an app migration.

For more information, see Retrieve migration progress

On September 1, 2024, we’re removing the option to migrate all data at once from the Jira Cloud Migration Assistant (JCMA). Until then, we’ll continue to support and maintain the feature’s current functionality.

We’re making this change to better meet the needs of large and complex migrations. The migrate all data at once feature is a monolithic solution with technical limitations that prevent it from scaling to meet the needs of enterprises (those with more than 100,000 users).

There are no actions developers need to take in response to this change. Automated migration paths work the same whether using project-by-project or migrate all data at once.

For more information, see Discontinuing 'Migrate-All-At-Once' Option in JCMA - Quick Reference Guide on the Partner Portal.

A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-43-migrating-app-custom-field-types/78580.

We’ve removed support for link syntax ({{link:<URL>}}) from the message parameter of the Send migration progress operation in the Status REST API.

We made this change because we no longer display app migration status messages in the migration assistants — we only include them in progress logs (available for download from the migration assistants). As a result, the link syntax is no longer relevant since the progress logs are formatted as CSV files in plain text.

We recommend that you replace link syntax in your status messages with raw URLs, as in this example:

If you don’t replace the link syntax, your status messages will include the {{link:<URL>}} as plain text in progress logs.

How to report migration progress and format status messages

We've increased the retention period from 5 days to 12 days for all app data exported to the migration platform’s intermediary cloud storage.

Note that we’ve only increased the app data retention period. The overall expiration period for migration transfers is still 14 days.

Learn how to export app data and access it in the cloud

Previously, if customers wanted to cancel an ongoing migration, they would have to contact Atlassian support to cancel it. We have now updated JCMA and CCMA to allow customers to initiate cancellation.

Upon initiating cancellation, the app migration platform will send a new event transfer-cancellation-requested to your cloud app. The cloud app should handle the event and will have 60 minutes to complete any clean-up tasks then settle the transfer.

Learn more about transfer cancellation here

Previously, if the percent parameter wasn't provided to the Send migration progress operation or the value was set to 0, the request would fail when there was a prior update with a non-zero value.

We have updated the Status REST API so that status updates no longer fail when the value of the percent field isn't provided or is set as zero. When there is a prior, non-zero value for percent, that value is retained.

With this change, applications no longer need to track percentages, making it easier to update migration status.

Learn more about reporting migration progress.

The Status REST API Send migration progress operation now limits the length of the message parameter to 300,000 characters. Values that exceed this limit are truncated to 300,000 characters and appended with this string: <truncated, message too large>.

Learn how to report migration progress

We’ve updated our documentation with an important recommendation to retry HTTP 5xx errors instead of allowing a single error to cause an app migration to fail. This recommendation applies to the following REST APIs:

• https://developer.atlassian.com/platform/app-migration/mappings/

• https://developer.atlassian.com/platform/app-migration/progress/

• https://developer.atlassian.com/platform/app-migration/app-data/

We’ve observed numerous migration failures that could have been prevented if temporary HTTP 5xx errors were retried. These are typically transient service failures, and retrying the request can often lead to successful completion.