Advance Notice: Connect Data Residency Customer Rollout

[SeanBourke]

Hey @marton.kelemen,

Thank you for the well thought out reply. My apologies for the delayed response, I wanted to ensure that we address each of the questions you’ve asked - hopefully the below helps.

@marton.kelemen

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.

If your app supports a regionBaseUrl of EU and Connect directs traffics for a customer’s app installation to EU based upon their proximity to that realm, then they will be deemed as being pinned to the EU realm.

• If the customer’s product exists in (or later moved to EU), then that customer would see the app as Pinned to the EU region.
• If the customer moves their product to a different realm which you also support in your Connect descriptor, then they will see your app as Eligible to move with a current location of EU
• If the customer moves their product to a different realm which you do not support in your Connect descriptor, then they will see your app as Not Eligible to move with a current location of EU
• If the customer had installed the app prior to any data residency realms being supported, then they would likely be directed to your baseURL and will appear as Eligible given they will be deemed as being in Global (or Not Set).

@marton.kelemen

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?

The /status endpoint is queried on a 15 minute interval, meaning that in this circumstance, the maximum duration of product downtime would be 15 minutes. It’s worth noting that the scheduled migration period can include multiple apps and the product downtime is impacted by the longest running migration task; so if a different app takes longer to migrate in the window, then the product will be unavailable until that app also completes its migration. I’d be keen to understand if you feel that for live migrations (where you have to move data between regions), if a 15 minute polling period is sufficiently frequent?

@marton.kelemen

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?

At the moment, this is provided through the via the Admin UI to provide admins visibility of where app data is currently located. A previously proposed improvement to have prior awareness (i.e. inverse app awareness) of a mismatch with a customer’s realm based upon the feasibility of a tenant pinning API would also provide the capability to support customers in understanding when an opportunity exists to realign data. There is no available scope or timeline available for this at the moment, however.

@marton.kelemen

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.

Appreciate this feedback and understand how it could create efficiencies in the process. It would be great to understand the frequency you have to perform fake migrations once this is live, as this would inform the potential for an improved customer experience. As noted earlier, the minimum downtime for a customer’s product is 15 minutes (pending all app migrations are completed in that window).