nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Safest way to migrate tickets to a new project

Randell Pelak_d0ufpy

So, we need to convert our team managed project to a company managed project. And let's just say this is my first week or two as a Jira admin. We don't have any real jira admins.

Soooo. I want to do this as safely as possible. But from what I can see, once you setup the new project, you "move" the tickets over. And it things get messed up you are just out of luck. Is there some why to make a backup or something like that? My first trial run with a few test tickets wiped out an entire field, even though I had told it to retain. We have like 13k tickets. So no way to "fix" them all after the fact.

Also... while it is doing the move, will it lock down the old project and tickets so people can't make edits or what not?

Accepted answers

Randell Pelak_d0ufpy

So overall, I have come to the conclusion that Jira doesn't want to directly support doing this. Ticket move limits are 1000 issues, same with csv exports. And if an epic falls in one batch, but it's issues in another... things go badly. And of course custom fields are a ton of extra work.

So they direct you to team managed fields by making it the default, but don't give you a way out when you grow to need to move beyond the restrictions they have. There was something with timelines that wouldn't support more then 500 issues or something as well as others that are driving us to change, even though we only have one project.

The "solution" I am going to try is the deep clone app. I feel like I shouldn't need an app for this, but I just don't see another option.

All comments

Trudy P Claspill

Addressing the simpler, second question first - no, the Move of issues does not lock down the source project.

Regarding your question about backing up the data before you move it, Jira natively provides a backup process that generates and XML file, and support "importing" that XML file as a method to restore your Jira data. However that is for the entire Jira system, not for individual projects.

If you want manage a backup with the ability to restore for a single project, you'll need to look at third party apps. I have not used any such apps myself. Revyz is one vendor that provides a backup/restore app. They have an article on the pros and cons of the native backup, which includes a link to their product in the Atlassian Marketplace.

https://www.revyz.io/blog/pros-and-cons-of-using-jira-cloud-database-backup-restore

Concerning the moving of the issues, have you already reviewed this information?

https://support.atlassian.com/jira-software-cloud/docs/migrate-between-team-managed-and-company-managed-projects/

Something I recommend you consider is if you really need to migrate the data to a new project. The "safest" path forward is to not move the issues at all and instead start fresh in the new project. Have you considered instead starting fresh with the new project? Can you at least leave the issues that are already closed in the existing Team Managed project? How many not-closed issues would that leave you needing to migrate?

The nature of Team Managed projects is to allow customizations in the project without impacting any other project. Because of that the fields in Team Managed projects don't necessarily automatically map to same-named fields used in Company Managed projects.

One way you can reduce the loss of data is to create Global Context fields that are set up in the same way as project-specific custom fields you added to the Team Managed project. Add those Global Context fields to both your Company Managed project and your Team Managed project. Then, in your Team Managed project, copy the data in the project-specific custom fields to the comparable Global Context field within the Team Managed project. Do that prior to the move of issues. With the data added to Global Context fields in your Team Managed project, the data should migrate successfully to those same Global Context fields in your Company Managed project.

Another option to consider is to export as much of the issue data as you can prior to moving the issues. There are issue data export options available for the search results you get in the View All Issues screen. That screen does limit the number of issues in your search results to no more than 1000, so you would not be able to export all 13k issues at once. With that export (particularly if you use the CSV format) you could later use a CSV import update the issues post-move, restoring data that did not successfully come through the move.

Randell Pelak_d0ufpy

Thanks for the info.

Is there a way to lock a project or even everything but still be able to do the bulk move?

Sadly, starting fresh is not an option. Too many open tickets with a lot of work spec'ed out for the future. But we could in theory move less.

You mention the csv export/import. Do the tickets have some kind of unique identifier that stays with them on a move? Like if I export to csv, then do the move and say only one field is messed up. I could write a script to fix the tickets if I could map the exported ticket to the ticket in the new project.

Randell Pelak_d0ufpy

The "solution" I am going to try is the deep clone app. I feel like I shouldn't need an app for this, but I just don't see another option.

Trudy P Claspill

The absolute unique numeric identifier for the issue should remain unchanged by a Move operation. You can see the unique identifier for an issue using a REST API call like this:

https://tclaspbiz.atlassian.net/rest/api/2/issue/<issue key>?expand=names

The first part of the returned data looks like this:

"expand":"renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations,customfield_10010.requestTypePractice","id":"10949","self":"https://myInstance.atlassian.net/rest/api/2/issue/10949","key":

The part I changed to bold is the unique identifier.

A way to lock the source project would be to change the permissions associated with it so that nobody had any permissions to modify the content.

I have heard recently (just yesterday) that Atlassian has been investigating improvements in the "migration" of projects from Team Managed to Company Managed, but I don't have any details or timeline information I can share.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

migration

jira-cloud