How to migrate from Salesforce Service Cloud to Zendesk

Migrating from Salesforce Service Cloud to Zendesk is a major shift in your customer support stack, but with the right plan, you can minimize disruption and preserve critical data, workflows, and reporting. This guide walks through every step of the migration process, from planning and data mapping to execution, testing, and go‑live.

1. Understand why you’re migrating

Before you touch any data, get clear on your objectives. This will guide which features to prioritize and what data to bring over.

Common reasons teams move from Salesforce Service Cloud to Zendesk include:

Simplifying a complex Service Cloud setup
Lowering administrative overhead and license costs
Getting agents into a more intuitive, support-focused interface
Improving response times and customer satisfaction
Consolidating channels into a unified omnichannel workspace

Document:

Your current Service Cloud pain points
What Zendesk must do on day one (MVP requirements)
Nice-to-have features you can roll out later

This becomes your migration “north star” and helps avoid scope creep.

2. Audit your current Salesforce Service Cloud setup

A thorough audit of your existing environment is critical. You need to know exactly what you’re migrating and what can be left behind.

Key elements to review:

2.1 Data model and objects

Identify and document:

Cases (primary support tickets)
Contacts & Accounts (customers / organizations)
Users (agents, admins, managers)
Custom objects (e.g., RMAs, entitlements, products)
Related case data:
- Case comments / email messages
- Attachments
- Case history (status changes, owner changes)
- Tasks and events

Note which objects are:

Required for daily operations
Only needed for historical reference
Obsolete and safe to archive instead of migrating

2.2 Fields, picklists, and customizations

For each key object (especially Cases, Contacts, Accounts):

List standard fields in use
List custom fields (API names, data types, purposes)
Document picklist values (e.g., statuses, priorities, reasons)
Identify any validation rules and required fields

This will be essential when you map Salesforce fields to Zendesk ticket fields, user fields, and organization fields.

2.3 Workflows, automation, and routing

Catalog:

Assignment rules / auto-routing
Escalation rules and SLAs
Email templates and auto-responses
Macros and quick actions
Approval processes
Triggers, flows, and process builder automations

Mark which ones:

Must be replicated in Zendesk (e.g., priority SLAs)
Can be simplified or retired

2.4 Channels and integrations

Note all channels currently configured in Service Cloud:

Email-to-case
Web-to-case forms
Live chat
Phone / CTI integration
Social channels (Twitter, Facebook, etc.)
Knowledge and support portals (Experience Cloud)

Also list:

Third-party integrations (e.g., Jira, Slack, e-commerce, billing)
Internal systems that read/write case or contact data

This will drive your Zendesk channel and app configuration.

3. Plan your Zendesk architecture

Zendesk structures customer service differently than Salesforce. Designing your Zendesk environment first helps you know where everything should go during migration.

3.1 Choose your Zendesk products and plan

Common components:

Zendesk Support – core ticketing system
Zendesk Guide – help center / knowledge base
Zendesk Chat & Messaging – live chat and messaging channels
Zendesk Talk – integrated call center
Zendesk Explore – reporting and analytics

Confirm:

Which products you’re licensing
The Zendesk plan level (affects features like custom roles, SLAs, etc.)

3.2 Define groups, roles, and permissions

Map your Salesforce roles and teams to Zendesk:

Create groups for:
- Support tiers (Tier 1, Tier 2, Escalations)
- Specializations (Billing, Technical Support, Sales Support)
- Regional teams (EMEA, APAC, North America)
Configure roles:
- Agents, team leads, managers, admins
- Permissions for ticket editing, reporting, admin access

This ensures tickets are routed and visible to the right people post-migration.

3.3 Map Salesforce objects to Zendesk entities

At a high level:

Cases → Tickets
Contacts → Users (end users)
Accounts → Organizations
Products / contracts / entitlements → Custom fields / custom objects (if needed via apps or Zendesk custom resources)
Case comments → Ticket comments
Tasks / activities → Internal notes or tags (depending on use)

Create a mapping document that specifies:

