Hi,
I've been having some issues trying to migrate from our existing Team-Managed project to a Company-Managed project. I've tried all kinds of things found on the Atlassian forums and have ran into road blocks with everything.
I'm now embarking down the following path:
Not the biggest fan of this approach and was hoping there was an easier way to do this migration; however, I've been spinning my wheels for over 2 weeks now so I was hoping someone may have some insight into this.
Thanks,
Brennan
Hi @Brennan Karrer,
Choosing the wrong project type and realising it too late unfortunately leads to these scenarios. I hope you have found this support article which lists:
If you have some kind of way to select the issues that you would need to update the custom fields from, you could consider bulk updates too, but your approach is not far off the best way to get things fixed.
Hope this helps!
About the custom fields, @Brennan Karrer - custom fields in team managed projects are set up only in those projects and not shared across Jira. The are silos, if you look at them. And, as the documentation states: you lose custom field data when you migrate to company managed projects, where you have to re-create them:
Custom fields: If you use custom fields in your team-managed project, a Jira admin needs to recreate the fields and add them to screen schemes and field configurations in your company-managed project. Custom field data will need to be recreated, otherwise it will be lost.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yeah I remember seeing this and was hoping by setting up the new project to have the same field type it would be possible to migrate this data over.
At this point, it sounds like my only option would be to perform something to what I stated above?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That indeed, or updating them via bulk change or manually. Any way you look at it, you will need to fill out the values again in the new field, in the new project.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Is there any safer path forward for this? I'm hesitant doing the bulk move knowing that field will be dropped. The export/import seems to be a safer approach, but I could not get attachments to work for the life of me and issue links would sometimes get updated to point to the new issues in project B and other times would still reference the issues in project A.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sounds like you're going to have to do both methods:
1. export Project A's issues into CSV to get values of Acceptance Criteria.
2. Bulk Move issues from Project A to Project B.
3. export Project B's issues to CSV.
4. CAREFULLY perform surgery on project B's CSV file to add Acceptance Criteria from project A's CSV file.
5. import project B's CSV file to update Acceptance Criteria.
At least, I think it will work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Gotcha. Yeah it seems like a bit of a convoluted process so just wanted to make sure I wasn't completely off track here.
Thank you both for the verification here and I will be proceeding with this approach.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi guys - I've had some success with this since my last post which I thought may be worth sharing. The Jira Deep Clone plug in appears to allow you to clone issues from a Team Managed Project (TMP) to a Company Managed project (CMP). If your workflow states and custom field names match exactly between the source TMP and the target CMP, it clones the issues from one project to the other and copies all data across successfully. This works inclusive of issue hierarchy, story points (which it maps from "Story Point Estimate" in TMP to "Story Points" in CMP) and sprints if you tell it to. It appears to overcome the issue move limitations Jira has natively when shifting issues between project types.
For our use case, the configuration was designed to be an exact match between the TMP and CMP to start; and therefore this has allowed us to replicate everything in a TMP in a CMP without much intervention. Furthermore, because it clones the source issues in the TMP to the CMP, it provides data redundancy which mitigates any risk of data loss you otherwise can come across when you "physically" move the issues between projects.
Hope this helps
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Brennan Karrer - I am facing in to the same issue. 7 team managed projects which existed before I worked here which need to move to company managed projects to drive greater consistency and workaround wider limitations with team managed projects and advanced roadmaps. Could I check, is the "Acceptance Criteria" field in your use case a custom field? Similar to you, I have replicated all team managed custom fields as system wide custom fields in the hope there would be an automatic way to map the values if the field names and types matched between project types. However, this appears not to be the case and I am also likely looking in to having to move the issues and then back populate the custom field data through CSV update. If you've since found a better way to do this, it would be great to hear it. Failing that, I have a tedious week coming up! Thanks
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey @James Akers
Unfortunately I'm in the same boat as you, and the "Acceptance Criteria" field seems to be a different custom field on each project. I have a working node script to execute a cross-reference check for the issues moved to the new project and the original CSV file of exported issues to update each moved issue with the original "Acceptance Criteria". Happy to share it assuming it all works as expected, about to execute it today.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Brennan Karrer . I thought you would confirm that was the case. Fun times all round. If you are happy to share the script that would be grand. Thanks for coming back to me. Best of luck with the execution today.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Brennan Karrer
As far as I know, the main method of migration is your option "B": creating a company-managed project and performing a bulk move from project A to project B.
As far as the field disappearing, did you create a custom field that's the same as "Acceptance Criteria" and associate it to project B's screens?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There's an Acceptance Criteria field that already exists for project B's screens. The one thing I did just notice is the Acceptance Criteria field for project A is `customfield_10036`, whereas the Acceptance Criteria field for project B is `customfield_10133`. I'm assuming this is where the Jira migration is having an issue?
Not sure how to map these two properly though since no option is given when moving issues from project A to project B.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Brennan Karrer ,
I know you mentioned that you checked the forums, but just to double-check, did you review this?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have reviewed the above document several times now, but maybe I'm missing something in regard to the Custom Fields portion?
Acceptance Criteria is a custom field on project A and a custom field on project B; however, they have different key values for the fields.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.