How to avoid losing custom field values when moving from a classic to a next gen project.

[Jon Linn]

I have 2 projects in jira cloud.  p1 is classic, and p2 is next gen.

I have the same fields in both projects, even though jira treats them as different. (having different underlying IDs)

When I move an issue from p1 to p2, all the values for any custom field are lost.  It doesn't matter whether I do a single or bulk move, and doesn't matter whether I try to retain values, or let Jira handle it.

Is there a way to have customer fields that are named the same be treated as the same field so that the move can occur properly?  Or can I map the custom field in p1 to the fields in p2?

[Nic Brough -Adaptavist-]

This line is the problem:

>I have the same fields in both projects, even though jira treats them as different. (having different underlying IDs)

The fact they have different "underlying IDs" means that they are different fields not the same field. 

You lose data because the first field is not present in the target project.

You can't "map" them, you need to use the same field throughout, or write something that will copy the data from one field to the other.

[Daniel Tomberlin]

I just discovered that a Classic project issue that I moved into a NextGen project so I wouldn't lose track of old bugs does not show fields I had on the issue when it was Classic. For example, I had fields for Support Vender and Supoort ID, but those are not displaying and when I go to Configure the fields are not available to find, like when I Configure other projects (classic I presume). So..

1. Shouldn't I at least be able to find an existing field in NextGen? Unlike Classic, I see what seems to be nothing but adhoc field creation just to the project.

2. Also, why would a Move "lose data," like my values are completely lost!? Seems like a bad practice. The data should still be in a table in the database and when we show a field that value is queried and seen.

I'm beginning to think if I setup a project to hold issues for future development I should make that a Classic Project since there is moving of issues involved.

[Nic Brough -Adaptavist-]

I think it's important to understand that Jira Classic and Jira Next-gen projects are very very different things and handle things like custom fields very differently.  The custom fields you see in Classic projects simply do not exist for Next-gen, they're a different structure, a different table, and hence different things.  That's why they have different ids - they're different objects.

[Gael Lambert]

I have the same problem. The field exist in the target project but during move setup the mapping doesnt display them.