Changelog

We are excited to announce following 2 new app related pre-migrations checks in CCMA v3.4.3 and above. Customers will be able to proceed with the migration if any of this check fails.

1. Cloud app license check

This pre-migration check verifies that all apps participating in the migration plan have an active cloud app license installed on their cloud site instance. If the license for any of those apps is inactive, customers will be redirected to manage the app license on the cloud site. Free apps will pass the check.

2. Check for apps to verify if apps can receive migration notification

This pre-migration check verifies all apps participating in the migration plan are registered to receive migration notifications. This means the check will pass for the apps that have registered a webhook to receive migration events or apps that don’t require them to function. If this check fails, the customer will be directed to the marketplace partner support portal.

Watch the changelog for future updates when this feature will be available for Marketplace Partners in the Jira Cloud Migration Assistant (JCMA).

You can find more details about Atlassian offered app checks at: https://developer.atlassian.com/platform/app-migration/app-vendor-checks/#atlassian-offered-app-related-checks-that-run-by-default

App vendor checks feature was first introduced in CCMA on 31 January 2023. This is now publicly released to customers from CCMA v3.4.3. This means any checks written and registered by vendor will always run for customers. For now, these checks are non-blocking for customers.

Read our docs for more information on how to build the pre-migration checks and write effective content for the checks.

The App vendor check feature is now also available for Marketplace Partners in the Confluence Cloud Migration Assistant (CCMA) version 3.4.0 and higher by enabling the feature flag migration-assistant.enable.app-vendor-check.

Read our docs for more information on how to build the pre-migration checks and write effective content for the checks.

Note:

Watch the Changelog for future updates about the public release of this feature for customers in the CMAs.

Atlassian support can now cancel transfers upon customer’s request. This was previously an experimental feature.

When this is requested, your cloud app will receive a new event with the type transfer-cancellation-requested and you may need to take an action.

We’ve added a new feature to the App migration platform that allows you to create and run pre-migration checks for your customer’s app migration. This feature of the Cloud Migration Assistant allows you to:

• detect and warn your customers about any pre-migration issues that can affect their app migration

• provide guidance to help them resolve potential pre-migration issues

Read our docs for more information on how to build the pre-migration checks and write effective content for the checks.

Note: The App vendor check feature is currently available for Marketplace Partners in the Jira Cloud Migration Assistant (JCMA) version 1.7.7 and higher by enabling the feature flag com.atlassian.jira.migration-assistant.enable.app-vendor-check.

Watch the Changelog for future updates about the public release of this feature for customers in the CMAs, and when this feature will be available for Marketplace Partners in the Confluence Cloud Migration Assistant (CCMA).

Server side listener failures can cause an app migration look stuck for long hours, as their cloud apps may not be aware of server side listener failures and miss setting a proper status to such app migrations.

To close this gap, App migration platform is introducing,

• a new web hook event type ( listener-errored) to notify the cloud apps when there is a server side listener failure

• a new connect end point to fetch details about the server side failure

You can read more details about this feature here.

We are experimenting with a feature to cancel stuck transfers. Cloud apps may receive a new event with the type transfer-cancellation-requested.

As the platform evolves to cover more exceptional cases, in future there might be also events to notify marketplace partners that there was an error on their server-side migration listener.

We are starting to phase out our first-generation app migration listeners (AppCloudMigrationListenerV1 and CloudMigrationListenerV1) in favour of DiscoverableListener

Added more details on how to handle request rate limits from the P2 server app.

This change was originally planned for the 16th of May and has now been applied. We have monitored the usage patterns on this endpoint and no customer impact is expected.

Following the announcement at MIG-812, the User Impersonation requirement to use the following Bulk APIs will be removed:
The Jira Cloud platform REST API - Bulk update custom field value
The Jira Cloud platform REST API - Bulk update entity properties

Requests made with User Impersonation will have their impersonation ignored.

Updated documentation to provide more details on possible 429 from calls made to App migration platform from cloud app.

For more details, refer to: https://developer.atlassian.com/platform/app-migration/rate-limiting/

Following tutorials are updated to remove the need to impersonate a user in order to use the Jira bulk APIs for entity properties and custom fields.

• Bulk API for entity properties

• Migrate app custom fields from Jira server to cloud

Refer to https://jira.atlassian.com/browse/MIG-812 for more details about this change.

Added Jira Service Management namespaces jira/servicedesk:requestType and jira/servicedesk:customerOrganization to mappings list.

Updated the tutorial for migrating app workflow rules to explain the step for cloud apps to filter the workflow rules that are yet to be processed.