The short version
- Zendesk tickets become Salesforce Cases, organizations become Accounts, end users become Contacts, and Help Center articles become Salesforce Knowledge articles.
- Public comments and internal notes must be loaded differently, or private notes can end up visible to customers.
- Rich text is the biggest trap. Case Description and Case Comments are plain text in Salesforce, so images and formatting need a plan.
- Inline images, attachments and links between tickets and articles all point back to Zendesk until they're re-hosted and rewritten.
- Triggers, macros, views and SLA policies don't migrate. They're rebuilt as Flow, Quick Text, list views and Entitlements.
- Plan the delta migration and cutover from day one, not at the end.
Already know what you need, or not sure where to start?
Either way, a short call is the quickest next step. Tell us what's in your Zendesk account and we'll walk you through the mapping, the timeline and what it would cost.
A Zendesk to Salesforce migration is really three projects in one: moving the data, rebuilding the support process in Service Cloud, and replacing the Help Center. This guide covers all three, based on the migrations we've delivered, including the details that most often cause rework.
Zendesk vs. Salesforce Service Cloud
Zendesk is a strong, support-focused platform with good self-service and ticketing out of the box. Salesforce Service Cloud is built on the same platform as your sales and marketing data, which is usually why teams move. Here's an honest comparison:
| Area | Zendesk | Salesforce Service Cloud | What it means |
|---|---|---|---|
| Customer 360 and reporting | Good | Stronger | Cases sit on the same Account as Opportunities, contracts and billing, with far more flexible reports and dashboards. |
| Customization and integration | Limited | Extensive | Custom objects, Flow, Apex, a full API and the AppExchange. |
| Sales and support on one record | Limited | Native | The whole customer journey is in one system instead of two synced ones. |
| Customer success and CSAT | Good | Good | Both collect CSAT well. Salesforce ties it to account health and renewals. |
| Standard support processes | Built in | Configured | CC handling, reopening closed tickets and the Solved-to-Closed flow come standard in Zendesk. In Salesforce they're configured during setup. |
Zendesk to Salesforce migration strategy in 8 phases
Migrating from Zendesk to Service Cloud needs analysis and planning before anything moves. We split the work into eight phases:
- Enable Service Cloud and agents. Licenses, profiles, permission sets, queues and Omni-Channel.
- Data migration. Users, organizations, end users, tickets, comments, attachments and Help Center articles.
- Support workflow migration. Triggers, automations, macros, views and SLA policies rebuilt in Salesforce.
- Integrations and third-party apps. Jira, voice, chat, WhatsApp, email and anything else connected to Zendesk.
- Help Center transition. A new Experience Cloud help center fed by Salesforce Knowledge.
- Training and adoption. Agents, supervisors and managers learn the new tool before go-live.
- Testing and validation. Sandbox runs, reconciliation and business sign-off.
- Post-migration support. Fixes, tuning and improvements once real work starts.
Zendesk to Salesforce object mapping
This is the generic data model mapping we start from. Every org adjusts it, but these are the decisions that come up every time.
| Zendesk | Salesforce Service Cloud | Notes |
|---|---|---|
| Agent | User (Service Cloud license) | Needed before tickets load so Case owners resolve. Check feature licenses too: Service Cloud User, Knowledge User, chat. |
| Group | Queue | Unassigned tickets land in the matching queue. |
| Organization | Account | Organization domains help match end users with no organization set. |
| End user | Contact | Plus an Experience Cloud user (Customer Community or Customer Community Plus) only if they log in to the new help center. |
| Ticket | Case | Status, priority, type and channel need value mapping. Zendesk ticket ID stored on every Case. |
| Public comment | EmailMessage or published Case Comment | EmailMessage keeps rich text and the email thread readable. |
| Internal note | Unpublished Case Comment or Feed post | Must never become visible in the customer portal. |
| Follow-up ticket | Parent Case | Set in a second pass once all Cases exist. |
| Attachment | File (ContentVersion) | Linked to the Case or the specific email it came with. |
| Ticket form | Record Type or Dynamic Forms | Each form usually becomes a record type with its own layout. |
| Custom ticket fields | Custom Case fields | Returned as a custom_fields list of IDs and values, so each ID needs mapping. |
| Tags | Topics or a text field | Depends on whether agents report on them. |
| CCs and followers | Case Team, email CC field, or custom field | Decide how CC behavior works in Salesforce before loading. |
| Satisfaction ratings | Custom object or Survey responses | Keep only if you still report on history. |
| Brands | Record Types, email-to-case addresses, or separate sites | Multi-brand setups need a design decision early. |
| Zendesk Talk calls | Voice Call records or Files | Recordings can be large. Check storage first. |
| Macros | Quick Text, Quick Actions, email templates | Rebuilt, with placeholders rewritten as merge fields. |
| Triggers, automations, SLA policies | Flow, assignment and escalation rules, Entitlements and Milestones | Rebuilt, not migrated. |
| Views | List views and Omni-Channel routing | A good moment to cut views nobody uses. |
Migrating Zendesk tickets and comments to Salesforce Cases
Data mapping and object setup
Before any tickets load, the Case object needs its new fields, record types and picklist values for Status, Priority, Type and Origin. Zendesk's statuses (new, open, pending, on-hold, solved, closed) rarely match Salesforce's defaults, and the Solved-then-Closed behavior has to be configured, not assumed.
Rich text in descriptions and comments
This is where most Zendesk migrations run into trouble. Zendesk descriptions and comments support rich text and inline images. In Salesforce:
- Case Description is a plain text area, so images and formatting are lost. Either tell the business about this limit or add a custom rich text field for the original description.
- Case Comment is plain text and has a length limit, so long comments get cut off. Images must be re-hosted in Salesforce Files and linked from the text.
- Feed posts support rich content and are a good fit for internal notes.
- EmailMessage keeps HTML and shows the conversation as an email thread, which usually suits public comments best.
Audit fields
Migrate audit fields: CreatedDate, LastModifiedDate, CreatedById, LastModifiedById and ClosedDate. Setting them requires the "Set Audit Fields upon Record Creation" permission for the migration user, enabled before loading. Some audit fields can be difficult to set in certain cases, so we also copy the original values into custom fields as a backup.
Custom fields and Jira issues
Zendesk returns custom fields as a list of IDs and values on each ticket, so every field ID needs mapping to a Salesforce field:
"custom_fields": [
{ "id": 27642, "value": "745" },
{ "id": 27648, "value": "yes" }
]If tickets are linked to Jira issues, the Jira issue numbers can be migrated into a Case field with an extra call to Zendesk's Jira integration API.
Attachments, voice calls and media
Decide early which attachments move, where they're stored and how they're linked. Attachments linked to the exact comment or email they arrived with are far more useful than a pile of files on the Case. Check Salesforce file storage against total attachment size, and check your org's daily limit on file versions before a large attachment load.
Migrating Zendesk Help Center to Salesforce Knowledge
Zendesk Help Center (Guide) organizes content as categories, then sections, then articles. Salesforce Knowledge uses Knowledge articles organized with Data Categories. Here's how it maps:
| Zendesk Help Center | Salesforce Knowledge | Notes |
|---|---|---|
| Article | Knowledge article (Knowledge__kav) | Title, body, labels and URL name mapped. Author and dates kept where possible. |
| Category | Data Category Group or top-level Data Category | Agree the new category design before loading. |
| Section (and subsection) | Child Data Category or Topic | Topics suit navigation in Experience Cloud; categories control visibility. |
| Article visibility (user segments) | Channels and data category visibility | Agent-only articles must never land on the public channel. |
| Draft / published | Draft / published article version | Articles are loaded as drafts, then published through the API. |
| Translations | Translated article versions | Each language enabled in Knowledge settings first. |
| Labels | Topics or a text field | Useful for search and related-article suggestions. |
| Inline images and videos | Salesforce Files and embedded video | Images re-hosted; video hosts added to Trusted URLs. |
| Article attachments | Files linked to the article | Kept with the article version. |
Links and cross-references
Articles that link to other articles, and tickets that link to articles, will still point to Zendesk after a plain copy. Every internal link needs rewriting to the new Salesforce article, otherwise users get sent back to the old system. We do this in a second pass once every article has its Salesforce URL.
Inline images and videos
Images in Help Center articles are hosted by Zendesk. They need to be downloaded, stored in Salesforce, and the image source rewritten. Embedded videos (YouTube, Vimeo, Loom, Wistia) work in Salesforce Knowledge once the host is added to Trusted URLs; otherwise Salesforce strips the embed.
Formatting and styling
Check headings, lists, tables and code blocks after migration. Zendesk's editor and Salesforce's rich text editor don't support exactly the same HTML, so some formatting needs cleaning, especially on older articles.
What we've learned from real Zendesk migrations
Archived tickets don't show up everywhere
Zendesk archives closed tickets after a while. Archived tickets stay available through the API but don't appear in views or search results, so an extract built on those misses history.
What we do: use Zendesk's incremental export API for tickets. It returns the full history, archived tickets included, and it's also how we pick up the delta before cutover.
Closed tickets can't be reopened in Zendesk
When a customer replies to a closed Zendesk ticket, Zendesk creates a follow-up ticket linked to the original. Migrate them as unrelated Cases and the history splits in two.
What we do: link follow-ups to the original Case as parent and child, and design the reopen process in Salesforce so it doesn't happen again.
Field lengths don't always fit
We've hit length problems on Case Description, Case Comments and Chatter posts. Zendesk content that fits there doesn't always fit in the Salesforce field.
What we do: measure the longest values per field during discovery and choose the target field (or a rich text field) before loading.
Migrated records can wake up scheduled automation
Thousands of old Cases landing at once can queue time-based Flows, scheduled jobs and paused flow interviews that fire days later.
What we do: pause automation for the migration user, and check for queued jobs and waiting interviews after every load.
Time zones shift dates
Zendesk returns timestamps in UTC. If the migration runs from a different time zone, dates can shift by a day in reports.
What we do: keep everything in UTC through the pipeline and spot-check dates against Zendesk after the sandbox run.
Zendesk to Salesforce migration checklist
Before migration
- Know the data volume for every object before giving a timeline or estimate.
- Agree how many sandbox runs there will be, and whether each is a sample or a full load.
- Confirm tools and access upfront: API access to Zendesk, a Salesforce migration user, and whatever ETL tooling is used. Missing access delays everything.
- Get field mapping signed off by stakeholders. Missing even one field can mean reloading or updating every record.
- List audit fields (CreatedDate, LastModifiedDate, CreatedById, LastModifiedById, ClosedDate) and enable Set Audit Fields.
- Check licenses before loading users: Service Cloud User, Knowledge User, chat, and external licenses.
- Create an External ID field on every object to store the Zendesk ID. Mark it unique and external.
- Check limits: field lengths, API limits, the daily file-version limit, and data and file storage. Flag heavy storage use early, because Salesforce storage is expensive.
- Agree on time zone handling for date fields.
- Plan the delta migration and cutover for records created in Zendesk during the migration window.
During migration
- Turn email deliverability off in sandboxes, and invalidate email addresses on Users, Leads and Contacts there.
- Deactivate email alerts and any triggers, Flows or workflows that shouldn't run on migrated records. This also speeds up the load.
- Track every failed record and reprocess it. Otherwise records quietly go missing.
- Re-host images in rich text fields and update the image source.
- Rewrite inline links to the new Salesforce records, or users get sent back to Zendesk.
- Bring over fields you're unsure about into custom fields. Stakeholders often ask for them later.
After migration
- Sanity-check records for every object.
- Reconcile counts per object between Zendesk and Salesforce.
- Share reports on the migrated data for stakeholders to verify and approve.
- Clear jobs the load triggered: time-based Flows, scheduled Apex and paused or waiting flow interviews.
- Check portal visibility from a customer login, so no internal note or agent-only article is exposed.
Rebuilding workflows, automation and integrations
Business requirement analysis
A migration is a good chance to improve the process, not just copy it. We set time aside with the business to confirm what's actually needed and what can go:
- Understand existing Zendesk processes, triggers, automations and macros.
- Define requirements for data mapping, automation and integrations.
- Document the changes to introduce in Service Cloud.
Support process in Salesforce
- Ticket management: list views, page layouts, search and access control, set up the Salesforce way.
- Channels: Email-to-Case, web and portal case forms, phone and chat.
- Macros and workflows: case status flow, acknowledgment emails, first response, and SLAs through Entitlements and Milestones.
Service Cloud setup
- User personas through profiles and permission sets: agents, supervisors, managers and leadership, each with the right dashboards.
- Case management: Case fields, support processes, record types, page layouts, Lightning record pages and support settings.
- Routing: Omni-Channel, queues and the supervisor console.
Automation
Zendesk triggers usually become record-triggered Flows or Apex triggers. Time-based automations become scheduled paths in Flow. Macros become Quick Text, Quick Actions and email templates.
Integrations
List every integration connected to Zendesk (Jira, voice, WhatsApp, chat, email tools and others) and decide how each one connects to Salesforce. Some have native Salesforce connectors; others need a custom build. See our Salesforce integration services.
Moving the Zendesk Help Center to Experience Cloud
The Zendesk Help Center is replaced by a Salesforce Experience Cloud site (formerly Community). Experience Builder handles most of it with clicks, though some custom components in LWC and Apex are usually needed.
- Point your help center domain at the new site.
- Set up self-registration and login.
- Build the new case form with case deflection, so customers see relevant articles before submitting.
- Add chat or an Agentforce agent to answer common questions from Knowledge.
- Customize the article page and track what customers search for and read.
- Redirect old Help Center article URLs to the new ones to keep search traffic.
More on this in our Experience Cloud services.
Training and adoption
Agents are the ones living in the new system every day, so they need to be comfortable before go-live:
- Explain what gets easier for them, not just what changes.
- Document the current Zendesk processes before replacing them.
- Look for better native ways to do things in Salesforce instead of copying Zendesk habits.
What you get after moving to Service Cloud
- One view of the customer across sales, support and success.
- Omni-Channel routing and a supervisor console to manage agent workload live.
- Digital channels like WhatsApp, SMS, voice and chatbots on the same Case record.
- Knowledge and self-service that deflects cases before they're logged.
- AI features like case classification, reply recommendations and Agentforce.
- Lower tool sprawl once support, CSAT and reporting run on one platform.
How Tenetizer helps with Zendesk to Salesforce migration
We handle the full move: data migration with our in-house tool, Service Cloud setup, workflow rebuild, integrations, and the new Experience Cloud help center. We also set up AI features such as case classification, reply recommendations and Agentforce agents. See our wider Salesforce data migration services, including Freshdesk to Salesforce and HubSpot to Salesforce migrations.
Frequently asked questions
How long does a Zendesk to Salesforce migration take?
Our migrations average 7 days of delivery once the field mapping is agreed and Salesforce is ready. Projects that also include Service Cloud setup, workflow rebuild and a new Experience Cloud help center take longer, depending on scope.
What Zendesk data can be migrated to Salesforce?
Tickets, public comments, internal notes, attachments, users, organizations, end users, custom fields, tags, satisfaction ratings, call records and Help Center articles with their categories, translations, images and attachments. Triggers, macros, views and SLA policies are rebuilt rather than migrated.
Can Zendesk Help Center articles move to Salesforce Knowledge?
Yes. Articles become Salesforce Knowledge articles, categories and sections become Data Categories, and links, images and embedded videos are carried over and fixed to work in Salesforce.
Will internal notes stay private after migration?
Yes, if they're loaded correctly. Public comments and internal notes are migrated separately, and we check visibility from a customer portal login before sign-off.
Can we keep original ticket numbers and dates?
Salesforce generates its own Case numbers, so the Zendesk ticket ID is stored on every Case and is searchable. Original created, modified and closed dates are kept by enabling "Set Audit Fields upon Record Creation" before loading.
What happens to archived and closed Zendesk tickets?
They're migrated too. We extract through Zendesk's incremental export API, which includes archived tickets, and follow-up tickets are linked to the original Case.
Will inline images and videos still work after we close Zendesk?
Yes. Images from tickets and articles are downloaded and stored in Salesforce. Embedded videos from YouTube, Vimeo and similar hosts keep working once the host is added to Salesforce's Trusted URLs.
Do links between tickets and articles keep working?
Yes. We rewrite links in a second pass once every Case and article exists in Salesforce, so nothing points back to Zendesk.
Do Zendesk triggers, macros and SLAs migrate automatically?
No. They're rebuilt in Salesforce as Flows, assignment and escalation rules, Quick Text and Entitlements. It's a good time to drop the ones nobody relies on anymore.
How much does a Zendesk to Salesforce migration cost?
It depends on data volume, attachments, custom fields, and how much workflow and help center work is included. We give a fixed quote after a short assessment of your Zendesk account.
View all Zendesk to Salesforce migration FAQs
Planning a move from Zendesk to Salesforce?
Tell us roughly how many tickets and articles you have and which tools connect to Zendesk. We'll come back with a mapping outline, a timeline and a fixed quote.
Book a free migration consultation