Migrate from CRM Service to Salesforce Sales Cloud

CRM Service Company records map to Salesforce Account. The company_name field maps to Account Name, and any additional CRM Service fields (industry, website, location) map to standard Account fields. We use Company sys_id as the external ID during import to enable subsequent Contact lookups without relying on name deduping.

CRM Service Contact records map to Salesforce Contact with AccountId resolved via the Company lookup. Email becomes Contact Email, phone becomes Phone, and first_name/last_name map to FirstName and LastName. We flag duplicate Contact creation when an incoming Contact email matches an existing Salesforce Contact and surface the conflict to the customer's admin for merge or skip decision.

CRM Service's unified person table holds both internal users and external contacts with a role discriminator. External persons with a customer role and no active Account association map to Salesforce Lead. The original person role is preserved in a custom field crm_service_original_role__c on Lead for audit. Internal users map to Salesforce User via the User mapping below.

CRM Service Issues map to Salesforce Case. issue_type maps to Case Origin, priority maps to Case Priority, and state maps to Case Status. The assigned_to reference resolves to a Salesforce User via the User mapping; the contact reference resolves to the Salesforce Contact via email match. We recommend excluding resolved Issues older than 24 months unless the customer specifically requires the full archive.

CRM Service Tasks map to Salesforce Task with Status, Priority, and due_date preserved. Task assignment migrates by resolving the assigned_to reference to Salesforce OwnerId via the User mapping. Closed tasks and open tasks both migrate by default unless the customer scopes only completed work.

CRM Service Knowledge records map to Salesforce Knowledge if the destination org includes the Knowledge object (available in Professional and above with a Knowledge add-on). Article titles, text, and category assignments migrate as KnowledgeArticleVersion and KnowledgeArticleDataCategory records. Without Knowledge enabled, articles migrate as Salesforce Chatter Files or custom Article objects documented for manual handoff.

Any custom table created in ServiceNow Studio exports with its table name as the object API name and all columns as fields. We pre-create the Salesforce custom object with a matching __c API name, all custom fields (with Salesforce-compatible types), and lookup relationships to standard objects before data load. Table-level ACLs from ServiceNow map to Salesforce field-level security and sharing rules configured by the customer's admin.

CRM Service Attachments stored in theAttachments table are exported to a staging location with their parent table and sys_id references. We re-upload each file as a Salesforce ContentVersion record and link it via ContentDocumentLink to the parent Salesforce record (Account, Contact, Case, or custom object) resolved via the original sys_id cross-reference map. Large attachments (over 35 MB per file) are chunked and uploaded via the Bulk API with binary handling.

CRM Service User records map to Salesforce User by email match. Active users get Active = true; inactive users default to Active = false unless the customer specifies archiving. We resolve ServiceNow roles and groups to Salesforce Profiles and Roles during scoping and recommend the customer provision any net-new Salesforce Users before the production migration phase.

CRM Service Groups map to Salesforce Queues. We create a Queue per ServiceNow Group during schema setup, and migrate Group membership by mapping each Group Member's User to the corresponding Salesforce User in that Queue. Queues for Cases and Leads are created separately from those for Opportunities if the customer uses both record types.

ServiceNow Departments migrate as a custom Division picklist on User or as a custom field on Account depending on whether the customer uses department for organizational reporting. We recommend the custom field approach for most migrations since Salesforce does not have a native Department object.

CRM Service SLA definitions have no direct Salesforce equivalent in Sales Cloud. We map SLA names and thresholds to a custom Entitlement Sla field on Case or a custom Case field tracking first response and resolution deadlines. The customer's Salesforce admin configures Salesforce Entitlements (Service Cloud feature) if SLA enforcement is required.

CRM Service Incident, Problem, and Change records all map to Salesforce Case with a Record Type discriminator so that each ServiceNow record type maps to a separate Case Record Type. Incident becomes Case Record Type = Incident, Problem becomes Case Record Type = Problem, and Change becomes Case Record Type = Change. This preserves the operational classification while consolidating into a single Salesforce object.

CRM Service Catalog items are configuration records without a Salesforce standard equivalent. We map catalog items to a custom object (Service_Catalog_Item__c) with fields for item name, description, category, and price. The customer rebuilds the catalog UX in Salesforce Experience Cloud or a custom Visualforce/Lightning page post-migration.

CRM Service Variables (catalog variables, record producer fields) map to custom fields on the Service Catalog Item custom object or on the parent Case record depending on variable scope. Variable types (string, boolean, reference, choice) map to equivalent Salesforce field types.

CRM Service CMDB Configuration Items do not have a standard Salesforce equivalent outside of Service Cloud's Asset object. For most sales-oriented migrations, we recommend mapping active Configuration Items to Salesforce Asset records linked to Account, and archiving stale CI records. If the customer requires the full CMDB, we create a custom Configuration_Item__c object.

CRM Service survey responses map to a custom CSAT_Score__c field on Case or to a related custom object (Survey_Response__c) linked to Case. Survey questions do not migrate as structured forms; we deliver the response data as records and a form rebuild recommendation for the customer's admin.