Changelog

Starting from Jan 6, 2025 , the App Migration Platform will be filtering out some events for Atlassian Connect that are not actionable.

For now, the only event to be omitted is app-data-uploaded strictly during scenarios in which the data can no longer be retrieved, such as when the transfer has been marked as settled.

Please note that even before this change, if an app tries to retrieve the data for a settled migration, an error will occur.

Starting from JCMA 1.12.15, customers will be able to identify when an app migration has done migrating its critical part hence enabling them to start using the cloud instance.

This feature is expected to reduce up to 60% of the migration downtime on selected apps.

We are now exploring how to extend this feature to make it self-serve for all the migrating apps.

Connect On Forge apps supporting Server To Connect app migration path can register for app migration webhook on their manifest as detailed here.

Long-running functions are now available as an Early Access Program (EAP) feature for Forge.

This feature allows developers to configure functions for Forge async events that have a much high maximum duration of 15 minutes (up from 55 seconds). This can be useful for apps that need to perform complex, batch operations or for apps that need to perform long-polling against external services. This EAP may also be relevant for developers performing data processing as part of their server-to-cloud app migration.

Refer to the Forge documentation for the function module and the async events API for more information about this new capability.

To sign up for this EAP, use the request form.

Since Oct 11, 2024, all webhook events sent to Atlassian Connect apps as part of migrations are receiving a new property serverAppVersion indicating the version of the installed P2 plugin performing the migration on server and DC side.

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