Renaming and importing a project: where has the old project key history gone (redirects, search)?

Andrew Lui Atlassian Team Jan 30, 2014

If I rename a project, then import the project into another JIRA instance, I can't do any operations using the old project.

For example, I cannot search for issues in the project, using the old project key.

3 answers

1 accepted

This widget could not be displayed.
Andrew Lui Atlassian Team Jan 30, 2014

If you import a renamed project, it doesn't retain the history of old project keys. This means that operations using the old project key won't work.

For example, if you rename a project from CAT to DOG, you normally can search for an issue (e.g. DOG-123) by using the old project key (e.g. CAT-123).

If you want to keep this information when importing the project to another JIRA instance, you will need to do the following:

  1. Query your database to find the moved_issue_key and project_key tables for your project in your original JIRA instance.
  2. Manually copy the contents of the two tables to the moved_issue_key and project_key tables for your project in your target JIRA instance.

Andrew, given that all the attachments are stored in a directory named for the old project key, how does a project import know which directory to use for the imported project's attachments?

Do we have an answer to this?

During xml creation of the backup, the attachments will be mapped based on the new key.

Once imported into the new instance, it will no longer refer to the old key nor store any date regarding the old project key, and attachments are stored in the folder with new key as it's name

This widget could not be displayed.
Andy Nguyen Atlassian Team May 27, 2015

Just to add on a note to Andrew's answer, that moved_issue_key table links old issue keys to their issue IDs. The high chance is that, upon a project import, the issue IDs are no longer the same as in the source instance, causing the links to be incorrect. Because of this, one should not simply copy the contents of this table from the source to destination database. It's advised that correct issue IDs are manually identified, by running a query like this in the destination database (using the new issue key e.g. DOG-123):

SELECT id,issuenum,project,reporter,assignee,creator,summary,description FROM jiraissue where issuenum = 123 and project = (select id from project where pkey = 'DOG');

The correct issue ID of DOG-123 will be identified, and that ID should be linked to the old issue key (CAT-123) in moved_issue_key table.

This widget could not be displayed.

Even if this issue is almost 2 years old it helped me a lot when I had to perform this task. Since there are some aspects missing I just want to share my experience with you all.

My steps for changing the project key

There's no guarantee that it'll work for you. Assumptions: The project key of the old project is OLD and it is about to be changed to NEW

  1. Backup JIRA
  2. Create a dummy project NEWDUMMY with a shared configuration of OLD. It will be deleted at the end and prevents autmatic deletion of unreferenced settings.
  3. Save the users and roles definition of OLD and then remove all users except you to prevent any changes during the process.
  4. Rename the project key in JIRA from OLD -> NEW
  5. Backup everything relevant to the project.
    1. Copy JIRA Application Data\data\attachments\OLD to JIRA Application Data\import\attachments\OLD. We need this for the reimport
    2. Copy IRA Application Data\data\avatars to to JIRA Application Data\import\avatars. I'm not sure if we need this.
  6. Backup JIRA again containing the project with the new project key. Better if you backup everything, but not necessary.
  7. Save the row of OLD from the table project_key. This statement generates a suitable insert command. It's written for MSSQL so you might have to adapt it.
    select concat('INSERT INTO [dbo].[project_key] VALUES (',[ID],',',[PROJECT_ID],',''',[PROJECT_KEY],''');')
    from [project_key]
    where [PROJECT_KEY] = 'OLD' -- Replace OLD according to your project key
  8. Delete project OLD (now with the key NEW) in JIRA
  9. Reimport project in JIRA
    1. Create a new project with the key NEW using the shared configuration with NEWDUMMY
    2. Restore project specific settings to NEW. Fortunately you have NEWDUMMY for reference.
    3. Import project in JIRA (System -> Project import) by providing the Backup of step 6. You have to copy it to import directory on the server before.
    4. Select project NEW for import
    5. JIRA executes extensive validations and will tell you if you forgot something.
    6. Import
  10. CAUTION! Now you have to adjust the JIRA database manually and you're leaving the safe ground of JIRA out-of-the-box tools.
    1. All the following steps were carried out on a MSSQL 2012 database. If you have a different database it's very likely that you have to adapt the statements.
    2. Stop JIRA
    3. Restore entry in table project_key by executing the insert of step 7.
    4. Insert the former issue keys in the table moved_issue_key for the automatic redirection mentioned by @Andrew Lui. I used this statement.

      INSERT INTO [dbo].[moved_issue_key]
                 ([ID]
                 ,[OLD_ISSUE_KEY]
                 ,[ISSUE_ID])
                  SELECT coalesce(const.maxs, 0) + row_number() OVER (order by (select NULL)) ID
                          ,('OLD-' + cast(issuenum as varchar(5))) as issue
                          ,[ID] as ISSUE_ID
                  FROM [dbo].[jiraissue] cross join
                      (select max(ID) as maxs from [dbo].[moved_issue_key]) const
                  where [PROJECT]=(select ID from [dbo].[project] where pkey = 'NEW')

      It's definately a good idea to test the select in advance to check if the result is plausible. You have to replace "OLD-" by your old key and don't forget the trailing "-" as well as NEW has to be replaced by your new project key (no "-").

    5. This is not enough because JIRA remembers a sequence number for the ID of this table and doesn't know about the new rows. As a result the next move would cause a primary key collision. Therefore the value of MovedIssueKey in the table SEQUENCE_VALUE_ITEM has to be set greater than

      select MAX(ID) FROM [dbo].[moved_issue_key]

      JIRA sets this number always to the next value roundet up to 100. (e.g. 12345 gets 12400)

    6. Fire JIRA up
    7. Reindex
  11. Restore the user access
  12. Check everything
  13. Delete NEWDUMMY
  14. Done

This worked for me using JIRA 7.1.6. There may be circumstances I currently not see that might break this process but it worked for me this way.

 

Hope this helps

Happy renaming

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Wednesday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

85 views 1 0
Join discussion

Atlassian User Groups

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!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you