Issue Summary

The App Migration Platform API currently provides no mechanism for Forge app vendors to discover or retrieve transferId values from past migration runs. The transferId is delivered exclusively via the listener callback at migration time. If a vendor's app did not persist the transferId at the time of the migration, there is no API to recover it afterwards.

In multi-run or chained migrations (where projects are migrated in separate runs under the same migrationChainId), this creates a practical data loss scenario: mappings for entities migrated in earlier runs become inaccessible to the app unless it has already stored the transferId from each run. The mappings themselves remain available on the platform, but the vendor has no way to retrieve them without knowing the transferId.

Steps to Reproduce

A customer performs a DC-to-Cloud migration of a Jira instance in multiple runs under the same migrationChainId.
A Forge app with a migration listener receives and processes jira:issue mappings for each run.
In a later run, the app needs to cross-reference mappings from an earlier run (for example, because 21 projects migrated in a prior run are absent from the current run's scope).
The app has no way to look up the transferId from the earlier run via the public API.

Expected Results

The App Migration Platform API should expose an endpoint that allows a Forge app to query past transfers associated with a given migrationScopeId or cloudId. For example:

GET /app/migration/transfers?migrationScopeId={migrationScopeId}

The response should return a paginated list of transfer objects, each containing at minimum:

• transferId
• migrationId
• createdAt
• status
• appDataProcessed

The endpoint should be scoped to the calling app's installation, so a vendor can only retrieve transfers relevant to their own app on the target cloud site.

Actual Results

No such public endpoint exists. The only transfer discovery mechanism is the listener callback at migration time. Vendors must persist transferId values themselves with no fallback if they fail to do so or if the app was not installed at the time of an earlier run.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available.