Life Cycle Standards, Migration, and Mappings

[Randy Fisher]

I am trying to get some clarification on the CSDM Life Cycle migration and mappings

Life Cycle Mappings at activation

In the product docs, it states that activation will result in the following:

1. One-time bulk mapping of legacy life cycle values to the new Life cycle stage and Life cycle status fields. The mappings are based on the mapping records in the Life Cycle Mapping table, which contain values, source, and target fields.

2. Setting the csdm.lifecycle.migration.activated system property to true (set to false in the base system), which then activates the Update lifecycle from legacy business rule. Future insert or update CI operations will then trigger this business rule to populate the standard Life cycle stage and Life cycle status fields. These processes ensure that the life cycle standards are used continually and consistently.

I activated the plugin in a test instance to test.  I had some questions on whether mapping rules on parent tables, like hardware, would apply to child tables, like server.  Upon activation, I was expecting a process to run that would start updating the life cycle fields on existing CIs based on the first result above.  That was not the case and have found no scripts or scheduled jobs that imply a bulk update.  Perhaps my understanding of the result is wrong.  I also updated a server record and verified the business rule listed in second result did work.  Based on that test, I assume the life cycle mappings are run against the child tables.  

Usage of lifecycle in current versions

I have read some fairly recent posts in this forum stating these fields are not recommended to be used exclusively.  Most suggest making the fields read only and continue using the legacy fields while letting the mapping still occur in the background.  At least we can start to leverage the CMDB Data Manager.  Is that still the case?   Any other recommendations or pitfalls to consider?

Thanks and appreciate any feedback. 

[Randy Fisher]

Just providing an update.  I went back after the weekend to look again and there must be a job/script that was run to do a bulk update as the CIs now have the life cycle stage and status updated.  

[Mark Bodman]

Yes, if you have been on the platform a long time and have lots of products, business logic and other customizations we recommend using both old and new lifecycles side by side until you are confident the mappings and all the other business logic is accounted for.

If your deployment is relatively new with few to no customizations or added business logic, you are likely safe in adopting the new lifecycles.  The 2 areas that are not using the new Lifecycles yet are in ITOM and ITAM.  Logic used to set the lifecycles based on discovery or asset disposition for example still works on old lifecycles, and will sync to the new ones in the background as you summarize.  

CMDB Data manager can work fine at this point when the mapping is implemented and you can rely on the new lifecycles being set properly. For this matter, the CMDB Data Manager will not need to be re-visited as all products move to using the new lifecycles excessively in the future.

[Alec Hanson]

Hi @Randy Fisher,

I am going through the process with a client on a new install and have been figuring out a few things through ServiceNow Support to understand how things are working.

We are working on the basis that we will use the fields on CIs and allow the syncs to work across to Assets, but on Assets will be using the legacy fields still. Legacy CI Status fields will be hidden and Asset CSDM fields will be hidden.

If you have any specifics I'm happy to help and will try to list the Gotchas I have faced soon.

One key one that is outstanding with support, and @Mark Bodman might be help with :-), is that although the CSDM Life Cycle status values on a CI map to the Legacy values (post some user config), this does not cause the Legacy Values on a CI to sync with the Legacy values on an Asset.

Hopefully that makes sense.

Alec

[Mark Bodman]

The main issue with synchronizing asset is where you drive the change and what comes first: the asset or the CI. 
Most organizations will create their assets upon discovery. This however should not ever be the case as assets are typically purchased well before they are deployed an a CI is created. In effect Discovery will be the first indication that many assets exist and when both the CI and Asset gets created. Reality is there is likely a mixed bag. Some assets may exist before the CIs, and some CIs will be the main process to capture an asset. I suggest that you strive to have as asset management process that captures the asset details very early to have a more consistent starting point. Adding the lifecycle synch between legacy and new on top of CI and Asset can be confusing and the reason to tread lightly as you use the new lifecycles to trigger end of life processes in CMDB Data Manager for now. Use an approval step before delete or archive CIs for example.