Thanks for the detailed update. I appreciate all of the effort that has gone towards solving the issues with the dashboard and permitting ad-hoc realm migration for apps.
With regards to the Connect installation realm being sticky, I also appreciate the additional information about the other use cases for it being non-sticky. However, I do believe that enforcing the prioritization the way you suggest would do more harm than good.
As I understand it now, there are two separate uses cases for the uninstall/reinstall lifecycle:
- The app vendor is doing a one-time manual realm migration and they are using the uninstall/reinstall process to switch the realm of the app.
- The app is being uninstalled for any other reason, including troubleshooting, maintenance, expiration of trial, and a myriad of other possibilities.
Manual realm migrations in #1 are very low-occurrence. Other reinstalls for #2 are, in relative terms, very high-occurrence.
If this uninstall/reinstall occurs at any time after a realm migration is performed, but before the app supported migration to that realm, this creates an issue. I do not think that #2 necessarily becomes “relatively low occurrence once realm migration capability is made available to customers”: even if the app adds support for realm migration at a later date (compared to the pinning of the host product), I don’t think we can count on admins regularly going to the dashboard to migrate additional apps. So, even if you have 100% of apps supporting realm migrations, you will still have this problem.
Realm switching is an important event, and having it happen in an uncontrolled and unexpected manner is unquestionably bad. But with #2, this is exactly what happens. The magnitude of the issue created by this problem is also huge (all of the customer’s app data is unexpectedly gone, and even worse, the only way to fix it creates heaps of work for the app vendor!).
#1 is a low-frequency, high-touch event that, by definition, already requires manual involvement of support personnel from the vendor. It seems that this case is more of the exception than the rule, and if it took a manual ticket raised with Atlassian to unpin the app realm, I think this would be entirely reasonable. If this adds two extra days to the process to unpin the app, how many people care? Or, alternatively, allow apps to specify their preference through the app descriptor, as lexek-92 suggested.
In summary, causing #2 to break regularly with catastrophic results, in order to help prevent breaking #1, feels like the wrong trade-off. Especially since the only people doing manual realm migrations with #1 are using a legacy process, who you probably want to push to use the automated realm migration solution anyway!
This must take into account that DE is a subset of EU (if the host application is pinned to DE, an app with data stored in US should be able to migrate to EU even if the app doesn’t support DE).
Regarding considerations between EU and DE realm declarations for the app, I have attempted to clarify in my above comment.
It seems odd that, if an app supports EU data residency but not DE specifically, then a DE-pinned customer will not be able to migrate existing data out of whatever location may be in use (let’s say, the US) to at least bring it into the EU.