Plan CSM migration and terminology compatibility
Read access to this guidance; editing requires the applicable module, operating view and record permissions.
Understand the model behind the workflows.
Download the original Connected Service Model whitepaper, version 1.0, dated 2 October 2026. Its 25 pages cover principles, conceptual and system models, six domains, relationship semantics, governance and adoption.
The PDF is the original proposed reference baseline. Online guidance includes later implementation clarifications; model recommendations do not establish automatic product enforcement.
Migration into CSM is broader than a label change: it requires deciding what existing records mean, who owns them and which processes consume them. The repository migration analysis also records a historical terminology transition that has already been executed.
Before you start
Inventory legacy services, applications, deployments, CIs, assets and request definitions. Record authoritative sources, identifiers, duplicate names and consuming forms, rules, exports, reports, integrations and training materials. Do not perform a broad search-and-replace in tenant-authored operational content.
Steps
- Classify records against the CSM entity dictionary. A server hostname should not automatically remain a business Service; a request action should not automatically become an Offering.
- Map identity, ownership, lifecycle states, environments and intended relationships. Preserve stable IDs and traceable mappings where consumers depend on them.
- Identify field-level authority and dependent consumers before bulk changes.
- Rehearse in non-production, back up the relevant data and verify a rollback plan with the implementation team.
- Compare counts, uniqueness, tenant boundaries, usable default Offerings, orphan links and graph direction.
- Test real Incident routing, Catalog fulfilment, Change controls, Asset reconciliation and Outage reporting.
- Obtain sign-off from the relevant owners and review early operational cases after transition.
Current terminology and historical analysis
The migration analysis is a historical proposal with an execution note. It records the October 2026 application change as completed in three phases. The current customer-facing names are ITSM Lite and CSM Full, with stored values ITSM_LITE and CSM_FULL. Earlier alternatives proposed in the analysis are not current unresolved product naming decisions.
The terminology transition preserved Service, Service Offering, Business Application, Service Instance and CI entity names and did not redesign their schema or operational behaviour merely by renaming the model. Historical decisions and completed change records can retain former terminology as evidence of what happened at the time.
Compatibility and rollout
Treat stored settings, API validation, guards, shared packages, frontend labels and integration mappings as one release contract. A display-name change is different from a persisted identifier migration. Do not rename previously applied migration directories or assume that editing a label migrates stored values.
For a tenant's own data adoption, document old-to-new mappings and consumer compatibility, then rehearse representative flows. This guide is a governance procedure, not a database migration command or a claim that every old integration is automatically aliased.
Expected result
Service information has clear meanings and ownership, consumers continue to work, and historical records remain explainable.
Important behaviour
The uploaded whitepaper remains a versioned conceptual baseline. Current online documentation incorporates later implementation clarifications. Renaming terminology does not automatically implement all reference-model recommendations or close separately documented implementation gaps.