Print
Jira Migration

Overview

The 10,000 foot view is that we will pull data from the source JIRA via the XML-RPC, RSS, and some HTML (for subtasks and attachments) and use it to create a Jelly script which can be run in the destination JIRA via the Jelly runner.

The 1,000 foot view is that you'll simply run the jira-to-jira.vm script via the Swizzle Jira Report tool, save the Jelly output and run it in your destination Jira. Here is an example Jelly output for the curious.

Things you must know

What gets moved

  • Project
  • Versions
  • Components
  • Issues
  • Subtasks
  • Comments
  • Attachments
  • Users (reporters and assignees only)

Limitations

  • Custom fields not migrated
  • Links between issues are not migrated
  • Issue Watchers not migrated
  • Permissions Scheme not migrated (a "starter" scheme will be created)
  • Groups not migrated (a yourproject-developers group will be created, anyone who's been assigned an issue will be added)
  • Notification Scheme not migrated (the jira default will be used)
  • Possible limit in the number of issues that can be exported via RSS

If you run into an issue limit, send a note to the swizzle user list and we should be able to figure something out for you.

Assumptions

  • You are not using HSQL as your DB on the destination JIRA
  • XML-RPC is turned on in the source JIRA
  • Issues are publicly viewable (attachment and subtask data fetched via html) in the source JIRA
  • The required Issue Types are available in the destination JIRA with the same name
  • You have file system access on the destination JIRA

Doing the Migration

  1. run the export script via the swizzle-jirareport tool
  2. run the resulting jelly script
  3. restart and reindex

Generating the jelly script

Download the swizzle-jirareport jar and run this command:

 
$ java -jar swizzle-jirareport-1.2-dep.jar http://svn.codehaus.org/swizzle/trunk/swizzle-jirareport/src/main/resources/jira-to-jira.vm

That should print out an error containing the following help text:

java.lang.IllegalArgumentException : Invalid or missing arguments.
  [MISSING]    username    : the username to be used for XML-RPC authentication. Must Match Pattern '[a-zA-Z0-9]+'
  [MISSING]    password    : the password to be used for XML-RPC authentication. Must Match Pattern '[a-zA-Z0-9]+'
  [MISSING]    projectKey    : the JIRA key of the project to import from. Must Match Pattern '[a-zA-Z0-9]+'
  [MISSING]    serverUrl    : the base URL where jira is available, no trailing slash. Must Match Pattern 'https?://.+'
  [MISSING]    jiraAdmin    : the username of the JIRA administrator doing the import. Must Match Pattern '[a-zA-Z0-9]+'

These are the parameters you need to supply. It should also be noted that you can download the 'jira-to-jira.vm' file and run it locally. If you feel brave, you may modify it as you like (definitely consider contributing any modifications back for the benefit of others).

Supplying parameters is done by simply passing them as -D options anywhere on the command line. When you run script with the full parameters, it will spit all the output to System.out, so you'll want to pipe that into a file.

$ java -jar swizzle-jirareport-1.2-dep.jar ./jira-to-jira.vm -Dusername=joe -Dpassword=cool -DprojectKey=PEANUTS \
                                           -DserverUrl=http://jira.acme.org -DjiraAdmin=administrator > peanuts.xml

When that is done running, all your attachments will have been saved in your tmp directory (grep the jelly for 'jira:AttachFile' if you're curious). If doing the import on a different machine, you will need to copy all the attachments over to the same file path on that machine.

Running the Jelly script

Login into jira via the exact same user you specified via the -DjiraAdmin option. This use should have jira administration rights.

Browse over to the "Jelly Runner" section. Follow any instructions to enable the Jelly Runner if it isn't already enabled.

Run the jelly script you created in the previous step.

It is a really good idea to save the output of that run as it is a complete record of what issues where added, what their old primary key was and what their new primary key is. If you ever want to port more data by hand, this data will come in very handy. Here is some sample output:

<JiraJelly xmlns:jira='jelly:com.atlassian.jira.jelly.enterprise.JiraTagLib' xmlns:j='jelly:core' xmlns:sql='jelly:sql'> 
  <issues> 
    <issue dest-id='10420' src-id='40099' src-key='SWIZZLE-1' dest-key='SWIZZLE-1'/> 
    <issue dest-id='10421' src-id='40911' src-key='SWIZZLE-2' dest-key='SWIZZLE-2'/> 
    <issue dest-id='10422' src-id='40912' src-key='SWIZZLE-3' dest-key='SWIZZLE-3'/> 
    <issue dest-id='10423' src-id='40913' src-key='SWIZZLE-4' dest-key='SWIZZLE-4'/> 
    <issue dest-id='10424' src-id='40914' src-key='SWIZZLE-5' dest-key='SWIZZLE-5'/> 
    <issue dest-id='10425' src-id='41274' src-key='SWIZZLE-6' dest-key='SWIZZLE-6'/> 
    <issue dest-id='10426' src-id='41275' src-key='SWIZZLE-7' dest-key='SWIZZLE-7'/> 
    <issue dest-id='10427' src-id='41276' src-key='SWIZZLE-8' dest-key='SWIZZLE-8'/> 
    <issue dest-id='10428' src-id='41277' src-key='SWIZZLE-9' dest-key='SWIZZLE-9'/> 
    <issue dest-id='10429' src-id='41278' src-key='SWIZZLE-10' dest-key='SWIZZLE-10'/> 
    <issue dest-id='10430' src-id='41279' src-key='SWIZZLE-11' dest-key='SWIZZLE-11'/> 
    <issue dest-id='10431' src-id='41280' src-key='SWIZZLE-12' dest-key='SWIZZLE-12'/> 
    <issue dest-id='10432' src-id='41757' src-key='SWIZZLE-13' dest-key='SWIZZLE-13'/> 
  </issues> 
  <attachments> 
    <attachment dest-user='dblevins' src-user='David Blevins' dest-id='10020' file='ONE.patch' src-id='22972'/> 
    <attachment dest-user='dblevins' src-user='David Blevins' dest-id='10021' file='THREE.tar.gz' src-id='22975'/> 
    <attachment dest-user='dblevins' src-user='David Blevins' dest-id='10022' file='TWO.txt' src-id='22973'/> 
  </attachments> 
</JiraJelly>

Special note on the dest-key attribute. If you've deleted any jira issues in your source jira, then these issues are not added to the destination jira and the keys will start to drift. The dest-key attribute represents the new key of the issue as it exists when it's immediately added to the new jira. However, fear not as the very last phase of the script is to update all new keys so the are the same as the original key.

Restart and Reindex

If the import did not go successfully, you can simply delete the Project as well as the Groups and Permission Scheme added and try again.

Assuming all went well, you'll need to restart Jira to flush any data cached in memory. When jira comes back up, you'll then need to log in as an administrator, go to Administration->Indexing and click the "Re-index" button. When that is done, you should be good to go.

At this point you'll just want to recheck your Permissions and Groups as well as setup any Notification Scheme you may need.

Powered by Atlassian Confluence