Migrate from Salesforce Service Cloud to Zendesk

Salesforce Cases map to Zendesk Tickets as the primary record. Case Origin, Status, Priority, and Record Type map to Ticket type, status, priority, and group or form respectively. CaseNumber becomes the Ticket ID reference; the original Salesforce Case ID is preserved in a custom field sfdc_case_id__c for reconciliation. If the source org has multiple Record Types, each maps to a Zendesk Form or Ticket field-based routing configuration. Case Description maps to Ticket description; Case Subject maps to Ticket subject or the first comment depending on the Zendesk configuration chosen during scoping.

Salesforce Contacts map to Zendesk End Users (sometimes called requesters). The Contact email becomes the User email, first name and last name map directly, and phone maps to user.phone. Multi-address Contacts require decision during scoping: the primary address migrates as the user address and secondary addresses are noted in a custom field. If the destination Zendesk instance uses Agents as contacts for internal testing or customer-facing agent roles, we resolve that distinction before import.

Salesforce Accounts map to Zendesk Organizations. Account Name becomes Organization name, Industry maps to a custom Organization field if Zendesk's standard Industry taxonomy is used, and the Account billing address becomes the Organization address. Account hierarchy (parent Account relationships) has no direct Zendesk equivalent; we flatten the hierarchy during migration and note the parent-child relationships in a custom field parent_organization__c for reference.

Salesforce Case Comments map to Zendesk Comments. The IsPublished flag determines whether the comment lands as a public comment or an internal note in Zendesk. Public comments appear in the customer-facing ticket view; private notes are visible to agents only. Rich-text formatting in Salesforce case comments is sanitized during transform. The comment author resolves by email match to a Zendesk User or Agent.

Salesforce Case History tracks field-level changes on the Case record. Zendesk does not have a native equivalent audit log object for Tickets, but the Change Log feature on Zendesk Suite Enterprise and the Support Professional plan captures field updates on a timeline. We migrate selective Case History records as private Zendesk comments prefixed with [Audit], preserving the field name, old value, new value, and timestamp. Full historical field change tracking requires Zendesk Suite Enterprise add-on; we confirm the destination plan tier during scoping.

Salesforce Entitlements define SLA terms (response time, resolution time) linked to Contacts and Accounts. Zendesk SLA Policies are standalone configuration objects applied to Tickets based on Organization or tag conditions. We extract entitlement terms from the source org during scoping, create Zendesk SLA Policies with matching first-response and next-sla-breach targets, and apply them to Tickets via Zendesk's SLA Policy assignment rules post-migration. The entitlement-to-policy mapping is a configuration step, not a direct object migration.

Salesforce Case Milestones track entitlement breach windows with Remaining time and Completion date fields. When migrating to Zendesk, milestone breach calculations are handled natively by Zendesk SLA Policies using the SLA definition timestamps (business hours, first response, next update). We do not migrate historical milestone completion data as records; instead, we validate that open Cases with unmet milestones have corresponding open Tickets in Zendesk with correct SLA Policy assignments at migration cutover. Closed milestones are not recreated in Zendesk because Zendesk does not support milestone objects.

Salesforce Case Team Members assign agent roles to individual Cases. Zendesk has no native case team concept; agents are assigned individually to Tickets via the Assignee field. We convert Case Team Member assignments to a custom multi-select User field on the Ticket (cc_team_members__c) during migration, or we note the team role structure and recommend a macro set that replicates team-based assignment workflows. The approach is chosen during scoping based on the customer's Zendesk plan tier and workflow requirements.

Salesforce Knowledge Articles migrate to Zendesk Guide Articles. Article titles, body content, summary, and URL Name map directly. Salesforce article categories map to Zendesk article sections, and publishing states (Draft, Published, Archived) map to Zendesk's draft and published status. Article visibility permissions (internal vs customer-facing) translate to Zendesk article section permissions. Salesforce's article voting and view counts migrate as custom fields on the Zendesk article if the customer requires them for reporting.

Salesforce EmailMessage records on a Case migrate to Zendesk Comments using the email channel format. The email subject maps to the Ticket subject, the HTML body migrates as comment body, and the from/to/cc addresses are preserved as comment metadata. Attachments extract separately and link to the Zendesk Ticket as file attachments via foreign key resolution. Plain-text and HTML body variants require sanitization during transform to match Zendesk's comment rendering format.

Salesforce Users representing agents and admins map to Zendesk Agents. We resolve Users by email match against the Zendesk destination instance. Any Salesforce User without a matching Zendesk Agent record goes to a reconciliation queue for the customer's Zendesk admin to provision before the agent and case migration phases run. Active status, agent role, and group membership from Salesforce profile and queue assignments translate to Zendesk Agent permission sets and Groups.

Salesforce Assets represent products purchased by an Account and linked to Cases. Zendesk has no native Asset object. If Assets are used for case context only (not for lifecycle management), we migrate the asset name and status to custom Ticket fields (asset_name__c, asset_status__c). If Asset lifecycle tracking is a core requirement, we flag this gap and recommend an AppExchange asset management app or a separate asset tracking system to be evaluated post-migration.