Migrate from Zendesk to Salesforce Service Cloud

Zendesk Tickets map directly to Salesforce Case records. The Zendesk ticket ID is stored in a custom field zendesk_id__c for cross-reference. Ticket Status (New, Open, Pending, Solved, Closed) maps to Salesforce Case Status values (New, Working, Escalated, Closed) — the customer configures the picklist mapping during scoping because Status semantics differ between the two platforms. Priority, requester, assignee, group, tags, and custom fields migrate directly. Each ticket comment thread migrates as an EmailMessage record linked to the Case for full conversation history.

Zendesk end-users (requesters) map to Salesforce Contacts. We resolve each requester by email address as the dedupe key. The requester's organization membership in Zendesk is preserved as the Contact's AccountId lookup. Custom fields on the Zendesk user profile migrate to custom Contact fields. Role assignment (agent vs. end-user) is encoded in the Contact record; agents migrate separately as Users rather than Contacts.

Zendesk agents map to Salesforce Users. We resolve agents by email address against the destination org's User table and preserve the Zendesk role (admin, agent, light agent) as a custom field on the User record. Group memberships map to Salesforce Queues and Group membership. Agents without a matching Salesforce User are held in a reconciliation queue for the customer's admin to provision before the migration resumes.

Zendesk Organizations map to Salesforce Accounts. The organization's domain names, details fields, and shared tags migrate to the Account record. Multiple Zendesk users can belong to one Organization — we preserve these memberships by setting AccountId on each Contact at import time. If the customer uses Zendesk's multi-brand feature with separate organizations per brand, each brand's organization maps to its own Account or a parent Account with child Accounts for subsidiaries.

Zendesk Brands (available on Growth through Enterprise, capped at 5-300 depending on tier) represent separate support identities with their own email addresses and help centers. We map each Brand to an Account for ticket ownership and optionally provision a separate Experience Cloud site if the customer requires a distinct self-service portal per brand. Brand routing rules map to Salesforce Omni-Channel routing configurations that the admin sets up post-migration.

Ticket comment attachments and Help Center article attachments are downloaded from Zendesk via the API, preserved with their original filenames and MIME types, and uploaded to Salesforce as ContentVersion records. ContentDocumentLink records attach each file to the parent Case or Article record. Attachments larger than 25 MB require chunked upload via the Salesforce chunked upload endpoint.

Zendesk tags are flat string labels on tickets, users, and organizations. We migrate all tag assignments to Salesforce as Case Tags (available on Enterprise and Unlimited) or as a custom multi-select picklist field on Case if the destination org does not have the Tagging feature enabled. Tag naming collisions are handled by appending the source object prefix during import.

Zendesk Help Center articles migrate to Salesforce Knowledge Base articles of the appropriate ArticleType. We extract article HTML content, section hierarchy, category structure, and all locale translations via the Zendesk Help Center API. Dynamic Content items (multilingual placeholders) are resolved to their default locale variant and mapped to Salesforce's locale fields. Article attachments migrate as ContentVersion records linked to the article. The customer must pre-create the ArticleType in Salesforce before migration begins.

Zendesk SLA Policies define first-response and resolution targets per plan or ticket type. There is no direct Salesforce equivalent — SLA Policies are rebuilt as Entitlements (the overall support commitment) and Milestones (first response, resolution) within the Salesforce Entitlement Management feature. We deliver a written inventory of every Zendesk SLA Policy with its targets, business hours, and escalation actions so the admin can recreate them in Salesforce Setup. SLA Policy data is not stored as records on migrated tickets.

Zendesk Macros are canned reply templates with variable substitution. We export full macro content, conditions, and variable placeholders as a structured document. In Salesforce, Macros map to either QuickText (agent-facing snippets) or Email Templates (outbound-facing). The variable substitution logic is documented separately because Salesforce uses merge field syntax (e.g., {{Contact.FirstName}}) that differs from Zendesk's ({{ticket.requester.name}}). We do not migrate Macros as executable Salesforce Macros.

Zendesk Custom Objects (available on Enterprise and Enterprise Plus plans only) have user-defined schemas with custom fields and lookup relationships to Tickets, Users, or Organizations. We migrate them to Salesforce custom objects with matching __c API names and field types. Lookup relationships are preserved only if the target custom object schema is created before migration begins. If the destination Salesforce org lacks the required custom object schema, we flatten the data into Case custom fields or a supplementary CSV.

Zendesk Views are saved ticket filters with columns and sort order. We export view definitions as structured data (conditions, filters, column layout) and deliver them as a written inventory. Salesforce List Views provide equivalent saved filter functionality per object. We do not create List Views as part of the migration; the inventory document gives the admin the filter logic to recreate them manually.