Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,773
Community Members
 
Community Events
176
Community Groups

Why do the migration assistants use region-locked S3 buckets?

Edited

From https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products/#For-CCMA-communications-

This indicates CCMA uses `rps--prod-east--app-migration-service--ams` s3 for app data.

If client is in EU, is `prod-east` still used? If client is in JP? Client on US west coast?


For JCMA, this is even worse, as the actual Jira data appears to always be sent to `us-west-2`. If enterprise customer is region locked, this breaks it and forces all data to, at some point, be subject to US jurisdiction.

Why does CCMA not do this? Is there a missing (or yet to be developed) web service in the JCMA stack?


Why is something like Multi-Region Access Points not being leveraged?

Am I missing something?

1 answer

1 accepted

0 votes
Answer accepted

Hi @Derek White

Thanks for your question. When we developer the App migration platform, we talked about this. Data in the S3 bucket is only held for about 10 days before it's deleted, or when the app transfer is finished.

It's a transient store, not a permanent store. Also, we don't control where apps store their data (although we do provide a way for regions to be specified.) So it might end up anywhere in the world once the app downloads it for processing.

It's the same for GDPr data. In https://developer.atlassian.com/platform/app-migration/mappings/ you can see we store it for no more than 14 days (in reality it's between 12 and 14 days as the deletion process can take 24 hours to run).

Hope this help.

Regards,
James.

That explains app data, but I was actually more concerned with product data.

Why does Jira have a "Uploading of migration data" entry, but Confluence does not? (This is not the "Uploading of app migration data" entry.)

How is this handled and why are they different? Does Confluence send migration data directly to the new site? If so, why does Jira not do it this way? Is the "Atlassian Migration Platform" utilized by Confluence to send data, whereas Jira uses an S3 bucket?

The client expected to see similar Functions for both CCMA and JCMA, since the migrations are similar. Who can blame them. When they saw the differences and the region locked S3 buckets, they questioned it. Why should their data go across the country to us-west-2, just to come back to us-east-*? Doesn't this make migrations and AWS data transfers take longer (takes longer to go between regions, than within a region).

Hi,

They're different because they're built completely differently. Confluence already have Space export, which is used in CCMA but Jira doesn't have anything similar, so each and every piece of data for a Project has to be exported and transferred. The Jira migration also has pieces of data that can differ between migrations (e.g. shared components like Workflows that can cause configuration drift.)

The Confluence Space goes almost directly (via a service) to the site for import. There's no residual data left over.

The Migration Platform consists of about 8 services, several DynamoDB databases, and a few S3 buckets.

The user interface is very similar, and some components are similar (especially for app migrations) but under the hood they're very different. But the end result is the same, the data gets to its destination. From my experience working on the platform, the different between different AWS regions doesn't make a lot of different to the speed as the network is rarely the slowest part of the process.

Hope this help.

James.

Thank you so much for the detailed response. Very good information. Clients often want a bit of information on how it all works and this will be extremely valuable.

Thanks!

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events