-
Suggestion
-
Resolution: Unresolved
-
2,249
-
141
-
Hi everyone,
Thank you for taking the time to share your feature request with us. Your input is greatly appreciated, and we understand the effort and dedication it takes to provide us with your thoughts and ideas.
we plan to launch an EAP in mid Dec 2024 to address handling of duplicated Jira config entities, refer community post for more details and to sign up to early access.
Regards
Rahil Hameed
Senior PM - Cloud Transitions
Issue Summary
When migrating a single project to a site the first time using C2C method, a new custom field will be created with (migrated) appended in their name.
This is reproducible on Data Center: N/A
Steps to Reproduce
- Choose a destination site where C2C migration has not been performed yet.
- In the source site, select a project and perform a C2C migration to the destination site.
- Go to Settings > Issues > Custom fields
Expected Results
If the custom field in the source and the destination sites have the same name, and underlying properties, they should be merged in one custom field to avoid unnecessary duplicates.
Actual Results
If the custom field in the source and the destination sites have the same name, and underlying properties, a new custom field is still created in the destination site with (migrated) appended on the name.
Workaround
Currently there is no known workaround for this behavior. A workaround will be added here when available
- duplicates
-
JRACLOUD-82726 Broken system field's description after migrating a team-managed project through the Migration Dashboard.
-
- Closed
-
- relates to
-
- In Progress
-
- Gathering Interest
-
MOVE-1737159 You do not have permission to view this issue
- resolves
-
- Closed
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[JRACLOUD-82762] C2C migration of a single project creates duplicated custom fields with (migrated) in their name
Hi,
I am the product manager of C2C. Thanks for raising this concern. We do understand duplication is a major concern area and we are making significant investments in our architecture which will solve this in the future.
However,tThe current state of solution is in alignment with https://support.atlassian.com/migration/docs/how-cloud-to-cloud-migration-links-data-between-sites/,
If an entity in your migration has the same name as an entity in the destination site, we'll create a new entity with the original name and a “(migrated)” tag. We’ll then migrate your data along with this new entity.
Jira cloud is designed to allow two custom fields with the same name, type, and association with the same set of projects, screens, and configuration schemes. However, they will still be treated as separate entities. So this is expected behaviour.
Admittedly, this may not align with your expectations and poses a challenge when it comes to migrations. Unfortunately, due to the current design of the cloud, it would be quite complex to modify this behaviour solely for the purpose of migrations.
In light of this, we have decided to convert this JAC into a suggestion ticket. This will allow our customers to express their support for this change by upvoting it. We'll be watching the response closely and will take suitable action based on the interest shown by our users. We truly value your input and appreciate your understanding in this matter.
Also effecting another entitiy Worklog raised under different bug
Issue Summary
Migrating a Team-Managed project to a different site through the Migration Dashboard leaves the system fields with an undesired description that can't be modified.
Example: (Migrated project)
The system field description has the value "(Migrated on 5 Jan 2024 17:26 UTC)".
Steps to Reproduce
Open the Migration Dashboard.
https://yoursite.atlassian.net/jira/settings/system/migration/dashboard
Migrate a Team-Managed project to a different cloud site.
Wait until the migration is completed.
Open the Team-Managed project that was migrated to the new site.
Open the project settings > issue types > select any issue type.
Expand any system field and check its description; it will show additional information about when it was migrated, and its information can't be modified.
Expected Results
No additional information should be added to those fields, or the administrators should have access to remove this information.
Actual Results
The additional migration information added to those field descriptions can't be modified since they are system fields.
Workaround
There is no known workaround so far.
This is an issue for me. Migration is creating a duplicate Acceptance Criteria field. I need to keep both a Acceptance Criteria field and Acceptance Criteria (migrated) field. This requires dedicated schemes for screens, etc ratehr than shared.
I did think of a solution though. I did notice that, as I did three migrations, only one new Acceptance Criteria(Migrated) was created.
Solution 
. What if I
- changed the names of the custom fields in the target instance prior to doing the migration. Eg Acceptance Criteria to Acceptance Criteria(Migrated)
- Performed the migration. Hopefully all the data would be added to the Acceptance Criteria(Migrated) custom field
- Then change the Custom Field in the Target back to Acceptance Criteria
Would this work? Would all the data in both the Target and the migrated project be merged under the same custom field? Would all the data in the Target be overridden by the new Custom field?
I may try this in Sandbox to see if there are any consequences
f59a47fa52a5 We are unable to sign up for the EAP program. I have gone to the portal as soon as i saw this update. Please help.