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!!!!

[IanCox]

The fact that everything landed in cmdb_ci_service is the tell — this is a target-operating-model gap, not tech debt. Fix the model and ownership before you move a single record, or you'll just recreate the mess in more tables.

Mapping: split the records into their CSDM classes — Business Service (cmdb_ci_service_business), Technical Service (cmdb_ci_service_technical), Service Offering (service_offering), and, where you have discovered/mapped services, Application Service (cmdb_ci_service_auto). Treat cmdb_ci_service as the abstract parent you stop writing to directly.

Sequence it by CSDM domain (Foundation → Design → Manage Technical Services → Sell/Consume) rather than a bulk reclass. Don't blindly flip sys_class_name; correct and validate first, then move via transform maps or CI Class Manager, preserving relationships.

Usage: Business Services and Service Offerings are what you attach to incidents, changes, and SLAs; Technical Services sit behind them via Depends on/Used by.

Before you migrate, inventory everything pointing at the legacy table — SLAs, assignment rules, reports/dashboards, subscriptions, service maps — and freeze new writes to it. Those references are exactly what breaks: SLAs keyed on the service field, dashboards filtered on cmdb_ci_service, and maps that need to rebuild against Application Services.

If you want a structured way to run this transition end-to-end, this is exactly what we do at Four Dragons: