How should we handle the case where migration of project-related app data fails? Consider this:
The customer has three projects: A, B, and C. They start a migration that includes projects A and B only, plus our app. Our app attempts to migrate some data associated with projects A and B, but fails on project B for some reason.
Assuming that the customer is able to correct the problem, how would they re-run the migration for project B? My understanding is that a project that already exists on the Cloud side can’t be included in a subsequent migration.
What if the customer then runs a second migration for project C? Should our app re-attempt to migrate the project-B-related data that failed earlier?
Thanks for the question. App Migration doesn’t have to be tied directly to the Jira Projects or Confluence Spaces being migrated. All the migrated data like issue ids or content ids are available in subsequent migrations between the same server and cloud site for (up to) 14 days.
One option is to keep a diff of sent data, because ultimately you may find data drift between migrations that you also need to keep up to date.
You can use the feedback channel documented here to keep track of what’s been successfully migrated and what still needs to go
You can use the feedback channel to send a message back to server to request a re-migration of specific data (or anything, as it’s just an object of any type that you send.)
When you send the data, you can use labels to help identify there data, or send a manifest file first to indicate what will be sent.
So, in answer to the question
What if the customer then runs a second migration for project C? Should our app re-attempt to migrate the project-B-related data that failed earlier?
I would say yes, your app should try and re-send the data for project B using the feedback channel to help identify what needs to be sent.
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.
"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.
I will need to confirm this because it’s in a bit of flux at the moment. If you finalise the transfer, then the data becomes inaccessible. This also happens when the transfer is timed out after 14 days but I’ll need to confirm exactly what the status of that happening. However, as a matter of good practice try and make sure the transfer is completed within 14 days, preferably less than 24 hours as that’s what we’re aiming for at an enterprise level.
Yes, that’s right and it’s similar to what JCMA does with configuration drift between migrations of projects and for example workflows or other shared data.