How can I successfully migrate from a Team-Managed to a Company-Managed project?

Brennan Karrer November 14, 2022

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.

  • Exporting from the Team-Managed and attempting to use the External Import functionality results in attachments not working properly in the new Company-Managed project.
    • Even tried manually updating the CSV file to contain a username + PAT combo for ensuring the attachments are properly ported over, but that did not work.
  • Moving issues between boards would be ideal; however, no matter what I try to do, the Acceptance Criteria field is always deleted. My new board has the proper workflow in place and Acceptance Criteria is a field defined on all of the issue types, so not sure why this field gets deleted.

I'm now embarking down the following path:

  • Export all issues from Team-Managed Project to CSV.
  • Move issues from Project A to Project B with JIRA's default functionality.
  • Cross-reference original CSV file to find moved issues and use the RESTful API to update each of the moved issues with the original Acceptance Criteria that gets deleted when moving between projects.

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

5 answers

1 accepted

3 votes
Answer accepted
Walter Buggenhout
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 14, 2022

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:

  • the recommended steps to migrate
  • the data that is - unfortunately - lost in the process

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! 

Walter Buggenhout
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 14, 2022

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.

Like # people like this
Brennan Karrer November 14, 2022

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?

  1. Export original issues to CSV.
  2. Move all issues from Project A to Project B while losing acceptance criteria in the process.
  3. Cross-reference original CSV file Acceptance Criteria and update all issues in Project B with the original Acceptance Criteria
Walter Buggenhout
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 14, 2022

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.

Like Brennan Karrer likes this
Brennan Karrer November 14, 2022

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.

Robert Wen_Cprime_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 14, 2022

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.

Brennan Karrer November 14, 2022

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.

2 votes
James Akers December 7, 2022

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

0 votes
James Akers November 15, 2022

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

Brennan Karrer November 15, 2022

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.

James Akers November 15, 2022

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.

Like Brennan Karrer likes this
0 votes
Robert Wen_Cprime_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 14, 2022

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?

Brennan Karrer November 14, 2022

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.

0 votes
Carlos Garcia Navarro
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 14, 2022

Hi @Brennan Karrer ,

I know you mentioned that you checked the forums, but just to double-check, did you review this?

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

Brennan Karrer November 14, 2022

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.

  • Acceptance Criteria Field in Project A: `customfield_10036`
  • Acceptance Criteria Field in Project B: `customfield_10133`

Suggest an answer

Log in or Sign up to answer