Migrate from ServiceNow Customer Service Management to Salesforce Service Cloud

ServiceNow Case records migrate 1:1 to Salesforce Case. The Case number from ServiceNow becomes a custom field sn_case_number__c since Salesforce auto-generates its own Case Number. Priority, Status, and Assignment Group map directly. We preserve the opened_by reference, opened_at timestamp, and resolved_at timestamp as custom fields to maintain the case lifecycle audit trail. Parent-child Case Task relationships are migrated separately as Tasks and linked via WhatId to the parent Case.

ServiceNow Case Tasks map to Salesforce Task records linked via WhatId to the parent Case. Assignment, due date, state (active, closed), and any notes on the task migrate as Task fields. ServiceNow task sub-states that have no Salesforce equivalent are preserved in custom fields for admin review. The task ordering relative to the parent Case is maintained by setting ActivityDate and CreatedDate to the original timestamps.

ServiceNow CSM Accounts map to Salesforce Account. Account hierarchy, address fields, and any custom properties migrate directly. The Account is loaded before Cases so that the AccountId lookup on Case resolves at insert time. ServiceNow Accounts linked to Service Organizations carry those references as custom multi-select or lookup fields on the Salesforce Account object since Salesforce has no native Service Organization concept.

ServiceNow Contact records migrate to Salesforce Contact with direct mapping of email, phone, title, and role fields. Contact-to-Account relationships migrate by resolving the AccountId via the account name match. Any custom fields on the Contact table are pre-created in Salesforce before import. We do not migrate fulfillers (agent users) as Contact records; those map to Salesforce User records separately.

ServiceNow CSM Consumer records (B2C person records distinct from B2B Contacts) map to Salesforce Contact. Consumer-specific properties like consumer_type and authentication_source become custom fields on the Salesforce Contact record. The mapping choice between Lead and Contact for Consumers is made during scoping based on whether the organization's support model treats all consumers as potential CRM leads or only as support requesters. We document this decision and its downstream reporting implications before migration begins.

ServiceNow CSM Service Definitions (structured metadata linking products, services, and case eligibility rules) have no standard Salesforce equivalent. We export Service Definitions as structured JSON records and create a custom Salesforce object Service_Definition__c with fields for the service name, eligible product references, and rule conditions. The customer admin configures how these rules drive Case creation in Salesforce Flow post-migration; we document the rule logic in the handoff spreadsheet.

ServiceNow Install Base tracks products sold to customers with warranty status and contract associations. Salesforce Field Service (an add-on product) provides a native Asset object with entitlement and warranty management. If the destination org includes Field Service, we migrate Install Base records to Asset with warranty start/end dates and contract lookups. If Field Service is not licensed, we migrate to a custom object Installed_Product__c with equivalent fields and flag the Field Service upgrade path for the customer's admin.

ServiceNow CSM Service Organizations represent internal or external business locations handling cases using an IBL/EBL/OSP hierarchical structure. Salesforce has no native equivalent. We migrate the organization hierarchy as a custom field on Account and Case (service_organization__c) with the full hierarchical path stored as a text string for reporting. Group membership and assignment routing are reconstructed in Salesforce using Queues or Public Groups, which we document in the migration handoff.

ServiceNow Knowledge Articles migrate to Salesforce Knowledge with article text, metadata, and URL names preserved. HTML content is preserved and rendered at the destination. We map ServiceNow article categories to Salesforce Data Categories or article type structures depending on whether the destination uses the structured or legacy Knowledge data model. Article version history migrates as a custom field snapshot since Salesforce Knowledge does not natively preserve version chains.

ServiceNow file attachments on Cases and Case Tasks use the Attachment API with document IDs. We extract files and re-associate them post-ingress using Salesforce ContentDocument and ContentDocumentLink, linking each document to the parent Case or Task record. Files without a recognized parent are held in a staging ContentWorkspace and flagged for the customer's admin to relink manually.

Nearly every CSM instance carries schema extensions beyond the standard tables. We export the full extended schema including choice list values, reference field targets, and UI-only display flags, then reconstruct equivalent custom fields in Salesforce before any data import. Field types are mapped to the closest Salesforce equivalent: ServiceNow reference fields become lookups, choice lists become picklists or multi-select picklists, and URL fields become URL fields. Any unmappable field types are flagged in the schema inventory for the customer admin to review.