Handling project-related migration errors

Acknowledgment

Thanks for your answer, @jrichards. You have corrected my misunderstanding about the relationship between Jira projects (or Confluence spaces) and apps involved in the migration: essentially, apps are free to migrate their own data regardless of which projects/spaces are transferred as core data.

I believe you’re referring to the data available via the getPaginatedMapping() method on the server side. That comports with the conclusion reached by @PhilippFrank in a different thread.

I hope I’ve got that right now.

Clarification request

You mentioned that the mapping data available for up to 14 days, but the Introduction to app migration says:

"You can retrieve mappings using the Pagination API before the end of the lifespan for each namespace. The table below lists the lifespan of each mappings namespace.

identify:user  --> 14 days
confluence:*   --> 2 years
jira:*         --> 2 years

Since the transfer id can be used for up to 14 days only, how would I obtain the jira:* data transferred up to 2 years ago?

Let me see if I understand the scenario to which you allude. A customer includes our app in a migration. They then alter some of those data on the server side, and perform another migration. I think you’re suggesting that we re-transfer the app data that changed between the two migrations so that the Cloud app will reflect those changes. Have I got that right?

That brings to mind a question about overwriting of data on the Cloud side, but I will raise that in a separate thread.

1 Like