Hey @lexek-92,
Connect will treat DE and EU as seperate realms, as the declared EU realm could be hosted outside of Germany.
what should we do if we decide to host EU data in Germany for example? Should we specify two locations pointing to the same thing, or only EU or DE?
This will be up to app vendors to decide. Generally, if your EU realm is hosted in Germany, it will be ok to declare the same region for both. If your supported region for EU is NOT in Germany, then it cannot be used for DE declaration.
as continutation of previous point, what happens if user wants to migrate data to DE, but we only support EU region or vice-versa?
In case when we specify EU and DE as the same url (it it’s the recommended approach), what happens when user requests a migration from EU to DE, or vice-versa?
If your European DB is hosted in Germany, declaring the DE realm in your descriptor makes sense to ensure customers are aware that their in-scope is hosted in Germany.
If you only declare DE realm in the descriptor, the app will be shown as ‘ineligible’ to migrate to EU.
Optionally, for above scenario where your European DB is hosted in Germany, you could also declare both DE and EU in your descriptor, however from a Connect perspective, it would be treated as a seperate realms. There will be a few migration considerations to factor:
- Connect will treat still EU and DE as seperate realms (as it could be pointing to different locations)
- Customer would not know that the app is hosting in Germany for both EU and DE, and will assume a migration will take place if they request it
- If migration is requested by customer (i.e. if host product also moves from EU to DE (or vice versa)), a migration schedule hook will still be sent to your app (assuming the relevant endpoints have been integrated)
- However in above scenario, as both DE and EU are hosted in same DB in Germany, no actual migration will need to take place for the app, i.e. it can be set it up so the migration is commited to the new requested realm straight away during the migration window, without actually migrating any data
- Once migration is complete, the customer will see an update in UI that the app pinning realm has changed e.g. from EU to DE.
in case when we specify EU and DE as the same url (it it’s the recommended approach), what happens when user requests a migration from EU to DE, or vice-versa?
There is no technical restriction for declaring the same URL for multiple declared realms in descriptor. There maybe a few reasons for you to choose to setup this way. One is the scenario you have outlined, where DE and EU both point to the same DB hosted in Germany. However apps are also likely to also use a single URL across multiple declared realms if they are re-routing to the region specific locations on the backend (e.g. via reverse-proxy etc.).
Again from a Connect perspective, if multiple realms are declared on descriptor, it will treat it as seperate locations (for realm pinning). Therefore if your app has also enabled realm migration capabilities, and the customer requests a migration from one supported realm to another, your app will get a migration request to migrate and commit to the requested realm (regardless of if an actual data migration takes place or not in the backend).
at which point the data from the source location should be removed?
Generally 30 days or less, but please let me confirm and get back to you on this.
is there a timeout after residency migration before user might attempt a new migration?
No, a ‘timeout’ has not been implemented at this stage.
Thanks,
Sushant