What to do with cmdb_ci_service table ?

[Rahul_K]

 Hi Community,

I need some clarity and guidance on the correct approach for one of my ongoing ServiceNow CSDM implementations.

Currently, our implementation has almost everything in a single table: cmdb_ci_service , including Business Services, Technical Services, and Service Offerings. These are also being actively used across ITSM processes.

Now, as we are implementing the latest CSDM framework and aligning with best practices, I’m unsure about the right approach for handling the cmdb_ci_service table and its existing data.

We have identified:

• Business Applications
• Application Services supporting those Business Applications
• Business Offerings

and we want to populate the appropriate CSDM-aligned tables instead of continuing with everything under cmdb_ci_service.

I would like to understand:

1. Which tables should ideally be used for these entities as per current CSDM recommendations?
2. How should we approach correcting/importing the data into the right tables?
3. How should these entities then be used within ITSM processes (Incident, Change, Problem, Request, etc.)?
4. What important considerations should we keep in mind before migrating away from the cmdb_ci_service table?
5. Is there any impact on existing relationships, reporting, SLAs, or service mapping that should be carefully reviewed?

Would really appreciate insights from anyone who has handled a similar transition from legacy service models to a CSDM-aligned structure.

Thanks in advance for your guidance!!!!

[DanielJ43996773]

Hi @Rahul_K 

This is a very common situation when moving from a legacy ServiceNow service model to a CSDM-aligned model.

In older implementations, many organizations used cmdb_ci_service as a generic “service bucket”, but in the CSDM model it is important to separate the concepts clearly.

Recommended table alignment:

• Business Application: cmdb_ci_business_app
• Application Service: cmdb_ci_service_auto / Application Service class, depending on how it is discovered or modeled
• Business Service: cmdb_ci_service_business
• Technical Service: cmdb_ci_service_technical
• Business Service Offering: service_offering
• Technical Service Offering: service_offering, related to the correct parent service

The key point is that Business Service / Technical Service represent what is being provided, while Service Offerings represent how that service is consumed, including commitments, availability, support model, SLAs, and requestable options.

For migration, I would not recommend simply moving records directly from cmdb_ci_service into the new tables without analysis. Start with a data assessment:

1. Classify each existing service record
2. Identify whether it is really a Business Service, Technical Service, Application Service, Offering, or Business Application
3. Map current relationships, dependencies, SLAs, reports, catalog items, assignment logic, and ITSM references
4. Create the correct CSDM target model
5. Migrate in phases, validating relationships and process impact

For ITSM usage, the common approach is:

• Incident / Problem / Change: use the impacted CI / Application Service / Technical Service depending on the process design
• Request: usually driven by Service Offerings and Catalog Items
• SLAs: often aligned to Service Offerings
• Reporting: should be redesigned around the new service hierarchy
• Impact analysis: should rely on correct relationships between Business Applications, Application Services, Technical Services, Offerings, and underlying infrastructure CIs

Important considerations before migrating:

• Existing references to cmdb_ci_service
• Historical tickets and reporting
• SLA definitions and conditions
• Catalog item mappings
• Service mapping dependencies
• Dynamic CI groups or service population methods
• Integration dependencies
• ACLs and role-based visibility
• Dashboards and PA indicators
• Business rules, flows, notifications, and assignment logic using the old table

My recommendation is to treat this as a CSDM remediation and transition project, not just a data migration. Keep historical records intact where needed, define the future-state model, migrate active/valid services into the correct classes, and update ITSM processes gradually to consume the new structure.

Also, avoid deleting or mass-changing legacy service records until you fully understand where they are referenced.