Zendesk has announced that it will retire its Zendesk Sell CRM product by August 31, 2027. The company is narrowing its focus to customer service and support products, with increased investment in AI in that area. For companies using Zendesk Sell, this creates a clear requirement to choose a new CRM and plan a migration.
For many teams, the question is not whether to start Zendesk migration, but how to do it without disrupting support operations or losing historical data. Service processes, ticket history, reporting, and agent workflows all need to continue working during and after the transition.
Salesforce is often selected as a Zendesk alternative at this stage because it currently holds around 20.7% of the global CRM market, more than any other vendor. That market position signals long-term platform stability and continued product investment. A Zendesk to Salesforce migration, triggered by the Zendesk Sell retirement, also creates an opportunity to clean up outdated logic, review service processes, and consolidate customer data into one system.
This guide explains how to plan and execute that migration step by step, with a focus on data accuracy, process continuity, and agent readiness.
Zendesk vs Salesforce: what really changes
Zendesk and Salesforce are built for different purposes, which is why migrations between them require more than a simple data move.
Zendesk is designed primarily as a customer support platform. It centers on ticket handling, agent queues, and service-focused workflows. For many teams, it works well as a standalone support tool.
Salesforce, by contrast, is a full CRM platform. Service cases sit alongside accounts, contacts, sales data, and reporting in a single data model. This structure supports cross-team visibility and more advanced automation across the customer lifecycle.
While Zendesk and Salesforce can be connected through integrations, those setups usually introduce duplicated data, sync dependencies, and ongoing maintenance. Over time, many teams move away from integration and toward a single-system model.
Understanding the difference between Zendesk and Salesforce is important before starting a Zendesk to Salesforce migration. The goal is not to recreate Zendesk inside Salesforce, but to redesign service processes in a system built for broader CRM use.
Migrating to Salesforce: measurable outcomes in practice
A good example of a successful move to Salesforce is the We Are Group case.
We Are Group is a UK-based organization working with vulnerable communities. As their operations grew, their existing support setup became harder to scale and maintain. The team needed better visibility across service processes, clearer ownership, and a platform that could support long-term growth.
After migrating to Salesforce, the organization:
- Consolidated 5 separate legacy systems into one Salesforce environment;
- Increased internal platform adoption from 25% to 75%;
- Reduced delivery timelines from 4 months to 2 months for new initiatives.
The new setup gave teams clear ownership, shared data, and faster coordination across departments. Support and operational teams worked from the same records, which improved reliability and reduced manual handoffs.
Zendesk Salesforce pre-migration checklist: analysing systems and processes before you start
A Zendesk to Salesforce migration should start with a clear understanding of how Zendesk is used today and how support work actually happens. Decisions made at this stage affect data quality, automation, reporting, and agent adoption later.
Step 1: Review your current Zendesk CRM setup
Begin with a structured review of the existing Zendesk environment. Many teams rely on configurations that were added over time and are no longer documented.
Start with ticket structure and configuration:
- Standard and custom ticket fields;
- Field types, required rules, and dependencies;
- Ticket statuses and priority logic;
- Macros, triggers, and automations, including why they were created.
Next, review channels and integrations:
- Support email addresses and routing rules;
- Ticket forms and required fields;
- Chat and phone tools that create tickets;
- Third-party apps connected to Zendesk;
- Zendesk API usage and sync frequency with other systems
Finally, review users and access:
- Agent roles and permission levels;
- Groups and team structure;
- Admin access;
- External or temporary users.
Step 2: Review service processes, not just configuration
System settings show how Zendesk is configured, but not how support teams actually work.
Map the full ticket lifecycle as it happens in practice:
- How tickets enter Zendesk from each channel;
- How ownership is assigned and reassigned;
- How priority changes over time;
- When and how escalations happen;
- How tickets move between first-line support and specialists;
- How tickets are closed or reopened.
Pay special attention to manual work, such as:
- Agents updating fields manually to move tickets forward;
- Tags added only to make reports work;
- Duplicate macros with small differences;
- Tickets passed between teams multiple times.
These patterns usually indicate process gaps that Salesforce can remove rather than reproduce. Light documentation works best here. Screenshots, short notes, or simple flow diagrams are usually enough to capture how work actually happens.
Step 3: Decide what to keep, change, or remove during the Zendesk Salesforce data migration
With systems and processes clear, define what should move into Salesforce and what should not. These decisions should be final before any data migration begins.
Zendesk to Salesforce data migration plan
Once service processes are clearly mapped, the next critical step is building a detailed Zendesk to Salesforce data migration plan. This phase defines how data will move, how it will be transformed, and how accuracy will be verified.
Act 1: Define the Zendesk migration scope
Start by defining exactly which Zendesk data sets will be migrated.
Typical data included in scope:
- Tickets
- Public replies and internal notes
- Attachments
- Approved ticket fields
- Users and requesters
- Groups and ownership data
Decide how much history to migrate from Zendesk to Salesforce. Common approaches include migrating only open tickets, open tickets plus recent history, or full ticket history with limited attachments.
Scope decisions should be final before extraction begins to avoid rework during loading.
Act 2: Define field mapping rules
Zendesk ticket fields approved during pre-migration analysis must be mapped to Salesforce case fields.
For each field, define:
- Zendesk field name and type;
- Salesforce target field;
- Data type compatibility;
- Value transformations if needed;
Mapping should also cover system fields such as creation date, last update, and original ticket ID. Storing the Zendesk ticket ID in Salesforce helps with validation and traceability.
Note: fields marked for removal should be excluded entirely from migration logic.
Act 3: Define object and relationship mapping
Zendesk data must be mapped into Salesforce’s CRM structure. Here is how to map it correctly:
Act 4: Define load order for Zendesk data migration
Zendesk data must be loaded in a specific sequence to preserve relationships.
A typical load order includes:
- Salesforce users
- Accounts and contacts
- Queues and ownership rules
- Cases
- Case comments
- Attachments
Load order should be documented and followed consistently across test and production runs.
Prepare Salesforce Service Cloud before loading Zendesk data
Salesforce should be fully ready before any Zendesk data migration begins. Loading tickets into a partially configured system usually leads to broken automation, incorrect ownership, and extra cleanup work after go-live. A stable Service Cloud setup allows Zendesk ticket migration and Zendesk ticket field migration to run without rework.
1. Define the case structure and lifecycle
Start by configuring how cases will exist in Salesforce. Case statuses should reflect real support stages, not default values. Priority rules must match how urgency is handled in practice, and required fields should align with each step of the case lifecycle. Page layouts should support agents by showing only the fields they need at each stage, rather than copying the Zendesk layout directly.
Clear case structure makes Zendesk to Salesforce data migration easier because tickets land in a predictable and controlled format.
2. Prepare accounts and contacts
Zendesk focuses on tickets, while Salesforce is built around customer records. Decisions about accounts and contacts must be made before data is loaded. Requesters usually become contacts or person accounts, while Zendesk organizations map to accounts. Duplicate handling rules should be agreed on early so migrated cases do not link to inconsistent customer data.
Correct customer structure prevents reporting and visibility issues after Zendesk migration.
3. Set up ownership and routing logic
Zendesk groups normally translate into Salesforce queues. Queues should be created before migration so cases can be assigned correctly during load. Assignment rules and routing logic should reflect the future process, not the old Zendesk setup. Salesforce Omni-Channel is often used to control workload distribution and priority handling, replacing much of the Zendesk assignment logic.
4. Rebuild automation using Salesforce tools
Zendesk automation relies on triggers, macros, and tags. Salesforce uses Flow, rules, and entitlements instead. Each automation should be reviewed before rebuilding, since many Zendesk rules exist only to work around platform limits.
Typical automation includes assignment changes, status updates, priority recalculation, notifications, and escalation logic. Simplifying automation at this stage reduces maintenance after migrate Zendesk to Salesforce work is complete.
5. Configure SLAs and escalation logic
Zendesk SLAs must be rebuilt using Salesforce Entitlements and milestones. SLA definitions should match real support commitments, including business hours and holidays. Escalation actions should be tested using sample cases so that timing and alerts behave correctly once real tickets arrive.
6. Prepare channels and case entry points
Cases should enter Salesforce through the same channels agents will use after go-live. Email-to-Case, Web-to-Case, and any messaging or phone integrations must be configured and tested in advance. Email threading, auto replies, and templates should behave consistently so migrated tickets and new cases follow the same rules.
7. Set up reporting before migration
Basic reports and dashboards should exist before any data is loaded. Case volume, open versus closed cases, SLA compliance, and agent workload reports help validate migration accuracy. Reporting also gives team leads confidence that the new system reflects real activity.
Reports act as an early warning system during Zendesk data migration.
8. Confirm readiness before loading data
Before running Zendesk to Salesforce data migration, confirm that required fields exist, queues and users are active, automation is deployed, and sample cases behave correctly. A short readiness review at this stage prevents failed loads and last-minute fixes.
Extract and clean Zendesk data before migration
After Salesforce is ready, attention shifts to Zendesk data itself. Here are the steps to prepare your data:
Step 1: Choose the export method
Select the extraction approach based on data volume and structure.
- CSV exports work for smaller Zendesk setups with limited relationships
- Zendesk API extraction fits larger environments where ticket history, timestamps, and comment order must be preserved
The chosen method should align with the migration scope and mapping already defined.
Step 2: Extract tickets with required relationships
Tickets should be exported together with the records they depend on.
Include:
- Ticket core fields such as status, priority, owner, creation and update dates
- Public replies and internal notes in correct order
- Organization and requester references
- Attachments linked to the correct ticket and comment
- Original Zendesk ticket ID stored as a reference field
Step 3: Clean data before loading
Only approved data should move forward. Cleanup happens before any Salesforce load.
Typical cleanup actions include:
- Removing unused ticket fields;
- Normalizing picklist values;
- Fixing empty required fields;
- Resolving broken user references;
- Reviewing tags kept for reporting.
Cleanup should reflect earlier decisions, not introduce new ones.
Step 4: Review users and ownership mapping
Zendesk user data often includes inactive or temporary accounts.
Prepare:
- Active agents mapped to Salesforce users
- Former agents mapped to inactive Salesforce users for history
- Requesters reviewed for duplicates and missing details
Clear ownership mapping ensures correct case visibility after migration.
Step 5: Prepare comments for Salesforce display
Comments should remain readable and useful for agents.
Confirm:
- Public replies and internal notes are clearly labeled
- System generated text is trimmed or marked
- Original timestamps are preserved
The goal is clear case history without clutter.
Step 6: Decide attachment handling rules
Attachments should follow predefined limits.
Define:
- Maximum file size allowed
- Whether all or only recent attachments are migrated
- Whether older files remain external with links stored in Salesforce.
Test a small attachment sample before the full load.
Zendesk data migration into Salesforce step by step
Once Zendesk data is extracted and cleaned, loading can begin. A controlled and repeatable load process protects data quality and reduces pressure during cutover. Rushing this phase often causes broken relationships, missing history, or incorrect ownership.
1. Start with sandbox loads
All migration loads should begin in a Salesforce sandbox. Each load should have a clear purpose, such as validating case ownership, checking comment order, or confirming attachment handling. Findings from one run should be applied before the next run begins.
2. Follow the defined load sequence
Zendesk data relies on relationships, so load order must follow the structure defined earlier.
A typical sequence is:
- Salesforce users, including inactive users for history;
- Accounts and contacts;
- Queues and ownership rules;
- Cases;
- Case comments;
- Attachments.
3. Load cases and history carefully
Zendesk tickets usually map directly to Salesforce cases, but field behavior differs. During case loads, confirm that status, priority, ownership, and timestamps appear as expected.
Validation rules or automation that block historical values may need to be temporarily relaxed during migration. The original Zendesk ticket ID should be stored in a reference field for traceability.
Comments should be loaded after cases and retain original timestamps. Public replies and internal notes should remain clearly distinguishable so agents can follow conversation history.
4. Handle attachments as a final step
Attachments should be loaded only after cases and comments are in place. File size limits and storage rules must be respected to avoid failed uploads.
When older files remain outside Salesforce, links should be verified so agents can still access them when needed.
5. Resolve errors at the source
Errors during loading are expected. Common issues include missing required fields, invalid picklist values, or ownership conflicts.
Instead of fixing records one by one, adjust mappings or source data and rerun the load. Addressing root causes keeps later runs faster and more predictable.
6. Validate after each load cycle
Each load cycle should end with basic validation:
- Record count comparison;
- Spot checks of sample cases;
- Review of ownership, status, and timestamps.
Once validation is complete, the same process can be repeated for the next cycle or the final production load.
Rebuild Zendesk automation in Salesforce
After data is in place, automation should be rebuilt using Salesforce-native tools. Zendesk and Salesforce use different automation models, so the goal is to implement the same outcomes in a cleaner and more maintainable way.
Review current automation outcomes
Start by reviewing what automation actually achieves in Zendesk, rather than how it is technically implemented.
Focus on outcomes such as:
- How cases are assigned or reassigned;
- When status or priority changes;
- How response and resolution times are tracked;
- When agents or managers receive notifications;
- How escalations are triggered.
Many Zendesk rules exist only because of past limitations or legacy processes. Those should not be carried forward automatically.
Group existing rules into clear categories like assignment, status updates, priority handling, notifications, and escalations to define what needs to be rebuilt in Salesforce.
Implement logic with Salesforce Flow and rules
Most Zendesk triggers translate into Salesforce Flow combined with assignment rules. Use Flow to handle conditional logic, field updates, notifications, and background actions. Assignment rules can manage initial ownership, while Flow can handle reassignment based on changes during the case lifecycle.
Keep flows focused and readable. Smaller, purpose-driven flows are easier to test and maintain than one large, complex flow.
Replace macros with Salesforce agent tools
Zendesk macros should be replaced with Salesforce tools designed for agent productivity.
Use:
- Quick Text for short, reusable replies;
- Email templates for structured responses;
- Quick actions to update fields and send replies in a single step.
These tools preserve agent speed without recreating Zendesk-specific logic.
Rebuild SLAs with entitlements and milestones
Zendesk SLAs should be implemented using Salesforce Entitlements and milestones.
Define which entitlement applies based on customer type, support plan, or case priority. Configure milestones for response and resolution targets, along with business hours and holidays.
Milestone actions can trigger alerts or escalations when targets are missed.
Configure notifications and escalations
Notifications and escalations should be driven by Flow and milestone actions.
Common actions include:
- Email or in-app alerts
- Task creation
- Ownership or priority updates
Notification volume should be controlled carefully so alerts remain meaningful and actionable.
Validate automation behavior
Automation should be tested using realistic scenarios, including reassignments, reopened cases, SLA breaches, and after-hours activity.
Agents and team leads should confirm that automation supports daily work without adding unnecessary steps.
Document key automation elements
Each Flow, rule, and entitlement should have a short description explaining its purpose and impact. Clear documentation supports future changes and reduces reliance on individual team members.
This approach keeps Salesforce automation aligned with real service processes while remaining easier to maintain than the original Zendesk setup.
Rebuild the agent workspace in Salesforce
After automation is in place, focus shifts to the agent experience. Even a well-designed data model and strong automation will fail if agents struggle to work efficiently. Rebuilding the agent workspace is about making daily support work clear, fast, and predictable.
Design the Service Console around core agent actions
The console layout should support the main actions agents perform during a case lifecycle.
Focus on enabling agents to:
- Read and understand the issue quickly;
- View key customer context;
- Reply to the customer;
- Update status and priority;
- Escalate or reassign when needed.
Page layouts should show only relevant fields for each stage of the case. Less-used fields should remain hidden to reduce noise. Highlights panels should surface critical information such as priority, SLA status, ownership, and customer tier. Related lists should be ordered so comments, emails, and attachments are easy to find.
Replace Zendesk views with Salesforce list views
Zendesk views usually translate into Salesforce list views.
Create list views for common scenarios, such as:
- New or unassigned cases;
- Cases waiting for customer response;
- High-priority or escalated cases;
- SLA risk cases.
Filters should align with routing and automation rules so list views remain accurate. Naming conventions should be simple and consistent to avoid confusion and reduce onboarding time.
Configure agent shortcuts and productivity tools
Zendesk macros and side apps should be replaced with Salesforce-native tools.
Typical replacements include:
- Quick Text for reusable responses;
- Email templates for structured replies;
- Quick actions for updating fields and sending responses in one step;
- Utility bar tools for notes, history, or external links.
Shortcuts should reduce clicks and keep agents focused on resolution rather than navigation.
Present customer context clearly
Salesforce allows richer customer context than Zendesk, but only relevant data should appear in the console.
Accounts and contacts should show recent cases, key notes, active entitlements, or contracts in a readable layout. Avoid exposing excessive data that slows agents down or distracts from the case.
Support different agent roles
Different roles require different views.
- First-line agents focus on speed and clarity;
- Specialists need deeper technical details;
- Supervisors need visibility into queues and performance.
Role-based page layouts and console apps help keep each workspace focused and uncluttered.
Validate the workspace with agents
Workspace validation should involve agents who handle cases daily.
Test:
- Replying to cases;
- Updating fields and statuses;
- Escalation and reassignment;
- Switching between cases.
Feedback from these tests should drive final layout and shortcut adjustments.
Provide lightweight agent guidance
Short, task-focused guides help agents adapt quickly.
Guidance should explain how to perform common actions in Salesforce and where Zendesk features have moved. Clear instructions reduce questions during the first weeks after go-live.
Migrate and configure service channels in Salesforce
After the agent workspace is ready, service channels must be moved and tested carefully. Channels are often the most visible part of a Zendesk to Salesforce migration because customers interact with them directly. Any issues here affect response times and trust immediately.
Email channel migration
Email is usually the primary channel in Zendesk, so Email-to-Case setup needs special attention.
Start by reviewing all support email addresses used in Zendesk. Each address should be mapped to a Salesforce Email-to-Case configuration with clear routing rules. Auto-response messages should confirm receipt without creating confusion or duplicate replies.
Email threading behavior must be tested so replies attach to the correct case. Signatures, templates, and formatting should be reviewed to match current communication style. Testing should include long email chains and forwarded messages, which often expose issues early.
Web forms and case creation
Zendesk forms often collect structured data that drives routing and reporting. When moving to Salesforce, Web-to-Case forms or custom forms should capture the same information without unnecessary fields.
Field validation should guide users to provide useful details while keeping forms short. Confirmation messages should be clear so customers know their request was received. Testing should include incomplete submissions and edge cases to confirm behavior stays predictable.
Phone and voice channels
Teams using Zendesk voice or third-party phone tools need to plan voice migration carefully. Salesforce supports voice through CTI integrations and Omni-Channel routing.
Call routing rules should align with case assignment logic so agents receive calls they can handle. Screen pops should display the correct customer record or case when a call arrives. Call logging should capture duration, outcome, and notes consistently.
Voice testing should include peak hours and handoffs between agents to ensure load distribution works as expected.
Chat and messaging channels
Zendesk chat or messaging tools often connect directly to ticket creation. Salesforce supports chat and messaging through Service Cloud features and partner tools.
Routing rules should match agent availability and skill sets. Chat transcripts should be attached to cases in a readable format. Notifications should alert agents promptly without interrupting active work.
Testing should cover concurrent chats and transitions from chat to case follow-up.
Self-service and knowledge
Zendesk Help Center content often moves to Salesforce Experience Cloud. Knowledge articles should be reviewed before migration to remove outdated content and align with new processes.
Article categories, search behavior, and visibility rules should be tested from a customer perspective. Links from old Zendesk pages should redirect correctly to avoid broken access. Self-service setup should support deflection goals without blocking access to support.
Social and external channels
If Zendesk handles social or external request sources, Salesforce alternatives should be configured before cutover. Routing and visibility rules should match the support policy so no requests are missed.
Each channel should be tested independently and then together to confirm that routing, ownership, and reporting remain accurate.
Validate channels before go-live
Before switching fully to Salesforce, all channels should be tested using real scenarios. Tests should confirm case creation, ownership, notifications, and response handling.
Test the Zendesk to Salesforce migration setup and prepare for go live
Once data, automation, workspace, and channels are in place, testing confirms that the system works end to end under real conditions. The goal is to verify readiness for launch, not to redesign processes again.
Run end-to-end testing with real scenarios
Testing should follow complete service flows instead of isolated features.
Cover scenarios such as:
- Case creation across all channels
- Routing to the correct queues and agents
- Status and priority changes during the lifecycle
- Escalations and notifications
- SLA start, pause, and completion
Data validation should be part of the same flow. Compare record counts between Zendesk and Salesforce, then open a sample of migrated cases and review ownership, timestamps, comments, and attachments. Internal notes and public replies should be clearly labeled and readable.
Combining functional and data checks avoids repeating the same tests in separate phases.
Involve agents in user acceptance testing
Agents should validate the system using their daily tasks.
Testing should include:
- Replying to customers;
- Updating case fields and statuses;
- Handling escalations and reassignments;
- Switching between cases, list views, and tools;
Agent feedback usually highlights practical issues such as layout clarity, missing shortcuts, or automation timing. These findings should drive final adjustments before launch.
Prepare lightweight training and support materials
Training should focus on actions, not platform theory.
Effective materials include:
- Short task-based guides;
- Simple checklists for common actions;
- Brief videos for key workflows.
Guidance should explain how familiar Zendesk actions translate into Salesforce, including where to find views, macro replacements, and customer history.
Plan and execute cutover
Cutover planning defines how the transition happens.
Key steps include:
- Defining a Zendesk freeze period
- Scheduling the final data load during low activity
- Switching channels to Salesforce
- Assigning clear ownership for each step
Communicate and support during launch
Before launch, share timing, expected changes, and support contacts. Let teams know what will feel different on day one and what stays the same.
After go-live, provide focused hypercare support. Monitor queues, routing, and SLAs closely, respond quickly to questions, and prioritize fixes that affect customer response or agent efficiency.
Post-launch monitoring and optimization
Going live marks the start of stabilization, not the end of the Zendesk Salesforce migration. The focus after launch is to confirm that the system behaves as expected under real volume and to make targeted adjustments.
Monitor flow and SLAs
Review queue sizes, assignment speed, and workload distribution during the first weeks. Backlogs or uneven load usually point to routing or capacity settings that need tuning. SLA behavior should also be monitored closely, as missed milestones often indicate configuration gaps.
Check data and reports
Early reports should align with historical trends from Zendesk. Large differences in case volume, resolution time, or backlog usually signal mapping or automation issues. Quick spot checks of new and migrated cases help confirm consistency.
Refine based on agent feedback
Agent feedback highlights friction that dashboards miss. Small adjustments to layouts, list views, or quick actions often improve efficiency more than major changes. Focus on reducing manual steps and keeping case handling predictable.
Tune automation and routing
Flows, notifications, escalations, and Omni-Channel settings may need fine-tuning once real usage patterns appear. Adjust rules based on actual case volume and agent behavior.
Improve knowledge and self-service
Review which articles customers use and where they still open cases. Usage data usually reveals content gaps that can reduce incoming volume.
Close the project
Once the system is stable, confirm stakeholder sign-off, archive Zendesk data if needed, retire unused integrations, and document the final Salesforce setup.
.webp)
together