i.e names are different, but ID is the same.
e.g. customfield_10010 is in instance A as well as in instance B.
How am I supposed to handle this?
I am planning to use the project configurator add-on to merge instance A project for project into the instance B.
But the question is a general one: Out of history it happens that I have e.g. customfield_10010 in both instances independently, they have different type and different meaning. The project configurator add-on will see both and assume they are the same, when importing the data they will be messed up. Do I see dragons here which will turn out to be a real problem or am I missing something that prevents problems in this area?
Yes, dragons. You looked in the wrong lair for them, but you were absolutely right to suspect dragons are there.
The dragon's lair called "field ID" will not cause you any problems - the project configurator will happily create a new field with a new ID and then project import will pull the right data into it.
The dragons are currently living in your "different type and meaning" lair, as you suspected. If the fields were the same type, you'd have a bit of fun merging them, but as they're a different type, it won't work. There is a Very simple work around though. Before doing any exports (of configuration or data) from the source JIRA, rename the field. Project Configurator and Project Import will then happily handle it as a separate field, bring in all the data, and then you can ask your users what they want to rename the fields as in the post-merge system.
This does have the weakness that filters using the field may fail, but there's no easy fix for that, it's easier to educate your users on what's happened and how to change any filters to use the new field names.
I wanted to check to see if your merge was succesfull. The following guide provides detailed information and is written based on the practical knowledge which our services team have aquired merging more than 30 JIRA server over the last 2 years. We of course use Configuration Manager for JIRA. In case you have any questions please don't hesitate to contact us at firstname.lastname@example.org.
the merge was successful but this job was no easy one. I used Project Configurator for the configuration and the built in mechanisms for data export and import. Most frustrating was the need to fix the xml file after export and before import due to incompatibilities of export and import. Why do I have to write a script fixing those bugs ...
Another frustrating thing was that you obviously have to delete a whole project after a failed import to get rid of any debris. Just looking into it if there are issues already there is not enough. I screwed up a whole project due to this and it took me weeks to clean up the mess afterwards. Unfortunately we didn't see the errors immediately and after some days there were too many changes done to roll back and do it once more.
But now we're through it and I hope this was the last merge I had to do ...
If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot