Is there any reason for running multiple instances of JIRA and/or Confluence in an organization that wants to focus on cross-functional collaboration, communication (reporting), and transparency?

[Business UserPM]

Less than a year ago, it is my understanding that an instance of JIRA was set up for the IT department. A short time later, there was one business unit that wanted to try it out. Rather than have them use the original instance, the other business unit was set up in another instance. There are also 2 instances of Confluence and not everything seems to talk to everything else. Since then, other business units want to leverage the tools, but it is very confusing as to why there are multiple instances and if it makes sense to collapse everything into one instance or not at this time. No one seems to be able to articulate the original reason for have unique instances, other than perhaps trust and the effort it takes to define common fields.

So the questions are: Any behind the scenes reasons for having multiple instances (benefits/drawbacks)? If we ultimately want to encourage collaboration and reporting across all business units, shouldn't we be in the same instance and isn't that easier to do sooner rather than later? Is there a load or license issue that may be in play here? I am just trying to understand the situation so that we can make good business decisions. Thanks!

[Mike Rathwell · Accepted solution]

I do concur with Timothy's comments at least concerning Confluence mostly because it doesn't have the facility of federating separate instances like JIRA does. Our company has separate instances of both Confluence and JIRA mostly due to geographic implications.

JIRA is utterly no problem; once JIRA instances are federated, I can link, clone, reference issues on either system FROM either system with little more effort of saying where it is. That part works very well and allows us to have two totally separate systems that operate suited to each location's specific needs without imposing the extra complexity imposed by supporting two disparate sets of needs in one system.

Confluence, however, is a bit tougher. We do have separate ones, again driven by geography but, in this case, it's a bit of a PITA. While I have Confluence configured to be able to see into both JIRA instances, there currently is no way of federating Confluence instances like JIRA can be. As such, there are always rather cumbersome methodologies we have to employ to reference information on one Confluence instance to the other one. One can't readily include content (and have it reliably work in case, for instance, someone moves or renames a page) and it's just... well.. a PITA.

All that said for BOTH Confluence and JIRA, there is a lot to be said for not having a single point of failure with them all combined into one instance.

So... Short(er) answer is that if you don't have geographic or wildly disparate user needs, make 'em big single instances and secure specific content as/where required by user or user groups. If you add in some of the clustering capabilities of Atlassian products, you can mitigate the single point of failure element.

The longer answer is as above... There are.. reasons.. for having them separate and if you can't decide or it seems like a nightmare to marry them, stuff just the Confluence to one instance and JIRA is no itch to keep separate.

[Business UserPM]

Thank you so much for the detailed answer. If we were to keep 1 Confluence and 2 JIRA, how would that impact report pulls in Confluence? If something is linked to JIRA, does it actually pull the info from the database? I am thinking that reporting could be a nightmare with more than a 1 to 1 ratio. Your thoughts would be greatly appreciated.

[Mike Rathwell]

Actually that works very well. It is, in fact what I do with my own Confluence instance where I have both JIRA instances in the company set up as trusted applications to Confluence. Basically, if I insert a JIRA macro, for instance, I merely select from a dropdown box WHICH JIRA I am selecting from. Nothing is actually "pulled" into Confluence from JIRA. It only displays the results of a query. That said, to your point, reporting with two instances is a bit more of a challenge where I do end up with a report in two parts, as it were, but with creative page layout and the like, it LOOKS like it is a single report. In my case, strictly speaking, it isn't a biggie since both divisions run their own way so I'd actually have a BIGGER problem to try to rationalize the two datasets to a single report. What I CAN do is get down to a summary report for each that makes sense in their own context. Going forward, I am going to be working with the other division and how to, if not federate (because we can't) the Confluence instances, at least make a definitive intersection of pages, etc. where they can link to each other and make it appear as seamless as possible. it would be lovely to be able to do a "!" include of a page where the usual SPACE:PageName nomenclature is extended to INSTANCE:SPACE:PageName but will do what we can to make it so. Glad I could be of help.

[andrew_zhou]

Hi @Mike Rathwell , this questions sound a bit challenging but can you pull JIRA status infor from two different instances belong to two different companies/ Orgs given that you have the credential to login of course. I had a niche scenario I need to generate report in Product Owner's Confluence including both internal and external Vendor's JIRA status.

Regards,

Andrew

[Timothy]

Short answer: No.

Long answer:

You already know the reasons why you should merge instances as you've stated them.  The only drawback of merging them is that you have more things to manage (e.g. permissions, fields, spaces, projects, etc).