This page includes release notes and updates about the app migration platform for individuals who develop migration paths to move app data from server/data center to cloud.
Use this page to keep track of new or updated features, deprecations, and bug fixes.
Read our docs on getting support through the right channel.
The app migration platform will now automatically detect the correct migration listener to invoke if multiple are defined. This can be useful for defining different migration paths to different environments (i.e. commercial, isolated cloud and AGC) or if you would like to support migrations to one or more cloud apps.
To find out more, our documentation is available here
Forge apps can now make API calls on behalf of JSM portal-only users. JSM portal-only users (also called customer account users) are customers who access your service desk through the JSM portal but don't have a full Atlassian account.
With this release, asUser() in Forge now works for customer accounts from both the frontend and the backend.
Apps can now perform actions like creating customer requests, reading comments, and updating tickets in the context of the portal-only user, with full permission checks preserved, exactly as they would be for a standard Atlassian account user.
The changes will be reflected upon redeployment of the Forge app.
This change only affects online user impersonation, for offline user impersonation we have a feature request being evaluated here: https://jira.atlassian.com/browse/ECO-1585
KB Article search & view endpoints are now supported for Forge apps for customer account users / unlicensed users
We have added Forge OAuthScope support for the endpoint /rest/servicedeskapi/knowledgebase/article/view/{pageId}. If your manifest has
1
2
3
4
permissions:
scopes:
- read:servicedesk-request
- read:knowledgebase:jira-service-managementthen Forge apps should fetch contents of the article(page) for portal customers.
What’s changing
We’ve introduced a new paginated endpoint to retrieve uploaded file metadata. This change helps reduce memory usage when handling large amounts of data during migrations.
Forge remote apps can now use the new endpoint: /app/migration/forge/v1/data/{transferId}/page.
Forge functions can now use the migration.getAppDataIterator method, available in @forge/api version 7.2.0 or greater.
We will announce the deprecation of the /all endpoint at a later date.
What you need to do
If your app handles large volumes of migration data, we recommend updating your implementation to use the new paginated methods:
For Forge remote apps: Update your requests to use the new paginated endpoint.
For Forge functions: Ensure you are using @forge/api version 7.2.0 or higher and migrate to migration.getAppDataIterator.
To reflect that Forge SQL & KVS Migrations are now suitable for use in production, the features have moved from Early Access to Preview status. Learn more at https://developer.atlassian.com/platform/app-migration/forge-storage/data-planes/
The Forge migration timeout logic for now uses a 15-minute sliding window from the last event status change (instead of 15 minutes from when the event was created). See https://developer.atlassian.com/platform/app-migration/report-progress-for-forge/ for more information.
We have increased the maximum file size for individual files uploaded during app data export to Forge from 16 MB to 256 MB. For more information, see the app data export documentation.
Starting JCMA version 1.12.50, Jira workflow rules can now be migrated through the P2 to Forge migration path.
Learn more about migrating workflow rules here
We now support Forge remotes in App migration platform addressing https://jira.atlassian.com/browse/MIG-2452 . This means you can call our APIs from a Forge remote.
Refer to https://developer.atlassian.com/platform/app-migration/rest/v2/intro/#about for the APIs available and https://developer.atlassian.com/platform/forge/remote/calling-product-apis/#calling-atlassian-app-apis-from-a-remote on how to call Atlassian APIs
Example:
1
2
3
4
5
6
7
8
9
curl --request POST \
--url 'https://api.atlassian.com/app/migration/forge/v1/message/{transferId}/status' \
--header 'Content-Type: application/json' \
--data '{
"status": "SUCCESS",
"messageIds": [
"<string>"
]
}'Note our base url is https://api.atlassian.com/app/migration/forge/v1/
Portfolio Insights will now include an expanded app assessment with information about Marketplace apps for migrating customers. This functionality is similar to app assessments from the migration assistants, and re-uses data provided by Marketplace partners through both Atlassian Marketplace and the App migration platform.
The goal of this functionality is to provide more information about apps earlier in the migration journey so that users have enough time to prepare and work together with Marketplace partners. Atlassian migration teams will also have access to this information so they can better support our users in their migration.
The expanded app assessment is based on existing resources provided by Marketplace partners on the Atlassian Marketplace or through the App migration platform.
It includes the following information for every app:
Cloud availability: Whether a cloud version of the app is available.
Migration path: What migration pathway is available, re-used from the App migration platform, with options, such as Automated, Manual, or Install only and links to migration documentation provided by Marketplace partners.
Overview information: General information about the app, re-used from the Atlassian Marketplace.
After assessing their instances, users can now view all of their user-installed apps, with additional information on each app’s cloud versions, migration pathways, and overview information.
The entries for ScriptRunner, Zephyr, and Xray also include the number of important entities, how they compare against migration guardrails, and migration recommendation.
Example from Xray:
Users will see the number of custom-built apps they have on their instance, with a way to review them in Data Center.
A new RFC is ready for review at: https://community.developer.atlassian.com/t/rfc-118-cloud-to-cloud-identifier-mapping/96871
Starting from CCMA 3.13.1 and JCMA 1.12.47 and `atlassian-app-cloud-migration-listener` version 1.8.7, you can use the Object Store data plane to migrate data into Forge Object Store from Server/DC.
AppDataListResponse in the Forge migration API has been updated to match the actual response.
Previously, the definition didn't match the API response, which could cause cast errors or undefined object errors when accessing response fields. This fix ensures the response structure is consistent with the API documentation, so the API can be effectively used to migrate apps from Server or Data Center to Cloud.
If you were using the previous definition, you may see a compile error after updating. To resolve this, change any usage of response.result to response when calling this API.
Starting with JCMA 1.12.46 App Data Only migrations will be available. See exp-app-data-only-migration for more details.
Starting with CCMA version 3.11.16 we now support migrating Confluence Server Macros directly to Forge Macros. See p2-to-forge-macros for more details.
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.
Rate this page: