JIRA Cloud and Data Center syncing and stability

[Julie Metior]

We are currently evaluating JIRA and would like to know whether the following is possible:-

1. Is it possible to sync a cloud instance with a data center instance?

2. If projects are archived on Data Center, will they automatically disappear from the cloud instance when they next sync? Or will they have to be manually deleted from the cloud instance once archived?

3. How many instances of JIRA are able to sync simultaneously with all data updating concurrently on each of them?

4. If a user is updating an issue on the cloud instance and another user attempts to update the same issue on the data center instance, are they notified that the issue is locked by another user or is there a risk of one or the other overwriting the updates that have been made?

5. There's a blog post introducing-jira-software-8.0 mentions that stability issues have been addressed and lag issues have been greatly reduced. Has anyone continued to experience stability / lag issues since the release of 8.0?

6. I've been told that some people have experienced issues with downloading and opening attachments. Is this still the case since the release of 8.0? If so, any suggestions on how to get around this happening or prevent it from happening at all?

7. Any suggestions regarding IT architecture/infrastructure needed in place for if/when we potentially transition over to JIRA - we currently have between 700 - 1000 users.

Thanks :)

[Łukasz Krupa]

ad-1 

Yes, you can use an app to do this like IssueSYNC.

It works for - cloud - server - data center deployments and supports different Jira version 6, 7, 8 and Jira editions - Core - Software - Service Desk.

But mind that it is not a exact replica. It is rather selected data synchronization between projects.

ad-2

In IssueSYNC Data center configuration you can point an event that will trigger deletion. By default tickets left as they are after archivization.

ad-3

Actually, limitation is performance of those instances. You can image that single change in one instance is like calling REST API action on second instance to reflect the change. So it is less number of operations that user's interaction using UI (more effort to render a view). 

Messages transferred between Jira instances can be send in bulk (using cron expression), so at least on network layer there is relatively small traffic.

ad-4

There is no such blocking mechanism. It is like in Jira out of the box when two users edit same issues. The last one saving the change wins. Of course all will be reflected in issue's change history tab. 

ad-7

That is something that customers use to ask their local Atlassian partners. Number of users is only one criteria of ten. You may consult with https://confluence.atlassian.com/enterprise/jira-sizing-guide-461504623.html