 This page has been deprecated. Please refer to the documentation on restoring a project from backup, which supersedes this document.
Merging 2 jira instances together using a modified atlassian-data-utils xml parser.
USE AT YOUR OWN RISK. This procedure worked well in our environments. Please test your merge result very good before you put it into a live environment.
!! READ THE WHOLE DOCUMENT BEFORE YOU BEGIN. THERE ARE SOME IMPORTANT NOTES WRITTEN DOWN !!
Prerequisits
- Backup xml JIRA instance A
- Backup xml JIRA instance B
Note: Both JIRA instances should have run the same version. Upgrade both instances to the version you want to have the final backup imported in. Than create the backups of both instances.
java -Xmx600m -DentityExpansionLimit=1200000 -jar saxon/saxon8.jar instanceA.xml parser.xsl targetxml=instanceB.xml > newbackup-translated.xml
Note: This process takes a while. 25 MB backup file took approx. 25 minutes.
Next, manually copy all entries from the newbackup-translated.xml file into the instanceB.xml file but keep in mind the listed exceptions below:
EXCEPTIONS
- The list of “SequenceValueItm” elements could not be the same as in the instanceB.xml. Copy all elements and overwrite the existing elements.
- OSPropertyEntry[@entityName=jira.properties] elements may only exist once! Either overwrite the elements in instanceB.xml with the elements in newbackup-translated.xml or simply don’t copy them.
- The most difficult task: Alter all workflows prior to coping them over. There are 3 xml values that need to be changed. For the first two elements with a number >= 10000, place “222″ in front of it. For the last one the number should be > 13
- <meta name=”jira.status.id”>10000</meta>Â TO <meta name=”jira.status.id”>22210000</meta>
- <meta name=”jira.fieldscreen.id”>10010</meta>Â TO <meta name=”jira.status.id”>22210010</meta>
- <arg name=”eventTypeId”>16</arg>Â TO <arg name=”eventTypeId”>22216</arg>
- OptionConfiguration –> should point to the existing Default Issue Type Scheme
AFTER IMPORT
- Go to “Permission Schemes” > “Default Permission Scheme” and remove all duplicate permissions
- Go to “Issue Types” > “Issue Types Scheme”-tab and remove the 2nd un-associated Issue Type Scheme from the list.
- Go to “Screens” –> Default Screen, Resolve screen e.d and clean up the duplicate Field Tab’s
LOST INFORMATION
- The SearchRequest elements are not copied to the newbackup-translated.xml file. The content is XML and it is too hard to change that during the copy process. Therefor all users with a custom portal page will loose their custom defined filters.
FILES
Pingback: JIRA: Information Officer LLC
Hi,
Parser.xsl is listed as one of the files in this topic. The saxon8.jar is a different story. That file can be downloaded from SourceForge http://sourceforge.net/project/showfiles.php?group_id=29872&package_id=21888
Thanks. I’m glad i’m able to help somebody with this “tool”. I will wait with any further improvements as Atlassian itself is currently implementing some kind of backup and restore functionality for individual projects. I hope their solution will be more advanced than this script
Pingback: links for 2008-06-26 « The Adventures of Geekgirl
I was referred to your site to merge 2 Jira instances. I used the tool and followed the instructions, using v3.13.1. Works pretty well, mostly. I noticed that Project Roles were lost, which affects the notification scheme and the permission scheme. This will require quite a bit of post merge cleanup work. Is this a known issue? Is there a work around?
Also, is there a script to update the attachment names, for a windows based system?
Other than that, it is mostly removing duplicate issue types, priorities, resolutions, etc.
Thanks
Russ
Hi Russ,
Due to the effort that Atlassian has put in restoring and backup of single projects, this tool is no longer maintained. Also the Project Roles are new features right?
Perhaps you can have a look at the new version of jira
The new version of Jira does have single project import, but that still leaves one to manually migrate (or recreate) all the users, fields, screens, permission, workflows, schemes, etc. I was hoping to use this tool to accomplish that.
I see. I didn’t knew that. Perhaps it is worth it to keep this tool alive. If i can find the time i will see what i can do.
The new project import process is outlined here – http://www.atlassian.com/software/jira/docs/v3.13.2/restore_project.html
Note that before you import that project you need to manually create the users, workflows, custom fields, groups, roles, workflow schemes, screens, screen schemes, status, issue types, priorities, resolutions, permission schemes, notification schemes, field configuration schemese, etc.
So all you get from the import tool is the project data, versions and components. The rest has to be there before you import. So it is better than nothing, but still an incomplete solution.
Does thie method can work for two 4.0.1 jira instances? I have checked the doc about Project Import from http://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup, but seems it needs a lot of work to manually change something.
By the way, where can I get the file parser.xsl?
I have stopped working on this procedure the moment Atlassian has implemented its own restore procedure. It is still a very time consuming activity to restore individual projects from a backup.
The parser.xsl is in de file-list at the bottom of this post.
did do the merge but i get now a problem when closing an issue: the fix version number is not saved. same issue when editing the fix version number. the only way it works is when opening a new issue.
got it fixed: Go to “Screens” –> Default Screen, Resolve screen e.d and clean up the duplicate Field Tab’s
Pingback: Confluence: JIRA 4.0
Pingback: Confluence: JIRA (??) ????