Best practice CSDM Life Cycle adoption for brand new Xanadu instance

[declannolan]

Hi,

I'm implementing a brand new Xanadu instance with CMDB/Asset management supporting a basic ITSM implementation.  Currently there is no Discovery and all CIs/assets will be imported and managed manually for the short-to-medium term.

We have no legacy data that needs converting/mapping and no immediate need for Operational Status values on CIs.  So my question is, what's the best practice in adopting CSDM Life Cycle Stage/Status?  Can we effectively ignore all the legacy status fields (my preference to keep everything nice and clean) and just use LCSS in isolation? (If so, does that mean we don't need to use the "Enable Life Cycle Sync" button on the Life Cycle mappings table?).

Thanks,

Declan

[Mathew Hillyard]

Hi @declannolan 

The recommendation is to map all your legacy status values to a life cycle stage/status. When you enable life cycle sync it does a one-time job across all impacted records - setting the life cycle stage/status field based on the mapping. If you don't create a custom life cycle mapping record before activation it will not synchronise afterward. The point of this is that once done you can move to using life cycles exclusively, instead of status.

I've attached the relevant PPT from ServiceNow on Life Cycles.

Hope this helps!
Mat

So I would only recommend disregarding custom status values if you are sure they will never be used.

[Damhoej]

In CSDM 5 they mention that that the life cycle does not work and will be turned off. 
so the solution here should be only to have lige cycle and not legacy. 
data manager in the cmdb requires lige cycle. 

[declannolan]

Hi (again 🙂 Mat,

Thanks for the response but the thing I'm struggling with is that we have no legacy CI/Asset data.  This is a completely new (Xanadu) instance.  Most of what I've seen about CSDM Life Cycles is focussed on migrating existing implementations (using legacy status values in CIs/Assets) but we will be importing CI/Asset data fresh with none of that baggage.  Why can't we just ignore the old legacy status fields completely (and thus ignore any legacy status value mapping)?

It feels counter-intuitive that ServiceNow have established a new (and hopefully better) approach to CI/Asset lifecycle management and yet we need to worry about legacy stuff that shouldn't affect new implementations for Xanadu instances onwards.

Basically I just want to know can I ignore legacy status mapping, and if not, why not?

Thanks,

Declan

[Mathew Hillyard]

Ah, I see you are referring to the legacy status fields rather than custom status values.

That is the whole point of life cycles. If you have no custom values and you don't want to use legacy status values then enable life cycle mapping and start from scratch using life cycles. The only caveat is that only a few select tables are there in the baseline as per the CSDM 4.0 white paper, so you may need to have a think about whether additional tables require status to life cycle mapping before enabling the life cycle mapping capability.