Transferring issues from JIRA Service Desk (Cloud) to other JIRAs

[Wojciech Niechoj]

Hello,

My team, which is responsible for customer support, is currently considering migration to JIRA Service Desk on Cloud. We will soon be serving multiple customers, who all use JIRA Software for development work. 

We are looking for a way to transfer issues, that are created in our SD, to our customers' JIRAs. We have found multiple addons that can provide such functionality, like IssueSYNC, Exalate or Backbone Issue Sync. The problem with those is that they all require both instances of JIRA (our SD and our customer JS) to have the addon installed.

It may be impossible for our team to influence our customers to invest in an addon, that they may not in fact need on their side. 

So my question is: is there any other, easy way to transfer issues from our Cloud JSD to our customers' JSs', that would not require THEM to install any additional addons or the addon for JIRA Software would be free and only we will be charged? 

Also: while full sync between issues (i.e. when the customers would change something in the issue on their side, it would reflect in the issue in our JSD) would be greatly appreciated, it is not strictly necessary for our purposes. A single-time, unidirectional transfer of an issue would be sufficient. 

[Deleted user]

Hi @Wojciech Niechoj,

I get your point. Your customers should not be bothered with administering an add-on which they rarely get in touch with. Maybe the following can help you.

Disclaimer: I'm part of the team behind Backbone Issue Sync from K15t Software.

Backbone offers a way to use it without installing the add-on on both Jira instances, but only in one instance. We call it a "remote licensing model". It requires that the instance where you're installing Backbone is a Jira server instance, so in your case it might be the Jira Software instance. It's basically working the same as with installing Backbone on both instances. However, there are some minor disadvantages compared to the regular installation model.

If you are interested in more details, I suggest you reach out to our Support Team and we can discuss your context a bit more. You can reach out via mail to support@k15t.com.

Cheers,
Sebastian

[francis]

Hi Wojciech,

I would like to add our POV in this discussion.

(I'm part of the Exalate team - also an issue synchronisation solution)

We have learned the hard way that a single node configuration - where one node controls how information is applied on the other node - can lead to showstoppers.  The risk with this approach is that you get painted into a corner, whenever the remote node requires a configuration change.  It could be that your synchronisation will not work anymore because your partner introduced a new status, or requires that a field is set whenever transitioning an issue to resolved.   You want to ensure that your instances are loosely coupled, such that either side can perform a change without affecting the other side.

To be able to implement such a loosely coupled configuration, your solution needs an architecture where common information is translated to the local context.  The flow of the synchronisation is as follows

• Issue on Jira A changes
• Issue information is translated to a common format message
• The message is sent over to Jira B
• Jira B translates the message to the local context
• The change is applied on the local issue

Whenever your own setup changes, you can adapt that translation, without requiring any negotiation with your partners.   This becomes vital if you link with multiple partners.  Can you imagine that you have to work with all these partners whenever you introduce a new status, or do an upgrade?

I'm sure that your customers will understand this autonomy argument, and why installing an add-on locally is beneficial.  I hope this makes sense?

Regarding the pricing - we offer a licensing scheme where only one side pays for the synchronisation.  Please feel free to book a meeting for further discussion

https://www.idalko.com/exalate-book-demo

Francis

[Danyal Iqbal]

You can do this via REST API for free (ignoring time costs :)). We are running multiple such integrations from simple issue creation and syncing a few fields to full blown replication with only the rest api, login credentials and the correct permissions. (Managing attachments is a pain in the ****)

--Check out the JRJC- Java Rest Client to make your life a lot easier if you decide to follow this path. You can also explore the python rest client as well although i would not recommend it  (a definite No for customer facing instances/projects due to stability/reliability issues)

P.s: Such an integration sounds more attractive than it is. The whole point of jira is to reduce multiple copies of content/attachments. I would not do it unless the projects in both instances are extremely mature (> 1 year without any change in configuration) and I am convinced by the business use case. .

BTW Backbone is your safest bet among the plugins you mentioned.

[Deleted user]

Thanks @Danyal Iqbal for you kind words about Backbone :-)

Just a small addition to your answer: You're right, if it's only about syncing a few issue data from one side to the other side (i.e. one way), then using the REST API might be enough for your use case. Of course, it's required that you are able to develop such a small program by yourself or have someone who can do it for a low cost. However, if it comes to more complex sync scenarios (which might happen in the future, who knows), then a sync solution might have been a good choice from the beginning comparing the costs and effort ;-)