You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Search for all the items you want to move to the software project and then execute a bulk move action.
Take into account that if you want to retain all information in regards to fields , issue types or statuses, you will have to have the identical workflow, issue type and screen schemes on the Jira Software project.
The values of the custom fields will till be retained in the fields but then they are not visible on the Jira Software project until you add the desired fields to the screens of the Software project.
Data related to Component and Version will be lost as they are project bound.
If not, then on moving you will need to specify the new issue type, status.
You can find more information here: Migrating issues
I guess there are no components or versions in JSM projects. Also the info to custom fields visibility is a kind of irrelevant here.
Also there is no need to make same statuses - they can be mapped to Jira Software project statuses on the last step of bulk move.
Anyway if it is one-off operation (e.g. boss told to close portal and use Jira Software) - it is a good solution. If it is just the case of adding tasks to developers using portal - I am 100% sure it should be done using a rule that will keep original request in place and create a copy in developers project. There are many pros of having a JSM for customers (e.g. for not paying for licenses) and having Jira Software for developers. My opinion is that only L2/L3 support should be agents in JSM.