Migrating projects - maintain issue keys

[Anna Henke]

From the article around images on the Boards on the new Agility projects a question has come up that would be interesting to discuss:

As using new features that come with the project template is not possible for other types of projects, Atlassians suggestion is to migrate an existing project to a new project of the desired type that supports the new boards for example.

My expection that issues get new IDs was already confirmed, but this is a blocking issue for us for several reasons:

1.  We refer to issues from other ALM tools (like Jama which we use as our Requirements Engineering Tool) via http-links
2. We refer to those IDs from external documentation which is not connected to Jira anymore
3. We have integrated Jira and Jama via Tasktop - I strongly assume that an integration would break when the Jira side is being migrated to another project

I know that when moving an issue from one project to another (which I assume would happen when migrating a complete project) the http-addresses still work as they are redirected to the new, migrated issue - this would probably be an acceptable workaround for the first use case.

Maintaining at least the numbers (the second part of the issue-id) would be considerable for the second use case.

The ideal use case though would be that the issues remain as they are, with their internal ID and their issue key. 

I am quite sure to have missed other pitfalls - maybe we can start a discussion here on how users with "legacy" projects can also benefit from new features without messing around with ID-changes.

Anna

[Martin Varga]

Ok the bad news is that this is not possible right now. It is a valid concern. I've looked into existing possibilities. But neither the issue move nor the issue import/export worked.

The issue move can change issue numbers, for example if you have deleted an issue before and have a gap in the numbers.

There is a workaround using the export/import. It is possible to export all issues to CSV, then import them to a new project. It will create new issue keys with different numbers, but it is possible to map the old issue key to a new field. Agility projects now allow you to create new custom fields. But it is far from ideal, because you issues will have completely new issue keys/numbers.

I've raised this feedback with the teams working on the new projects. I'll try to keep you updated. Hopefully we can add some kind of painless migration in the future.

[Paul]

@Martin Varga , any updates on this? Our IT folks are about to migrate from one Jira installation to another and plan to break all of our keys. Is there any way to preserve the key? Alternatively, is there any way to map the key to a custom field so that we'll at least have a record of what the key was?

[Itamar Ben Sinai]

@Martin Varga 

Same here,

Please open a feature request, and share with us

Thanks

[Darren Houldsworth]

If you import with CSV or JSON, you can specify the issue number. I just migrated 50,000+ issues from one instance to another and kept all the keys. During the migration I did have to change project keys for some, and I scripted the JSON import file generation and was able to modify references in description and comments too. It is possible, but take a little bit of work.

;D

[Henry Chad Apale]

Hi @Darren Houldsworth , wanted to follow-up with you on how you did this and elaborate on how to maintain issue-keys upon migration.

I'm currently trying to migrate next-gen project into a classic, and maintain the issue-keys to be exactly the same. I have found that bulk-moving issues into another project will mess the ordering of the issue-keys. After deleting the next-gen project, I also found that  renaming the classic project's issue into the same issue key of the next-gen might break the link aliases since issue-key number won't match.

Would appreciate any advice 

[Darren Houldsworth]

Moving will move an issue from one project to another and use the next key number in the target project.

What you need to do is export the old project issues into JSON, edit the issue keys to reflect the new project key, then JSON import. The JSON import will respect the "key" tag and number it accordingly.