Life Cycle mapping

[kg4ult]

Hello 

I am in the planning stages of implementing Life Cycle mapping given the updated values to align properly with CSDM 5.
However, most of the documents seem over simplified. My hunch is that this process is a bit more involved than i can see from these documents.

Have any of you performed this task recently and if so, could you provide some guidance and lessons learned. 

Thanks

[Vikram Reddy]

Hi @kg4ult,

The docs make lifecycle mapping look like a one time field swap, and that's exactly where most people underestimate it. In practice it's a governance exercise wearing a configuration screen, and the platform behavior around it catches almost everyone off guard the first time.

The single biggest surprise: install_status and operational_status do not keep syncing to life_cycle_stage and life_cycle_stage_status after you run the initial migration. The life_cycle_mapping table only does a one time bulk population when you hit "Enable Lifecycle Stages." After that, sync only continues if you've turned on csdm.lifecycle.migration.activated (drives an "update lifecycle from legacy" business rule) and, separately, csdm.lifecycle.sync.between.ci.and.asset.activated if you want CI and Asset records reconciling with each other. A lot of teams enable the button, assume they're done, and then wonder six weeks later why new CIs are landing in "To Be Determined." Before you touch the mapping table, a few things worth doing:

• Audit legacy dependents first: reports, ACLs, business rules, transform maps, and any integration reading install_status or operational_status directly. ITAM and ITOM still lean on the legacy fields under the hood, so you're not fully retiring them even after cutover.
• Build mappings per table, not globally: life_cycle_mapping entries are scoped by table (and its extended/child tables like cmdb_ci_hardware vs cmdb_ci_server), so a mapping on the parent doesn't automatically cover every subclass the way you'd expect.
• Respect life_cycle_control: it's the validation table that says which stage/status combinations are actually legal. Invalid combinations from a bad mapping fall back to "To Be Determined" silently, so check that table doesn't just report blank rows after activation.
• Don't try to customize the stage/status value lists themselves. ServiceNow has stated those are meant to stay standard since more products are wiring logic to them; customizing them is a good way to break future upgrades.
• Run old and new in parallel for a while. Several practitioners in the CSDM forum land on the same advice: keep legacy status fields live alongside life cycle fields until you're confident the mappings and any downstream logic actually hold up, rather than cutting over in one pass.

Also worth knowing there's a scheduled job, "CI Lifecycle Management - Restore Internal State Management Tables," that reconciles drift on an ongoing basis, separate from the manual button. If your lifecycle values keep resetting unexpectedly after go live, that job (or LifeCycleUtil.bulkPopulate being triggered again) is usually why.

Thank you,
Vikram Karety
Octigo Solutions INC

[kg4ult]

Thank you very much for the detailed information. I will carefully review this in the morning. I suspected it was more complex than it appears to be. 

[vaishali231]

Hey @kg4ult 

One of the first things I'd recommend is performing a CMDB impact assessment before making any configuration changes. Identify every place your current lifecycle values are referenced, including:

1. CMDB CI classes and existing lifecycle values
2. Asset Management (if you're using HAM/SAM)
3. Discovery, Service Mapping, Cloud Discovery, and other population sources
4. IntegrationHub, Import Sets, Transform Maps, and external integrations
5. Business Rules, Flow Designer flows, Workflows, Script Includes, Scheduled Jobs
6. Reports, Dashboards, Performance Analytics indicators
7. ACLs, UI Policies, Client Scripts, and any custom applications that reference lifecycle values

The next step is to create a mapping matrix between your existing lifecycle values and the new CSDM 5 lifecycle stages. In many cases, you'll find that multiple legacy values map to a single CSDM value, while some custom values don't have a direct equivalent and require a business decision rather than a technical one.

Another area that often gets overlooked is data quality. Before migrating, identify CIs with missing lifecycle information, conflicting values, duplicate records, or inconsistent updates from different discovery sources. If these issues aren't addressed first, the new lifecycle model can actually make reporting less reliable instead of improving it.

If your instance has integrations creating or updating CIs, verify that those integrations will continue sending valid lifecycle values after the change. I've seen projects where the mapping was configured correctly, but integrations continued writing deprecated values, resulting in inconsistent CMDB data within days of go-live.

I would also recommend implementing the change in phases:

1. Document the current lifecycle model and dependencies.
2. Build the mapping between legacy and CSDM 5 lifecycle values.
3. Update integrations, Discovery patterns, and automation.
4. Validate reporting and downstream processes in a sub-production instance.
5. Migrate historical data.
6. Monitor new CI creation after go-live to ensure the mappings are working as expected.

In my experience, the configuration itself is relatively straightforward. The real effort lies in planning, data remediation, regression testing, and stakeholder alignment. The official documentation provides a good overview of the target state, but it intentionally doesn't dive into the implementation complexities that vary from customer to customer.

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[vaishali231]

Hey @kg4ult 

Hope you are doing well.

Did my previous reply answer your question?

If it was helpful, please mark it as correct ✓ and close the thread . This will help other readers find the solution more easily.

Thankyou & Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb