Zendesk to Salesforce Data Migration

A Zendesk to Salesforce data migration isn't an export problem in either direction. The hard part is the fortnight when both systems are live.

Decide the scope before the mapping

The instinct is to move everything. Resist it, because history is the most expensive and least used part of any helpdesk migration.

Three scopes, in increasing order of pain:

People and open work only. Users, accounts and every ticket that isn't closed. Fastest, cheapest, and enough for most teams.
The above plus a rolling window of closed tickets, usually twelve or twenty four months. This is the sensible default.
Everything, forever. Justifiable when regulation demands it and rarely otherwise. Consider a read only archive or an export in cold storage instead, since nobody searches a four year old solved ticket in the new system.

Agree the scope with the people who will actually be asked for old records. Legal and finance, usually, not support.

Zendesk to Salesforce data migration: what maps cleanly

ZendeskSalesforce Service CloudNotes
TicketCaseThe core mapping. Status and priority values need translating.
End userContactStraightforward, subject to matching on email.
OrganizationAccountUsually clean for B2B, meaningless for consumer desks.
Ticket commentsCase comments or feed itemsPublic and internal must stay distinguishable.
AttachmentsFiles linked to the caseVolume here drives migration time more than anything.
Custom fieldsCustom fields on CaseOne to one only if types line up. Drop lists need care.
Help centre articlesKnowledge articlesContent moves, theming and structure do not.

What doesn't map at all

This is the list nobody sends you at the start of the project.

Automation logic. Zendesk triggers, automations and macros have no import path into Salesforce flows, assignment rules and quick text. It's a rebuild, and it's usually the largest line in the plan.
Views and dashboards. Rebuild in reports and list views. Take the opportunity to build fewer.
SLA policies. Concepts overlap, definitions do not. Entitlements and milestones in Service Cloud need designing rather than importing.
Merge history. Zendesk merge relationships and the closed_by_merge tag mean nothing on the other side, so merged pairs land as an odd closed record unless you handle them.
Satisfaction ratings and side conversations, which map partially at best. Decide early whether you need them or a CSV of them is enough.
Ticket IDs. They will change. Store the old ID in a custom field on every migrated case, because you will spend the next year with customers quoting numbers from the old system.

The parallel period is the risk

Almost nobody cuts over instantly. There's a window, days or weeks, when both systems can receive work, and that window is where the damage happens.

A customer replies to an old Zendesk notification while your new address routes to Salesforce. Now the same conversation exists as an open ticket in one system and a new case in the other. Two agents, two answers, one confused customer. This is the single most common failure of a helpdesk migration and it's entirely predictable.

Three controls, all boring, all effective. Freeze new ticket creation in the source system on a stated date and forward its inbound mail to the new one. Run a delta migration for everything created or updated after the initial export. And before go live, deduplicate the source, because every duplicate you migrate becomes two cases you now maintain in a system where merging works differently.

How to actually move the data

Three routes, and the choice is mostly about volume and how weird your data is.

A migration vendor. Fixed price, they've done it before, they handle the API tedium. The usual choice above a few thousand tickets. Ask specifically how they handle attachments, merged tickets and custom field types.
Custom against the APIs. Read from the Zendesk API, write via the Salesforce Bulk API. Full control, and you own rate limits, retries and the delta run. Reasonable if you have engineers and unusual requirements.
CSV and Data Loader. Fine for contacts and accounts. Painful for tickets with threaded comments and attachments, and it's where most self service attempts stall.

Whichever you pick, test on a subset into a sandbox and have real agents open twenty migrated cases and tell you what looks wrong. They will find things no mapping document catches. See Zendesk migration for the platform agnostic checklist and Zendesk vs Salesforce if the decision itself is still open.

Cutover week, in order

The plan that works is dull and specific. Write it down and give each line an owner.

Two weeks out. Full test migration into a sandbox. Agents review. Automation rebuild is finished, not started.
One week out. Deduplicate and tidy the source. Close what should be closed. Tell customers nothing, because they don't care which system you use.
Freeze day. Stop new ticket creation in the source, redirect inbound mail, publish the new support address everywhere it appears.
Cutover. Delta migration for anything created or updated since the main export. Verify counts by status, not just a total.
Week one after. Keep the old system read only and accessible to agents. Do not revoke it early. Somebody will need it on day three, and they'll need it in the middle of a customer call.

Then leave the old system dormant for a quarter before you cancel it. The licence is cheaper than the panic.

FAQ

Frequently asked questions

Is this the same as a Service Cloud migration?

Yes. A Zendesk Service Cloud migration is this migration under Salesforce's product name, since Service Cloud is the support half of Salesforce.

How long does a Zendesk to Salesforce data migration take?

Data movement is days. The project is weeks to months, because rebuilding automations, SLAs and reporting is the real work, not the export.

Do ticket IDs survive the migration?

No. Salesforce assigns its own case numbers. Store the original Zendesk ID in a custom field so customers quoting old numbers can still be found.

Can we migrate from Salesforce to Zendesk instead?

Yes, the same mapping runs in reverse and the same gaps apply. Automation, SLA and reporting logic still has to be rebuilt by hand.

What causes duplicate cases during a migration?

The parallel period. Customers reply to old notifications while new mail routes elsewhere, so one conversation becomes a ticket and a case.

Should we migrate closed tickets?

A rolling window of twelve to twenty four months suits most teams. Full history is worth it only when regulation requires it, and an archive often serves better.

Migrate a clean queue

Duplicates you migrate become duplicates you maintain. Ticket Merger clears them out of Zendesk before the export, and keeps the new queue clean after.

Start free trial

14-day free trial. No credit card required.