Can Service Management Jira Projects become "normal" Jira project after SM is uninstalled?

[Martin Doucet]

Hi all,

I'm asked to evaluate what the impacts would be to uninstall Service Management (4.20.1) from our Data Center Jira (8.20.1). We have one active project of type SM and multiple Jira projects of various types. The hope/wishful thinking is that after uninstalling the SM application, the SM project would somehow become like a normal Jira project.

I know better. I ask nevertheless in the hopes that I might have missed something, or that this could be done with some elbow grease and code monkeying. I have a test instance that mirrors prod so I could make some changes, but before I make my test instance unstable and generate a few hours of work for me to rebuild, I figured I'd ask.

We will likely uninstall Service Management anyway, and I expect the non-SM Jira projects won't be affected - kindly confirm that part is accurate. It's that last pesky SM project that still uses the app. The users would very much like to keep as is if possible (same project key, same numbers, etc.).

In your infinite wisdom, valued Jira experts, what say you? Short of migrating all the issues from the SM project to a new, "normal" Jira project (which is the way to go), is there a way to sort of excise Service Management from a Data Center setup and make that SM Project a "normal" Jira project?

(I expect a flurry of "no". It's fine if so - then that response will be available for anyone. Feel free to expose why doing so would be a bad idea.)

[Martin Doucet · Accepted solution]

Hey there,

Got some new info.

I've reached out to Atlassian support, and after a call, here is the results.

Disclaimer: Or course, YMMV, so this advice is provided as is. Make your own tests and make backups!

The "cleanest" way to remove Service Management from your instance is to delete your license (but do not remove your configuration if you want a quick backtrack option). You can also remove the app itself, which I haven't tried but would likely nuke everything SM-related and would not be recoverable save from a app and DB backup.

I did the tests on my test instance and I can remove/re-add the license. Since I had kept the SM configs, I could return to normal by putting the license back. This is practical if you want to make a "pilot" removal, field any questions from your users and gauge any other unknowns, before definitely pulling the plug.

With the license removed, the impacted former SM projects can still be accessed. You can create and edit tickets (the "normal" Jira way) without issues. Testing continues but it looks good so far.

Obviously, there are consequences. The portal attached to your SM project no longer leads anywhere, and although you still see, in the Project settings, SM-related pages, they "Snap!" to nowhere as well. Note that they don't show an error - just a white page.

So it seems that my "wish" of being able to utilize a former SM project as a "normal" project (it fits no category in the Project details) is good. I'll continue my testing and will provide any additional details if I encounter other caveats.

The advise to move to a new, solid Jira Software project remains the best, clean, future-proof solution, but this method above bears being heeded, depending on your reality and how risk-tolerant you and your users can be.

Thanks!

[John Funk]

Great! Thanks for testing all of that out - good info!

[Jack Brickey · Accepted solution]

what do you want to do with the data? if you want to be able to work issues then Move issues to a JWM/JSW project. If you dont need then just export to Excel or maybe create a free Cloud instance.

[John Funk]

And I think Jack is going to test this for you and will let you know what happens. 

[Martin Doucet]

The project will need to remain live and active, workable, including the existing tickets prior to the operation. So a static export would not do.

I'm pretty sure I'll have no choice indeed but tell the team they'll have to live with a new Software Jira project and different numbering, where I'd move everything. Jira should be able to refer old-to-new ids so that would soften the blow.

Jack, if you feel like testing, that'd be great, be my guest! If anything can be done, I'm willing to work on this with you.

[Jack Brickey]

LOL...i'm just waiting on my admin creds to @John Funk 's instance. ;-)

@Martin Doucet , you definitely should move all issues from JSM to JSW/JWM projects. 

[John Funk]

@Jack Brickey  - You like how I turned that one back on you?   :-)

@Martin Doucet  - I agree with Jack - you need to move those to a Jira Software project.

[Martin Doucet]

That bad, han? Not event the beginning of the possibility of maaaaaybe some convoluted sliver of a ray of dusty light?

Oh well. It is what it is. Moving to a new project it will be.

Thanks @John Funk and @Jack Brickey . Have fun messing each other's instance! ;-)

