Changelog

Building on top of our previous announcement about Forge Storage, starting from JCMA 1.12.42 (CCMA coming soon), App migration can automatically update server ID references to their respective cloud equivalent as part of the migration pipeline.

Learn more about it at Data transformers.

Starting from JCMA 1.12.36 and CCMA 3.11.13, we are offering, in early access, a new feature that allows you to migrate data directly into Forge Storage.

We are starting with Key-Value Store and Custom Entity Store. Soon, we should have coverage for other Forge Storage data planes.

Read more about it at Key-Value Store & Custom Entity Store

Starting from JCMA 1.12.37 and CCMA 3.11.12, apps can now define up to 7 app vendor checks, up from 3.

Following our announcements on Support for Multi Transfers, we are pleased to announce that starting from CCMA 3.11.9, Multi Transfers will also be available for Confluence apps.

Starting from JCMA 1.12.27, apps will have more flexibility about how they organise and report on the transfer progress.

Currently, no matter how big or complex your app’s migration path is, each migration will receive a single transfer to both operate and to report statuses updates. Furthermore, in the event of a retry, the whole data export and import process is restarted.

Multi transfers adresses these scenarios by nesting multiple transfers that can be independently managed. They also enable the developer to identify where there’s a dependency between them and to flag what transfers can be completed in the background without blocking the customer’s migration downtime.

Soon, we’ll be delivering this for Confluence migrations through CCMA, and then there will be a new announcement.

We have introduced a message size limit for the logMessage string parameter in the addLog Forge API. The maximum allowed size for messages are 65,536 characters. Log messages exceeding this limit will be truncated by the app migration platform.

Starting from @forge/migrations 1.0.5 If you encounter an unrecoverable error during app data processing in Forge app migrations, you can call migration.messageFailed(transferId, messageId) to fail the migration early (this will immediately settle the transfer as FAILED for users) instead of letting the transfer time out.

Please ensure adequate logging is added for users, to help them understand and remediate issues with migration.addLog(transferId, "your log message").

A new RFC is ready to review at https://community.developer.atlassian.com/t/rfc-80-app-migration-multi-transfers/87348

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.