Thank you for your prompt reply.
I can confirm, your understanding is correct.
I can also provide you with a very typical use case:
Our app registered the customer to the desired location (e.g. to the EU) based on Atlassian’s routing choice (i.e. based on geolocation), even though the instance was initially not pinned. Later on, if the instance gets pinned by the customer, we still have to do an official migration process for our app’s data, instead of just labeling the app’s data as already migrated.
So, this means that our app has to go through the standard migration flow, even if there is no real need for moving any data? Of course, we can shortcut at least the heavy part, as you wrote, but…
I still have concerns regarding this.
First of all, what is not clear to me is that how much system downtime can such a “fake” migration induce. If I’m right, the host product must be shut down/“freezed” during the data migration process. Are there any other potential side-effects, too? (provided that otherwise our app would be the only one participating this data migration session, these effort are all in vain)
There is another, not that much of a technical issue, but still an important aspect: how can customers get informed about the opportunity/necessity of a data migration at all? I think, following this concept they have to trigger all the events and then see the outcome, therefore, if they do not take the initiative, they won’t be aware of the fact, where their data are stored. Of course, if it’s not crucial to them, then we also can live with it, but a bit more proactive attitude could help a lot…
Apart from these, I could imagine that by adding an extra
data storage location field to the migration overview (for which, the response could be obtained by another hook preliminary to the migration => similar to the
/schedule hook), the admins could assess their apps’ statuses better, without the necessity to initiate an entire migration in order to get the answers for such questions.
As an alternative, an app could indicate in the response given to the
/schedule event that the data are already migrated to the specified location, so subsequent hooks shall not be called. However, this could only tell the user, whether their data are already in a requested/target location, so the first approach seems to be more generic and user-friendly for me.
Anyway, if the implementation of such an assessment step would require too much effort, then we’ll go for the suggested solution. It can surely work, even if it’s suboptimal in some scenarios.