[John Funk]

Yes, I am afraid it is that bad - you have to take Jack's advance. Painful, I know. And even more painful that I have to agree with him.  :-)

Seriously, I don't think there is a better way. What is your biggest fear of having to do that? 

[Jack Brickey]

It really isn't that bad unless you have a lot of projects abd custom fields that you need to retain. The way I would probably do this is:

1. stand up the new projects as required to move forward. Keep in mind that many of the fields or capabilities of JSM won't reply in JSW or JWM, e.g SLA, Request Participants, etc
2. Use export to export all issues. You may even choose not to export anything that's already considered done.
3. Massage the export file and ready it for CSV import into your new project.
4. Use CSV import to get your old issues into your new projects

Note: export all issues from all projects into a single file an import that single file as well. You just need to be sure to specify the project as one of your columns.

[John Funk]

Hey @Jack Brickey  - would you do the export and import instead of just doing a Move?

[Jack Brickey]

i might. sometimes the import, once you have a working config file, can be easier. hard to say which way to go w/o experiencing the environment firsthand. it is going to be tedious either way.

[Martin Doucet]

@John Funk Sigh. I guess I'll have to take his advice. And yours. ;-)

@Jack Brickey  It's a single project, about 1600 tickets - really not that big. I will likely use the Bulk Move principle instead of a new, fresh import. Basically I need all the ticket's history, and the Done ones also need to come along. That way I can leverage Jira's "old-to-new" (there's must be a better term) feature so users still using the old project ticket ID will "magically" land on the new ticket's project structure. I'll also make the old project read-only, and handle the questions and redirect the users to the new project.

There will be a bit of work to redo the boards and the like, but that should be fairly simple if the boards use JQL filter inheritance. Change the top one and poof! rest flows.

I guess I will lose some things - like sprint history. Also, I know the PM will have fun recreating the many, many components and versions (and other project-specific stuff) that were in the old project.

The new project will have all the same screens, workflows, priorities, notifications, etc. as the previous one. I'll test on my test instance first, of course, but I think this way is the cleanest. There is no concerns about the SM's specific features (like SLA and the like), they were not used anyway - hence why the move to a regular project and, afterwards, drop SM altogether from our instance.

[Martin Doucet]

Would the SM project be at all reachable? If I could lock it to read only, that'd be best. But I worry it'll bork completely if not deleted/archived when I'll uninstall SM.

[John Funk]

Since neither of us has actually done the dropping of JSM as a paid product, we don't really know what the access will be like. So we would love to hear what happens after you do it. :-)

For what it is worth, I would go about it the same way you are looking at it. 

1. Create the new project

2. Update it with all of the same schemes currently being used by the JSM project. 

3. Add the Components as needed to the new project. 

4. Same with the release name. Although, do you really need those? Typically, I just create a single "Mass Release from Move from Project ABC" for those and cram them all in the single release. 

5. Do a bulk move on all of the Open stuff first.

6. Do a bulk move on all of the Closed stuff.

7. We don't use Sprints so not sure what happens with those. And if you are doing Scrum, you shoudl be use JSW instead of JSM anyway  :-)

8. Actually, I would probably do this as step 2 (I hope you read all the way through first!!), I would create a copy of all of your existing boards, and just update the board filter to use the new Project (or even initially include both projects) See if the current stuff shows up in the new board as it should).

9. After the move, you will need to Release the Releases, I know stupid, but you have to do that. 

10. Check things out on the new board and then update the filter to drop the old project). 

GOOD LUCK! Let us know how it goes. And Jack is just a quick plane ride away  ;-)

[Martin Doucet]

Thanks @John Funk , I'd love a visitor in thick snowed and cold Montréal!

Yeah, I'll do many iterations on my test env. before I get the right sequence. I feel I'll be restoring my db quite a few times...

I'll (try to remember to) let you guys know how it turns up. Will likely be in a few months tho, so don't hold you breath.

Cheers!

[John Funk]

Sounds good. I am dealing with my own snow in Nashville right now - don't need more. And I DON'T do frigid  hahaha