Salesforce object → Zendesk entity
Salesforce field (label + API name) → Zendesk field
Data type conversions and any transformations needed

4. Map fields and configurations in detail

Field mapping is one of the most important migration tasks. A careful mapping avoids data loss and confusion.

4.1 Ticket fields (Cases → Tickets)

For each Salesforce Case field, decide:

Will it be:
- A standard ticket field (subject, description, priority, status)?
- A custom ticket field?
- A tag (good for flags or categorical indicators)?
- Dropped entirely?

Examples:

Case Number → Zendesk ticket ID (auto)
Subject → Ticket subject (standard)
Description → Initial ticket comment
Status → Zendesk status (New, Open, Pending, On-hold, Solved, Closed)
Priority → Zendesk priority (Low, Normal, High, Urgent)
Origin → Ticket channel or a custom field
Case Reason → Custom dropdown ticket field
Product → Custom dropdown ticket field
Entitlement / SLA → SLA policy + possibly a custom field

Make sure:

Any Salesforce picklist values are recreated in Zendesk as dropdown values.
Default values and required fields in Zendesk align with your data.

4.2 User and organization fields

Map:

Contacts → End users
- Name, email, phone
- Account association → Organization membership
- Contact type, customer tier → Custom user fields
Accounts → Organizations
- Account name → Organization name
- Industry, size, region → Custom organization fields
- Any key IDs used for integration (e.g., CRM ID, ERP ID)

Ensure each user’s primary email is correct, as Zendesk uses email heavily for identity.

4.3 Status and lifecycle mapping

Service Cloud often uses custom case statuses. Align these with Zendesk’s statuses:

Salesforce New / Open → Zendesk New or Open
Salesforce Pending Customer → Zendesk Pending
Salesforce Waiting on Third Party → Zendesk On-hold
Salesforce Closed / Resolved → Zendesk Solved or Closed

Decide:

Which statuses represent “active work”
Which represent “waiting”
Which represent “done”

Configure Zendesk workflows and SLAs accordingly.

5. Decide what data to migrate (and what to archive)

You don’t always need to bring everything over from Salesforce. Migrating less—but more relevant—data makes Zendesk cleaner and faster.

Consider:

5.1 Active vs. historical cases

Common strategies:

Migrate all open and recently solved tickets
- E.g., all open/pending/on-hold cases plus the last 6–24 months of solved cases
Archive older historical cases
- Export to a secure data warehouse or storage (e.g., a BI tool, S3, or a database)
- Keep accessible via reporting or a lightweight internal tool

Factors to weigh:

Compliance and retention requirements
How often agents reference very old cases
Data volume and complexity

5.2 Attachments, comments, and logs

Decide whether to migrate:

All public and private comments
Attachments (size limits, storage costs)
Case history logs (status changes, owner changes)

Typically:

Comments are critical and should be migrated.
Attachments can be migrated where feasible; very large or old files might be archived externally.

6. Choose your migration method and tools

You can migrate from Salesforce Service Cloud to Zendesk using:

6.1 Native exports + imports

Export data from Salesforce using:
- Data Loader, Data Export, or report exports
Import into Zendesk using:
- CSV import tools for users, organizations, and tickets
- Zendesk API for more complex scenarios

Pros:

No additional cost
Full control over mappings and transformations

Cons:

Can be time-consuming and technical
Requires careful scripting for comments, attachments, and relationships

6.2 Third-party migration tools

Several ETL or migration platforms can help:

General-purpose ETL tools (e.g., Talend, Fivetran, Stitch, custom scripts)
Specialized help desk migration services (search for tools specifically supporting Salesforce Service Cloud → Zendesk migrations)

Pros:

Handle many complexities automatically (comments, attachments, relationships)
Often provide error logs and rollback options

Cons:

Added cost
Still require configuration, mapping, and validation

6.3 Custom API-based migration

If you have engineering resources:

Use the Salesforce APIs (REST, Bulk, or SOAP) to extract data
Use the Zendesk REST API to create users, organizations, and tickets
Script complex logic like:
- Preserving ticket IDs (as external IDs or custom fields)
- Maintaining original timestamps and authors
- Re-linking users, organizations, and tickets correctly

This gives maximum control but requires more development effort.

7. Configure Zendesk before migrating data

Don’t import data into an empty or misconfigured Zendesk environment. Set up the essentials first.

7.1 Basic account setup

Configure brands (if you support multiple brands)
Set timezone, business hours, and language
Turn on SLAs and configure business rules as needed

7.2 Channels

Set up equivalent or improved channels:

Email: Support addresses and forwarding to Zendesk
Web forms: Contact forms embedded in your website or help center
Help center (Guide): Categories and sections; initial articles
Chat, Messaging, Talk: Configure as needed based on your audit

Avoid pointing production traffic to Zendesk until you’re ready to go live, but ensure everything is staged.

7.3 Ticket fields, user fields, and organization fields

Create all necessary custom fields based on your mapping document
Configure default values and field order on ticket forms
Create multiple ticket forms if you support different request types

7.4 Business rules and automation

Recreate key behaviors from Service Cloud:

Triggers:
- Auto-assign tickets based on channel, subject, or fields
- Set priorities based on type or customer tier
- Add tags for routing or reporting
Automations:
- Reminders for pending customer responses
- Notifications for breaches or escalations
Views:
- Queues for each team (e.g., Tier 1, Billing)
- “My open tickets,” “Unassigned tickets,” “High priority”

Keep initial workflows as simple as possible. You can refine after agents start using Zendesk.

8. Build and test your migration in a sandbox

Never run your first migration directly into your live Zendesk production environment.

8.1 Use sandbox or test environments

Salesforce: Use a Full or Partial sandbox if available, or a representative subset of data
Zendesk: Use a Zendesk sandbox (enterprise plans) or a test instance if sandbox isn’t available

8.2 Run a pilot migration

Select a sample set of data, for example:

A few hundred users and organizations
200–500 tickets across various priorities, statuses, and channels
A mix of old and new cases

Migrate them, then validate:

Fields appear correctly
Comments are in order, with correct authors and timestamps (if preserved)
Attachments open and are associated with the right tickets
Users are correctly linked to organizations and tickets
SLAs and triggers work as expected on migrated tickets (if applicable)

8.3 Gather feedback and refine

Ask:

Agents: Are the tickets readable? Does the history make sense?
Admins: Are fields clear and usable? Are views and workflows correct?
Reporting owners: Can they get the metrics they need in Zendesk Explore?

Adjust mappings, cleanup rules, and scripts based on findings, then re-run the test as needed.

9. Plan your cutover strategy

A well-planned cutover minimizes downtime and confusion for both agents and customers.

9.1 Choose a migration window

Pick a low-volume period:

Overnight or weekend for your primary region
Align with your business hours and coverage

Decide:

Big bang migration:
- Migrate all targeted data at once
- Switch channels over in a single window
Phased migration:
- Migrate older/historical tickets first
- Switch live ticketing only at the final cutover

9.2 Define read-only vs. active systems

Common approach:

After cutover:
- Salesforce Service Cloud becomes read-only for historical reference
- Zendesk becomes the system of record for all new and updated tickets

Communicate clearly to agents which system to use for what and from which date.

9.3 Keep a backlog sync strategy (optional)

For longer transitions, some teams:

Sync open cases from Salesforce to Zendesk
Prevent new case creation in Salesforce
Or maintain a one-way sync of status updates for a defined period

This requires more complex integration and should be carefully managed.

10. Execute the production migration

When you’re confident in your test runs, it’s time for the real migration.

10.1 Pre-migration checklist

Confirm:

All needed custom fields and forms exist in Zendesk
Groups, roles, and views are set up
Channels are configured but not yet fully switched over
Data exports from Salesforce have been validated (no major gaps)
Scripts or tools are tested and ready

10.2 Migration sequence

A typical sequence:

Freeze changes in Salesforce (or strongly limit new cases)
Export users and organizations from Salesforce
Import users and organizations into Zendesk
Export tickets (cases), comments, and attachments
Import tickets into Zendesk in batches:
- Older/historical tickets first
- Recent and open tickets next
Switch channels:
- Update email routing (DNS / forwarding) to Zendesk
- Update web forms to create Zendesk tickets
- Re-point chat, messaging, and phone routing to Zendesk
Verify sample data and run smoke tests:
- Create test tickets
- Ensure agents can work tickets end-to-end

10.3 Monitor and handle errors

Expect some errors (data mismatches, invalid fields, etc.):

Review error logs from your migration tool or scripts
Correct data and re-import failed records
Keep a documented list of known issues and resolution steps

11. Train your team on Zendesk

Agents moving from Salesforce Service Cloud will need new muscle memory and workflows.

11.1 Role-based training

Agents:
- Working in the Zendesk agent workspace
- Using macros, views, and ticket fields
- Communicating via email, chat, and phone within Zendesk
Team leads & managers:
- Managing queues with views
- Approving or escalating tickets
- Basic reporting and dashboards
Admins:
- Maintaining ticket fields, forms, and workflows
- Managing users, organizations, and groups
- Building triggers, automations, and SLAs

Provide quick reference guides and short videos to speed up adoption.

11.2 Change management and communication

Communicate clearly:

Why the migration is happening
The benefits of Zendesk for agents and customers
The exact date/time of cutover
Where to go for help and how to report issues

Strong change management reduces resistance and accelerates adoption.

12. Validate, optimize, and clean up after go-live

Once Zendesk is live, the work isn’t over. Plan a post-migration stabilization period.

12.1 Validate data and workflows in production

In the first days/weeks:

Spot-check migrated tickets for accuracy
Verify that users and organizations are correct and deduplicated
Confirm SLAs and triggers are behaving as intended
Monitor for routing issues (tickets stuck, wrong queues, etc.)

12.2 Gather agent and stakeholder feedback

Hold feedback sessions:

What’s working well in Zendesk?
What’s confusing or missing?
Which views, fields, or macros need refinement?

Use this feedback to make targeted improvements, not wholesale changes.

12.3 Optimize reporting and dashboards

With Zendesk Explore:

Rebuild key KPIs from Salesforce:
- First response time
- Resolution time
- Backlog size
- CSAT, NPS (if applicable)
Create role-specific dashboards:
- Agent performance
- Queue health
- Channel-specific metrics (chat, phone, email)

Ensure leaders can access the insights they relied on in Service Cloud.

12.4 Decommission or archive Salesforce Service Cloud

After a defined period (e.g., 3–6 months):

Fully decommission Service Cloud or reduce licenses to a bare minimum
Archive any remaining historical data according to your retention policy
Document the final system of record for audits and compliance

13. Common pitfalls when migrating from Salesforce Service Cloud to Zendesk

Avoid these frequent issues:

Migrating too much legacy data and cluttering Zendesk
Poor field mapping, leading to confusing or broken workflows
Skipping sandbox testing, resulting in production issues
Underestimating agent training needs
Not aligning statuses and SLAs, causing missed expectations
Ignoring integrations, leaving downstream systems out of sync

Plan for these in advance and incorporate checks into your migration plan.

14. Summary: A structured approach to a smooth migration

To migrate from Salesforce Service Cloud to Zendesk successfully:

Clarify your goals and audit your current Service Cloud setup.
Design your Zendesk architecture (groups, fields, workflows).
Map objects and fields carefully (Cases → Tickets, Contacts → Users, Accounts → Organizations).
Decide which data to migrate and which to archive.
Configure Zendesk and test a pilot migration in sandbox.
Plan and execute a well-communicated cutover window.
Train agents thoroughly and support them post-go-live.
Validate, optimize, and gradually decommission Salesforce.

With a clear plan, careful data mapping, and strong change management, your migration from Salesforce Service Cloud to Zendesk can deliver a cleaner, more efficient support operation that’s easier for both agents and customers to use.