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

[Andrew]

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.

[Andrew · Accepted solution]

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.

[MattS]

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?

[Bhushan Nagaraj]

Do we have an answer to this?

[Azfar_Masut]

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

[Daniele Gagliardi]

Hi all, even though this is an old post, I'd like to share my findings: it is still possible search an issue using its old key. I found it empirically, and then I also found a documentation section giving an hint in this direction: https://confluence.atlassian.com/adminjiraserver075/editing-a-project-key-935391076.html#Editingaprojectkey-changesNotesforchangemanagement

"The old project key can be used in JQL queries — Users won't have to update issue filters that reference the old project key."

So if you simply change your project key or if you move your issues in a new project (this last one was my case) you can still use the old key to search your issues.

[Deleted user]

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

[Andy Nguyen]

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.