I’ve provided some answers in-line below, hopefully this helps. We have more details about our manual testing available here.
We need to manually schedule these, so there can be some delay between the support request being picked up and actioned. With that said, you can provide multiple requests within the support ticket to expedite testing (i.e. schedule a migration from EU to US, then schedule a migration from US to EU 12 hours later).
You should be able to review the status of the app within the Admin portal. If not, please include a note within the request and we can follow-up.
App migrations have up to at 24 hour window to complete the migration. You can however request a shorter window for testing if you like.
Hey @SeanBourke ,
Thanks you for the answers, it clarifies the issue more. I would like to follow up few of the topics:
We are trying to adopt data residency into our app, therefore we would like to test the behavior of the residency mechanizm in different scenarios and establish solid contract. Is there more effective way to do so, instead of waiting 12h for mechanizm to be triggered manually ? The debugging in this case becomes barely possible.
We have created several support tickets at the beginning of the week and all of them have status new, thus do not really know wether the migration occurred or not, the Admin Portal shows that the app status is eligible.
Certainly, nevertheless in the test support ticket I was not able to set custom startTime and endTime for PM time, it switches to AM instead. I was wondering wether it is some validation issue or a bug ?
I have found your tickets that were indeed marked as spam since some unexpected data was entered in the fields (e.g. there was not Atlassian Cloud premium site URL, etc.).
I have now assigned them to myself. I will handle the 1st one and close the rest as duplicate. Please check the ticket in a bit time and get back to me in there.
Also, for the future, even if not explicitly mentioned in the documentation, requests should be made at least 7 days before the requested date (those ticket SLA is 1 week and when the queue is full it takes that long to get them worked on).
Thank you for handling the case. My bad, i’ve assumed that the process is automated, thus that many tickets were created.
Please correct me if i am wrong, but as i understand the concept of appKey and Premium Cloud URL, those are the key and baseUrl fields from Connect app descriptor file of the production app deployed to the marketplace ?
If those are true, is there a way to test the residency mechanizm locally ? Any suggestion or clarification would be very welcome.