What's the best practice for changing life cycle control for an OOTB life cycle mapping?

[Caleb Cordes]

The life cycle mapping for Configuration Item: "Operational Status - Non-Operational"  to "Configuration Item - Design - Build" not make sense for all use cases. For instance users may put a CI in Non-Operational status when the CI is turned down and pending retirement. I assume it's not best practice to update the lifecycle Control, but can someone tell me what the impact would be? What's the best practice in this case?

[cassieb_]

You should consider how the life cycles come into play from an Asset Management perspective. In the case of a "device" being turned off for retirement/disposal, the Asset State would change to "In stock" with a Substate of "Pending disposal". This would change the Hardware status of the CI to "In Disposition"

As seen in the Hardware life cycle the appropriate Lifecycle Stage and Lifecycle Stage Status would be "End of Life" and "Pending Disposal", respectively.
The Hardware life cycle information can be found at https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/csdm-implementation...

There is not an entry in the OOB Life cycle Mappings configured for this scenario, so I would recommend creating one that supports the documentation noted above.
For example, the new Life cycle mapping

Table: Hardware [cmdb_ci_hardware]

Priority: 20

Legacy field name: Hardware Status

Legacy field value: In Disposition

Life cycle control:  Hardware - End of Life - Pending Disposal

[Caleb Cordes]

That's an interesting take. That covers hardware, but what about non-hardware classes, such as Application Services for instance. 

[cassieb_]

For application services that are going to be retired, I am not sure why you would not directly retire them.

Also look at this in the Logical life cycle in ServiceNow Docs:

https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/csdm-implementation...

[Caleb Cordes]

It's about tracking the decisions from divest (no longer investing) to executing plans to retire. . . Since Application Services are following the logical standard, the OOTB pending retirement is enough to satisfy the use case. 

OK, back the second part of my original question. What is the impacts do I need to consider when creating a missing life cycle making? For instance, if I were to create a life cycle mapping for "In Disposition" for cmdb_ci_hardware as you suggested, wouldn't that screw up any OOTB logic that doesn't know to look for that life cycle status change?