Data residency realm migration for Connect apps: Early Access Program

Today, we are happy to announce the launch of the Early Access Program (EAP) of data residency realm migration for Connect apps. This EAP release includes a new realm migration service and associated APIs, which will enable you to start integration and testing to support migration of app data to match the parent product realm. For more details of this EAP, please refer to developer documentation.

If you have any questions or would like to provide feedback, please reach out to us by leaving a comment on this post.

If you face technical issues with APIs or bugs, please raise via our developer support desk.

Read the full blog announcement here.

Update on supported regions of Realm Pinning

In addition, we have added Germany as one of the supported realms for Connect Data Residency. To see our list of supported regions, please read the documentation.

5 Likes

Hi, thanks for the heads-up!

I just looked at the docs and didn’t see anything related to the standard lifecycle events. Not sure why (maybe I got this from some older announcement etc.) but I thought that the migration target realm app instance would receive the standard install and enabled lifecycle webhooks (and the source realm app instance would receive the disabled and uninstall events).

If not I suppose the tenant record migration needs to be done during the scheduled migration phase.

Could you please confirm either case?

This is for an app that only stores tenant records in our storage.

Thanks,
Jens

2 Likes

@SushantBista thank you for the announcement.

Is there documentation available which data are considered in scope for data residency for apps? I’m asking especially about:

  • Are the install data and shared secret data which are in scope?
  • Are data like the accountId in scope, given that Atlassian stores them in the US irrespective of data residency settings?
  • Does data residency concern only storage, or also processing? As an example, if an app stores all data in Confluence, and processes e.g. page data from Confluence by reading the data and writing the data back to Confluence: Is this processing to happen in the data residency realm?
1 Like

Hi @jens!

So just to elaborate a bit on the existing data residency behaviour for Connect.

Currently, after an instance is pinned, is it entirely possible for an app to move realms. This behaviour is facilitated by an uninstallation by the customer, followed by a reinstallation - thus causing the old realm to receive a disabled and uninstall lifecycle event, and the new realm to receive an install and enabled lifecycle hook.

However, with Connect data residency migrations, neither realms will receive any of these lifecycle hooks as the app is neither uninstalled or installed.

During and prior to the migration, all hooks will continue to hit the current realm - and if the migration is successful, then subsequent hooks and webhooks will hit the target specified realm.

Hopefully that answers your question!

Hi @marc,

The data types considered in-scope for an app’s data residency will be dependent on a Partner’s/app’s individual privacy and data residency policy, which should be documented and made available to customers.

Atlassian has outlined details of what is in-scope for its products here.

Data in transit (up to 30 days), including data being processed and not at rest is currently not in-scope for Atlassian products data residency.

Thanks,
Sushant

Hi @SushantBista ,
another question: does the clientKey stay the same during and after migration? Currently the lifecycle hooks issue uninstall and install events, resulting in changed clientKeys (I believe).

And can we “query” a Confluence instance to get the current realm? The reason I’m asking is that we want to process data in the same realm as where the current Confluence instance is.

1 Like