CMDB Business Applications - Identifying a Reference System

[MJONES_OH]

Hello!

I'm trying to find the best way to identify and properly status Business Applications which are still "Live" but are used as a reference system. As an example, we acquired an organization and their tools/apps. A few apps have had their data migrated from the Company A's system to ours, but for audit or other regulatory reasons, we have to keep Company A's system alive for a period of time for reference. However, no one is operationally using this system.

I know how we would do this via Application Services (Service Instances), however, for purposes of app portfolio management, we have identified each companies system as different business applications with different strategies and ownership. Assuming this system is still "In Production" or "In Use" via available status options, what is the best recommended way to classify this system as a referential system? Keep in mind, this data is needed at the Business Application level for Strategic Rationalization and Transformation efforts... or at least that is what we think?

Appreciate the help!

[TheJoeDC]

Wondering if your lifecycle status can track that. While the Applications are still Operational, but coded as Pending Retirement (or End of Operation stage On Hold)

[MJONES_OH]

We thought that lifecycle should certainly be involved, but we also felt that not every system that is Pending retirement or other is a referential system and wanted to highlight those specifically. It might be that we create some sort of a custom true/false categorization but we wanted to align to OOB process as much as possible.

[TheJoeDC]

I think you are correct in keeping these as Business Applications, as each one in Company A/B supports the capabilities. 

Thoughts on:

1) Customize "Application Type" and add a "Reference" as a choice (doesn't really fit but could be a simple solution)

2) Work backwards as you mentioned, Application Service be a "reference" instance and you can dot walk your reporting

[MJONES_OH · Accepted solution]

Thought I would provide the solution I found. Thanks to @TheJoeDC for the help on this! With the help of AI, I was able to find the below.

PROMPT - Please define ServiceNow Lifecycle Stages and Statuses for Product Models where the Stage and Status pairings are as follows: End of Life & Obsolete, End of Life & Retired

RESPONSE - In ServiceNow, Product Model Lifecycle Stages and Statuses help organizations manage the lifecycle of their hardware and software assets. When it comes to the "End of Life" stage, there are two commonly used statuses: Obsolete and Retired. Here's how these are typically defined:

End of Life & Obsolete:

• Stage: End of Life
• Status: Obsolete
• Definition: The product has reached the end of its lifecycle and is no longer in active use for operational purposes. However, it may still exist in the environment for reference, audit, or legal hold reasons. It is not supported, not maintained, and not intended for future use, but it hasn't been fully decommissioned or removed from the system.
• Use Case: Useful for tracking legacy systems or products that are technically inactive but still present due to compliance or data retention requirements

ANSWER - To Identify a Reference system, use Lifecycle Stage and Status End of Life and Obsolete.