How to split an existing project in two, keeping worklogs and versions intact?

Hi there,

I have a project with about 60 Epics and 100 versions.

About 75% of the issues in the project relate to 2013 work. We would like to 'split' the project in 2, so that I have PROJECT 2013 and PROJECT 2014.

However, if I move all of the 2014 issues from PROJECT 2013 to PROJECT 2014 I lose the FixVersions.

One of the drivers for doing this is because when a user creates a new task in the current project, they have 60+ Epics to select from (Epic Link needs to be mandatory for issue creation for this projct) and this is cumbersome.

Any suggestions? I want my worklogs and FixVersions to remain intact!

Thanks

1 answer

1 accepted

You can try to create a clone of the existing project into a new one and then remove everything that is not needed from both projects (the 2013 and 2014).

Create an xml backup of JIRA and then replace the project key (i.e. PR) with a new one (PRI). The patterns you need to search are (not sure these are all though)

  • key="PR
  • projectKey="PR"
  • key="PR"
  • originalkey="PR"

After replacing these in the entities.xml try do Project Import from backup. This will create a new project with key "PRI" which should be the same as the "PR" project. Then remove all that is not needed.

NOTE: This is not tested and is a solution that "might" work, so I'm not sure if JIRA Agile will work correctly after that with the new project and if actually the JIRA Agile data will be properly cloned, so you have to have a backup of your system in case something goes wrong or test this on a snadbox/test/staging JIRA instance.

Some plugins like CLI or Script Runner provide clone functionality and you may also try to do the clone using them.

Hey Boris - looks like that Script Runner plugin will work for me. Thanks for your answer.

Hey Boris

Turns out this doesn't work because worklogs aren't copied. Any other ideas??

Yes, it doesn't clone the worklogs for the tasks?

Do you mean Script Runner ?

And a possible way to avoid editing the backup xml manually will be to restore the JIRA backup onto another JIRA instance, change the project key and then create a backup again which to use for import into the original JIRA, but into a different project

I suspected that it will not copy worklogs and that's why I've suggested using project backup/restore approach.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,944 views 12 18
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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot