Advice on Decommissioning of HR Services

[joecurry105]

Looking for some advice on decommissioning of services as unsure of best practice in ServiceNow.

For background: In BMC Remedy (our ITSM solution), when a service is decommissioned we export the service so we have a copy on hand (stored in SharePoint), set the service to “Unavailable” in production for 28 days (this leaves the service description active while preventing a user from requesting it), and then delete the service as a whole from the system. This enables us to maintain a tidy workspace while maintaining a backup of our services should they need to be reinstated.

In ServiceNow there is no option to set a service to unavailable, so instead we have decided to take the approach to disable the service and create a Knowledge Article in it’s place (the article would have the same name as the service to make it easy to locate).

Where I need advice: What we’re unsure on is what to do with the service after it’s been disabled. Is it best practice to leave the service in place and inactive, or should we be exporting and deleting it?

If we are to export, I would also appreciate some advice on the best way to do this so that nothing gets missed. It’s much easier in Remedy as the service is packaged, whereas in ServiceNow the services are compiled of various parts.

[rahulswami]

Hi @joecurry105,

The core issue is that deleting a catalog item or service breaks referential integrity. Past requests, RITMs, tasks and any flows or workflows that reference that item all point back to it. Delete the record and those historical requests start looking broken the item name disappears from them, and anything still wired to trigger off that item can fail outright. So the platform native approach is not retire then delete, it is retire and leave in place, with deletion treated as a last resort rather than a routine step.

The pattern most ServiceNow shops follow looks like this: set the catalog item to inactive, which removes it from the portal and search without touching the underlying record, pull it out of any category so it cannot resurface by accident, and document the retirement reason and date on the record itself. That inactive record just sits there afterward. It is not costing you anything functionally, and it preserves the audit trail and historical request data indefinitely. Where teams do eventually clean up, it tends to follow a much longer timeline than 28 days, think archiving after a year or two, with actual deletion only considered after five to seven years, usually handled through CMDB Data Manager's policy based archival rather than a manual export and delete step.

Given that, you probably do not need the export then delete step at all. Leaving the service inactive with a knowledge article standing in its place, like you are already planning, is a reasonable and pretty standard way to keep the workspace tidy while the retired record itself serves as its own backup.

If you still want an offline copy for peace of mind alongside keeping it inactive, rather than instead of it, the cleanest way to capture the whole service given it is built from multiple pieces, catalog item, variables, UI policies, client scripts, any associated flow or workflow, record producer if there is one, is to build a scoped Update Set containing just those records before you deactivate anything, then export that Update Set as XML. That gives you one portable file capturing the full configuration, closer to the packaged export you are used to from Remedy, without touching the live record at all.