Migrate from ServiceNow IT Service Management to Salesforce Service Cloud

ServiceNow Incidents map to Salesforce Case. State (New, Active, On Hold, Resolved, Closed) maps to Case Status with record type ITSM_Incident__c. Assignment group maps to Salesforce Queue via a pre-built Queue-to-group mapping we configure before migration. Priority (1-Critical through 5-Low) maps to Case Priority. Caller reference maps to Contact by email lookup. We preserve the incident number as a custom field original_incident_number__c for audit and cross-reference. CI linkage from the incident's cmdb_ci reference resolves to the migrated Asset record.

ServiceNow Problems map to Salesforce Case with record type Problem. The problem_id field links related Incidents via a custom lookup field problem_incidents__c that we populate during migration using the original ServiceNow problem-incident relationship graph. Problem manager assignment maps to Case Owner. Known error body migrates as a custom rich-text field known_error_body__c. We do not replicate the full known error database as a separate object; it attaches to the parent Problem Case.

ServiceNow Change Requests map to Salesforce Case with record type Change_Request. Change type (Standard, Normal, Emergency) maps to a custom picklist change_type__c. Risk assessment, approval chain (CAB approvals), and schedule dates migrate as custom fields. Implementation tasks under the Change Request map to Salesforce Tasks linked via WhatId to the parent Change Case. Change freeze calendar associations are documented but do not migrate as an automated constraint; we flag freeze window requirements for the customer's admin to implement via Salesforce Flow time-based actions.

ServiceNow cmdb_ci records map to Salesforce Asset. Parent-child relationships from the CMDB become Asset hierarchy (Asset with a parent Asset). Dependency maps (ci_rel_ci relationships) are more complex: we export the relationship table and represent bidirectional dependencies as custom lookup fields on Asset (dependency_a__c, dependency_b__c) since Salesforce Asset does not have a native many-to-many dependency graph. Organizations that require a full CI relationship map should consider an AppExchange CMDB product post-migration; we flag this as a configuration recommendation during scoping.

ServiceNow Service Catalog Items with custom variables and variable sets require a reconstruction in Salesforce. Catalog item text and descriptions migrate to Salesforce as a written catalog inventory document listing every item, its variables, its fulfillment workflow, and its variable set dependencies. Variable sets are documented as a separate inventory. The customer's admin uses Salesforce Flow to rebuild catalog items as guided flows or uses a third-party AppExchange catalog tool. We do not migrate catalog items as executable Salesforce configuration.

ServiceNow Knowledge Articles map to Salesforce Knowledge. Article title, body (HTML), metadata, and active or retired status migrate. Category hierarchies from ServiceNow map to Salesforce Data Category Groups and categories. Article workflow states (Draft, Review, Published, Retired) map to Salesforce Knowledge article statuses. Approval workflows for article publication do not migrate; we document the approval chain as a written process note for the customer's admin to configure in Salesforce Lightning.

ServiceNow Fulfiller users map to Salesforce Users. We resolve by email match and flag role assignments during scoping because every imported user defaults to a Salesforce profile that may carry different license costs. The Fulfiller vs Requester distinction from ServiceNow translates to an active vs inactive User in Salesforce, with active fulfillers provisioned as active Salesforce users and requesters optionally provisioned as Experience Cloud users or Contacts depending on whether they need portal access.

ServiceNow Groups (assignment groups, approval groups, fulfillment groups) map to Salesforce Queues for case routing and Salesforce Groups for collaboration. Group membership and group managers migrate as GroupMember records and manual sharing rules. Group type classification (e.g., fulfillment, approval) is preserved as custom fields on the Salesforce Group for audit.

ServiceNow SLA definitions with start time, end time, business hour calendar references, and breach actions map to Salesforce Entitlement records linked to BusinessHours. We flag every calendar mismatch during the mapping phase: ServiceNow calendars carry time zone and holiday schedule definitions that do not map 1:1 to Salesforce BusinessHours, which has limited holiday schedule support. Calendar mismatches are documented with the original ServiceNow calendar definition and a recommended Salesforce BusinessHours configuration so the customer's admin can resolve before SLA timers resume in production.

Child tasks under Incidents and Change Requests migrate to Salesforce Task records. Task state, assignment, short description, and parent references (WhatId pointing to the parent Case) preserve. Task workflow states transform to Salesforce Task Status equivalents. Parent-child task hierarchies within ServiceNow are documented as a flat task list in Salesforce because Salesforce does not support nested task hierarchies natively.

File attachments on Incidents, Problems, and Change Requests export via the ServiceNow table API and load into Salesforce as Attachment records linked to the migrated Case. Large attachment volumes require chunked export and storage consideration; we coordinate with the customer on attachment staging before migration to avoid API timeout. Attachment file size limits follow Salesforce Attachment constraints (25 MB per file).

Instance-specific custom fields on Incident, Problem, Change Request, and Task tables are inventoried during discovery and mapped to Salesforce custom fields on the Case or Task object. We pre-create the destination schema (custom fields with type-mapped Salesforce field types, including picklist value sets, validation rules, and required-field constraints) in a Salesforce Sandbox before production migration. Custom field data that cannot map to a Salesforce field type (e.g., ServiceNow reference fields pointing to ITSM tables not present in Salesforce) is documented for the customer's admin to resolve.