Merging two jira instances of almost identical project configuration

[Bryan Karsh]

Hi, 

Here is a pickle for you. I have two self-hosted jira servicedesk instances. Both have around 450 projects. The projects are the same in both instances, and have the same pkeys. The instances were designed off a template to share similar functionality despite being in different geographic locations. 

Okay, so we have a project to merge these two jiras into one. We have the Configuration Manager plugin, and were planning to use that. We were also planning to modify the  pcounter field in the project table (db hack) to change *new* issuekeys by a certain amount. 

However, it dawned on me that this doesn't solve the very real problem of issuekey name collision -- since we have several hundred projects with issuekeys that are identical on both instances.  I don't want to do some uber csv import of 400+ projects' issues with modified issuekeys to avoid problems. I also don't want to create new projects to avoid it. What I do want is to migrate the issues from the source instance projects into the target jira instance's respective projects -- just with modified issuenum values. 

Any tips? 

[Mirek]

These projects are the same in both instances

So both instances have only similar projects and configuration but different issues?

[Bryan Karsh]

yes -- but the issuekeys overlap due to same pkeys in both source and target instances. 

[Mirek]

Well if the configuration is the same.. I think the best way would be to build a tool (script) that over REST API would get similar projects from instance A (source) and instance B (target) and simply get values from tickets and based on that create a new ticket in instance B.. You can even probably add a simple weblink in the old ticket to new instance to quickly see ticket if needed.. Then you simply run the script and it should be all magically done.

[Matthias Gaiser _K15t_]

Hi @Bryan Karsh

you might want to look at an issue sync app. I'm working for the team behind Backbone Issue Sync and I actually had to smile about your requirement about changing issue keys. Why? Usually, we get the requirement the other way: People want to keep using the same issue keys.

If you use an issue sync app, you wouldn't need to care about the issue keys, the issue sync solution would simply create new issues with new keys and carry the data over. One thing to think about is the issue history which wouldn't be replicated. If it's important to you, you could think about writing it into a text field (see this article for Backbone).

If you want to evaluate that path, I'd recommend setting up a one-way sync from one project to another one which you can throw away in the end.

This is basically the less coding way of the path @Mirek suggested - but you'd pay for the app. :)

Cheers,
Matthias.