Helpdesk migration
Field-level mapping, validation, and rollback between Service and Zendesk. We move data and schema; workflows are rebuilt natively in Zendesk.
Service
Source
Zendesk
Destination
Compatibility
12 of 12
objects map 1:1 between Service and Zendesk.
Complexity
BStandard
Timeline
48–72 hours
Overview
Salesforce Service Cloud organizes support around Case, Contact, Account, and Entitlement objects with a status pick-list that differentiates open, pending, and closed states. Zendesk Support uses Tickets, Users, and Organizations with a separate status (New, Open, Pending, Solved, Closed) and a field-based satisfaction rating. We map every Case field to its Zendesk equivalent — Subject and Description to ticket subject and description, Case Status to ticket status via a value-mapping table, and Priority to a custom priority field on Zendesk tickets. Salesforce entitlements and assets migrate as custom fields on the mapped Zendesk tickets. Escalation rules, flows, approval processes, and service contracts do not migrate — we export your Salesforce workflow definitions as a rebuild reference for Zendesk triggers and macros. We use Salesforce Bulk 2.0 API for high-volume exports and Zendesk REST API for imports, with a 24–48 hour delta-pickup window capturing any cases created or modified during the cutover window. All timestamps, case owners, and contact associations are preserved through email-based user resolution.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Service object lands in Zendesk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Service
Case
Zendesk
Ticket
1:1Direct 1:1 map. Salesforce Case maps to Zendesk Ticket — Subject to subject, Description to description, CaseNumber preserved as custom field Source_Case_Number__c. Case Status pick-list values map to Zendesk ticket status values via a value-mapping table before import. The value-mapping table is built during the planning phase and reviewed with your admin before migration executes.
Service
Contact
Zendesk
User
1:1Direct map for end-user contacts. Salesforce Contact becomes a Zendesk User with the requester role. Agents (users with Salesforce licenses) map to Zendesk agents. Email is the match key — contacts without emails become users with a placeholder email and flagged for follow-up.
Service
Account
Zendesk
Organization
1:1Salesforce Account maps to Zendesk Organization. Parent-account hierarchies map to Zendesk child organizations where the same parent-child relationship exists. Annual revenue, industry, and website fields migrate as Organization custom fields in Zendesk. Parent accounts must be migrated before child accounts to maintain the hierarchy correctly.
Service
CaseComment
Zendesk
Comment
1:1CaseComment public comments map to Zendesk public Comments on the ticket. IsPublished=false comments map to Zendesk internal notes. Original CreatedDate and CreatedById are preserved as comment metadata. HTML-formatted comments are converted to plain text for Zendesk's comment renderer. The IsPublished flag determines public vs internal visibility.
Service
EmailMessage
Zendesk
Comment
1:1Salesforce EmailMessage (incoming and outgoing emails linked to a Case) maps to Zendesk ticket comments. Email headers, HTML body, and attachments are preserved. ThreadId from Salesforce EmailMessage is stored as a custom comment field for email threading continuity. Incoming emails become requester comments; outgoing emails become agent comments.
Service
Asset
Zendesk
Custom Field on Ticket
1:1Salesforce Asset has no native Zendesk equivalent. We migrate Asset.Name, Product2.Name, InstallDate, Status, and WarrantyEndDate as custom fields on the Zendesk ticket (Asset_Name__c, Product__c, Install_Date__c). Asset serial number stored as Asset_Serial__c for reference. Custom fields must be created in Zendesk before migration.
Service
Entitlement
Zendesk
SLA Policy + Custom Field
1:1Salesforce Entitlement objects define SLA terms (FirstResponseTime, ResolutionTime) per entitlement process. Zendesk SLA Policies are plan-based, not record-based. We migrate entitlement terms as a custom Entitlement_Name__c field on the ticket and surface SLA gaps in the migration report for Zendesk SLA plan setup.
Service
CaseTeamMember
Zendesk
Ticket Collaborators
1:1Salesforce CaseTeamMembers (internal collaborators on a case) map to Zendesk ticket collaborators. TeamMemberRole from Salesforce maps to a custom Collaborator_Role__c field in Zendesk. Public collaborators appear in the ticket thread; private collaborators are noted in the audit log. Collaborator access levels are preserved during migration.
Service
Product2
Zendesk
Custom Field on Ticket
1:1Salesforce Product2 records linked to Cases via ProductId map to a custom field Product_Name__c on Zendesk tickets. Product family, product code, and description are stored as additional custom fields for product-context visibility in the Zendesk agent view. Agents can filter tickets by product without navigating away from the ticket.
Service
KnowledgeArticleVersion
Zendesk
Article (Guide)
1:1Salesforce Knowledge articles migrate to Zendesk Guide articles. ArticleTitle maps to article title, Summary to article body, and ArticleNumber stored as a custom field for source traceability. Categories map to Zendesk Sections; Section names require a pre-migration setup plan to ensure the hierarchy aligns with your Zendesk Guide structure.
Service
CaseArticle
Zendesk
Article-to-Ticket Link
1:1Salesforce CaseArticle junction links articles to cases. We map this as a custom field Article_IDs__c on the Zendesk ticket containing the source Salesforce article IDs, so agents can see which knowledge articles were linked in the original case. This preserves the article-to-case relationship for reference during support handoff.
Service
Custom Object
Zendesk
Custom Object or Custom Field
1:1Salesforce Service Cloud custom objects (Enterprise orgs) map to Zendesk custom objects where available, or to custom fields on the ticket object. N:N custom object relationships require junction object recreation in Zendesk or a tag-based approach. We document all custom object schemas during the audit phase for accurate mapping.
| Service | Zendesk | Compatibility | |
|---|---|---|---|
| Case | Ticket1:1 | Fully supported | |
| Contact | User1:1 | Fully supported | |
| Account | Organization1:1 | Fully supported | |
| CaseComment | Comment1:1 | Fully supported | |
| EmailMessage | Comment1:1 | Fully supported | |
| Asset | Custom Field on Ticket1:1 | Mapping required | |
| Entitlement | SLA Policy + Custom Field1:1 | Mapping required | |
| CaseTeamMember | Ticket Collaborators1:1 | Fully supported | |
| Product2 | Custom Field on Ticket1:1 | Fully supported | |
| KnowledgeArticleVersion | Article (Guide)1:1 | Fully supported | |
| CaseArticle | Article-to-Ticket Link1:1 | Fully supported | |
| Custom Object | Custom Object or Custom Field1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Service gotchas
Performance slowness in UI and load times is a documented issue
Zendesk gotchas
Data export requires API scripting on non-Enterprise plans
Automations cap at 500 active rules and 1,000 tickets per hour
Help Center has no native export feature
Custom Objects and full data export are Enterprise-only
Pair-specific challenges
Migration approach
Validate Salesforce Service Cloud environment and API access
FlitStack AI connects to your Salesforce org via API (OAuth 2.0 or username-password flow) to audit Case fields, pick-list values, custom objects, and entitlement configurations. We export the Case object schema including all custom fields, validate which Salesforce profiles have API access, and identify any locked or archived cases that require selective inclusion rules. This step produces a data dictionary used for all subsequent mapping decisions.
Resolve owners, contacts, and accounts by email before migration
Salesforce Case owners (User records), Case contacts, and Account records are resolved by email match against Zendesk agent and user accounts. We build a resolution table: matched users get their correct assignee_id in Zendesk; unmatched users are flagged and mapped to a fallback agent or the unassigned queue. Accounts resolve to Zendesk Organizations by name match; parent-account hierarchies are ordered so parent organizations exist before children are created.
Run a sample migration with field-level diff before full commit
A representative slice of cases (typically 100–500 records spanning different statuses, origins, and case types) migrates first. We generate a field-level diff between the Salesforce Case values and the Zendesk ticket values so you can verify priority mapping, status value mapping, entitlement field population, and comment threading before the full run commits. This is the decision gate — you approve the sample before we proceed.
Execute full migration with delta-pickup window
The full Case-to-Ticket migration runs using Salesforce Bulk 2.0 API for high-volume export and Zendesk REST API for ticket creation. A delta-pickup window (typically 24–48 hours after the full run starts) captures any cases created or modified in Salesforce during the cutover. All original CreatedDate, LastModifiedDate, and CreatedById values are preserved as ticket metadata. Audit log records every operation; one-click rollback is available if reconciliation finds unexpected gaps.
Platform deep dives
Service
Source
Strengths
Weaknesses
Zendesk
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. All 7 core objects map 1:1 between Service and Zendesk.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Service and Zendesk.
Object compatibility
All 7 core objects map 1:1 between Service and Zendesk.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Service: Configurable per-instance rate limits. ServiceNow enforces a default inbound transaction quota and inbound API rate limits that admins can tune by user, IP, or system property. HTTP 429 responses signal throttling..
Data volume sensitivity
Service exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Service to Zendesk migration scoping. Not seeing yours? Book a call.
Walk through your Service to Zendesk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Service
Other ways to arrive at Zendesk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.
