Migrate from ServiceNow Customer Service Management to Zendesk

ServiceNow CSM Cases map to Zendesk Tickets. The Case number becomes the Ticket ID stored in a custom field servicenow_case_number__c for cross-reference. Case state (active, on-hold, resolved, closed) maps to Zendesk Ticket Status with a custom field servicenow_state__c preserving the original CSM state value. Priority, Assignment Group, and Assignee resolve to Zendesk Ticket Priority and Assignee via user email lookup. Parent-child Case Task relationships are resolved before Ticket creation so that all child context is attached as Ticket Comments or merged into the parent Ticket body.

Case Tasks migrate as Zendesk Ticket Comments ordered by the Task sequence number, preserving the original task body and assignment chain. If the Case Task represents a materially distinct work item that warrants a separate record, we create a linked Sub-ticket via Zendesk's native parent-child ticket relationship and link it by ID. Task state, due date, and assigned-to fields migrate as comment metadata or as a custom fields on the parent Ticket.

ServiceNow CSM Accounts map to Zendesk Organizations. The Account name becomes Organization name, and the Account sys_id is stored in a custom field servicenow_account_id__c. Account hierarchy (parent Account relationships) migrates to Zendesk Organization domains and parent Organization fields where supported. If the destination Zendesk instance uses the Enterprise plan, we configure multi-org hierarchical structures; otherwise we flatten to a single level and flag parent-child relationships as custom fields.

ServiceNow CSM Contacts (linked to Accounts) map to Zendesk end-user type Users. The Contact email becomes the User email and serves as the dedupe key. First name and last name split from the Contact full name field. We preserve the Contact-to-Account relationship by linking the User to the corresponding Zendesk Organization. Any custom Contact fields (department, title, access level) migrate as User custom fields.

ServiceNow CSM Consumer records (B2C person records, distinct from Contact in CSM's data model) map to Zendesk end-user type Users. Consumer records do not require an Account association in CSM; in Zendesk, they attach to an Organization or remain unorganized end-users at the customer's preference. Consumer-specific properties (consumer type, consent flags) migrate as custom fields on the User record.

ServiceNow Service Definitions define eligibility rules linking products, services, and case types. Zendesk has no native Service Definition equivalent. We export Service Definitions as structured JSON and store the full eligibility matrix in a custom Ticket field servicenow_service_definition__c, or distribute the relevant values (service category, entitlement tier) into individual custom fields. The customer's admin decides which Service Definition properties are operationally significant enough to surface on the Ticket form.

ServiceNow CSM Install Base tracks products sold to customers including warranty status and contract associations. Zendesk does not have a native Install Base object. We export Install Base records as structured JSON keyed to the Account or Consumer reference, and store product list, warranty status, and contract ID in custom fields on the Organization (for account-level context) or as Ticket custom fields (for case-level context). The customer chooses the strategy during scoping.

ServiceNow CSM Service Organizations (IBL/EBL/OSP hierarchy) represent internal and external business locations handling cases. Zendesk Groups model team ownership but not geographic or organizational hierarchy. We export the Service Organization hierarchy and map the top-level organization to a Zendesk Group, with subordinate levels stored in a custom field servicenow_service_org__c containing the full hierarchical path. If the customer uses Zendesk's Enterprise plan with SLA policies based on org location, we configure Zendesk Business Rules to replicate the routing logic.

ServiceNow CSM Knowledge Articles migrate to Zendesk Guide Help Center articles. We preserve article text (HTML), metadata (author, publish date, article ID, folder path), and attachments. Article versioning in ServiceNow collapses to the current published version in Zendesk; draft and retired versions are excluded unless specifically scoped. Zendesk's article search and AI-powered answer recommendations replace ServiceNow's Knowledge Management search. Article-to-Case associations (ServiceNow's knowledge article usage tracking) are exported as structured metadata for the customer's admin to configure in Zendesk's Article Feedback mechanism.

ServiceNow CSM file attachments on Cases and Case Tasks use the Attachment API with document ID references. We extract binary files via the ServiceNow Attachment API, re-upload to Zendesk as Ticket Attachments, and re-associate them to the correct Ticket. Attachments exceeding Zendesk's size limits are flagged and linked in the ticket body as URLs to a document store configured during scoping.

ServiceNow CSM instances routinely carry custom fields on Case, Account, Contact, and Consumer tables added via form configuration. We export the full extended schema using Table API queries that surface all columns, then create equivalent custom fields in Zendesk before data import. Zendesk supports text, numeric, date, dropdown, checkbox, and regex field types. Where a CSM field type has no Zendesk equivalent, we map to the closest type and flag for admin review. Choice list values and reference field targets are preserved in the mapping document.