Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

×
Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Migrate project from Jira Service Management to Jira Software

We have a project in Jira Service Management under which there are about 7000 issues.

These issues contain attachments, links, internal notes, attachments + links in internal notes, as well as around 15 custom fields we have created. 

We would like to migrate the whole project (all issues) to Jira Software project without losing any information we have. Both the Service Management and Software under Same URL

Please advice the best way to do so if possible and the problems we may confront.
Which solution could work? Export/Import .xml? or with backup and restore backup?

Please help.

1 comment

Radek Dostál
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Mar 01, 2022 • edited

Here's the first trouble - "without losing any information we have". They are different project types and JSM has specific JSM features which JSW does not have.

You will lose SLAs, request participants, request types, source channel, comment visibility (I think they just get converted to regular comments, never tested) that come from the top of my head. Anything JSM-specific.

Other than that, the underlying data you can keep - e.g. workflows, issue types, fields, attachments, that's all part of Jira core.

IIf you do an .xml export it will not allow you to import it into a JSW project because it will not be satisfied with the data mismatch - and you really don't want to try to make it compatible, it's a ton of regex/grep data manipulation to fool Jira that this is indeed JSW project (oh and a different one, under different key, etc.) so that it can import it as such, not to mention the human error and knowledge needed what to remove and what to replace and how.

The best would be if you had a test environment where you can simply change the project type - it will do some conversion and mostly should end up with valid JSW data in the end, but I don't think anybody can really guarantee the perfect result and you might want to check and do a few tweaks (such as permissions and role membership), this way you can see the result before committing to it with production. JSM/JSW conversion is.. well, it's possible and will mostly work, but it's of course not a standard thing to do.

You can change the project type in project administration -> details, and for the love of me I can't find any KBA for it in atl. documentation other than Cloud which is not applicable with Server.

You can make a backup, but remember you also need to back up attachments separately (not covered with native backup!) and you will only be able to restore issue data - you cannot restore the project configuration. Once you change the type, you can no longer restore the data unless you get the project back in original state, delete all issues, versions and components - only then can you import the data back. And even then it can still fail or import it wrong, or import with something missing, .xml exports/imports are somewhat finicky. I strongly suggest using a separate test environment and not rely on backups, because you really need to know how they work, they have the tendency to fail.

Comment

Log in or Sign up to comment