Zendesk Sell Retirement and Salesforce Migration Guide

Zendesk Sell is scheduled to retire on August 31, 2027. Existing customers can continue using the sales CRM until retirement, but administrators should begin documenting their data, integrations, security model, and reporting requirements before selecting and configuring a replacement.

This guide explains the retirement timeline, the limits of the available exports, and a practical approach for migrating Zendesk Sell data to Salesforce Sales Cloud. The migration should be treated as a data-model and business-process project rather than a direct CSV upload.

What is happening to Zendesk Sell?

Zendesk announced the retirement of Zendesk Sell on September 9, 2025. The published removal date is August 31, 2027. Zendesk states that it will no longer provide a sales CRM after that date.

Customers retain access according to their subscriptions until the subscription ends or the retirement date arrives. Because deletion can begin when a subscription terminates, an organization should not assume that its data will remain available until August 31, 2027 if it cancels earlier.

Administrators should verify current dates and account-specific terms in the official Zendesk Sell retirement announcement and Zendesk’s product-removal schedule.

Why should Zendesk Sell customers start planning now?

A CRM migration affects more than leads and deals. Sales teams often depend on automations, field definitions, ownership rules, email integrations, dashboards, web forms, and downstream systems that are not obvious from a record export.

Starting early gives the project team time to answer four questions:

• Which Zendesk Sell records and activities must be retained for operational, contractual, or regulatory reasons?
• Which processes should be rebuilt in Salesforce, and which should be removed rather than copied?
• How will legacy identifiers be preserved so records can be reconciled after migration?
• What evidence will demonstrate that the target system contains complete and accurate data?

In enterprise orgs, the discovery phase often exposes duplicate account structures, inconsistent picklist values, inactive owners, and integrations that rely on undocumented field names. Resolving those issues before loading Salesforce reduces rework during user acceptance testing.

What Zendesk Sell data can be exported?

Zendesk’s retirement guidance identifies exports for leads, contacts, deals, notes, tasks, smart lists, full account data, and the Total Sales report. The same guidance states that standard exports do not include some information, including activity history, appointments, emails, call logs, and documents.

Some system fields may be available only through a smart-list export. Exported files are provided through a secure email link, and Zendesk states that generated exports remain available from the Export panel for 30 days.

Do not wait until the final cutover to test exports. Generate a sample from each available export path, inspect its columns, confirm character encoding, and compare record counts with the Zendesk Sell user interface.

How do you map Zendesk Sell to Salesforce?

There is no universal one-to-one mapping. The correct Salesforce design depends on whether the organization uses business accounts, person accounts, multiple sales processes, products, territories, or custom objects.

Suggested starting object mapping

Preserve source identifiers

Create an external ID field for each migrated object, such as Zendesk_Sell_ID__c. Source identifiers make it possible to upsert records, relate child records to parents, detect duplicates, and reconcile migration results.

Zendesk_Sell_ID__c
Data Type: Text
Length: Based on observed source values
External ID: Enabled
Unique: Enable only after duplicate source IDs are resolved

Do not use record names as the only matching key. Company names, contact names, and opportunity names are rarely stable enough to support repeatable migration loads.

How do you prepare Zendesk Sell CSV files for Salesforce?

Keep the original exports unchanged in a restricted archive. Perform cleansing and transformation on working copies so the migration team can trace every value back to its source.

1. Record the export date and record count. Maintain a control sheet for every source file.
2. Inspect delimiters and encoding. Save transformed files as UTF-8 CSV unless the selected loading tool requires another format.
3. Normalize null values. Distinguish an empty source value from an intentional request to clear a Salesforce field.
4. Standardize dates. Convert dates and date-times into formats accepted by the selected Salesforce import tool.
5. Map picklists. Create a controlled translation table instead of editing values manually.
6. Resolve owners. Map former and current Zendesk users to active Salesforce user IDs or a designated migration owner.
7. Separate rejected rows. Never silently discard records that fail validation.

Example transformation specification

Source column: deal_stage
Source values: Qualified, Proposal Sent, Contract Review, Won, Lost
Salesforce field: Opportunity.StageName
Target values:
  Qualified       -> Qualification
  Proposal Sent   -> Proposal/Price Quote
  Contract Review -> Negotiation/Review
  Won             -> Closed Won
  Lost            -> Closed Lost

Rule: Reject blank stages unless a documented default has been approved.

The Salesforce stage names above are examples. Use the stage values configured for the target sales process rather than assuming that every Salesforce org uses the same pipeline.

Which Salesforce import tool should you use?

Salesforce provides several data-loading options. Select the tool based on volume, repeatability, supported objects, error-handling needs, and the skill level of the migration team.

The official Salesforce Data Import Wizard documentation describes supported objects and limits. Salesforce also provides a Trailhead unit on data import practices.

For programmatic loading, Bulk API 2.0 Ingest supports insert, update, upsert, and delete operations using CSV data. Salesforce recommends considering Bulk API 2.0 for operations containing more than 2,000 records, although the appropriate tool still depends on the migration design and operational requirements.

What is the correct Zendesk Sell migration sequence?

Load parent records before child records and maintain cross-reference files between source IDs and generated Salesforce IDs.

1. Configure the target org. Create objects, fields, record types, sales processes, validation rules, permission sets, and duplicate-management rules.
2. Load users or build an ownership map. Do not assign migrated records to inactive or nonexistent users.
3. Load accounts. Preserve the source organization ID in an external ID field.
4. Load contacts. Resolve each source organization reference to the corresponding Salesforce AccountId.
5. Load leads. Keep unqualified prospects separate from converted customer records.
6. Load opportunities. Resolve account relationships, stage mappings, owners, currency, and close dates.
7. Load tasks and notes. Build WhoId and WhatId relationships from the cross-reference tables.
8. Load files through a supported files process. Do not treat binary documents as ordinary CSV fields.
9. Run reconciliation. Compare source totals, target totals, rejected rows, amounts, owners, and relationship counts.

Example Bulk API 2.0 job request

The following request body illustrates an Opportunity upsert job. Replace the API version with a version supported by the target org and validated by the integration team.

{
  "object": "Opportunity",
  "operation": "upsert",
  "externalIdFieldName": "Zendesk_Sell_ID__c",
  "contentType": "CSV",
  "lineEnding": "LF"
}

The job is created with a request to the Bulk API 2.0 ingest endpoint, after which the client uploads CSV data, marks the upload complete, monitors processing, and downloads successful and failed result files. API calls must use an integration user with the required object permissions and field-level access.

How should Salesforce security be handled during migration?

A data migration does not bypass the need for a defined Salesforce security model. Review organization-wide defaults, role hierarchy, sharing rules, teams, permission sets, object permissions, and field-level security before users receive access.

• Use a dedicated migration user rather than a personal administrator account.
• Grant only the permissions required for the approved migration operations.
• Store source exports in encrypted, access-controlled storage.
• Remove temporary migration permissions after the final load.
• Test visibility with representative sales users, managers, and administrators.
• Do not expose archived CSV files through public file-sharing links.

Validation rules, flows, duplicate rules, and Apex automation can affect imports. Document which automation will remain active, which will be bypassed through an approved control, and which will run after loading. A blanket deactivation of production controls can create incomplete records or unintended sharing.

How do you validate a Zendesk Sell migration?

Successful API or Data Loader responses prove that Salesforce accepted records; they do not prove that the migration is correct.

Minimum reconciliation checks

• Source, transformed, loaded, and rejected record counts by object.
• Total opportunity amount by currency, stage, owner, and fiscal period.
• Contacts without accounts where the target model requires an account.
• Opportunities without accounts, owners, close dates, or valid stages.
• Tasks and notes whose source parent IDs were not resolved.
• Duplicate external IDs and duplicate business records.
• Unexpected truncation in text, phone, URL, and picklist fields.
• Date and time shifts caused by locale or time-zone conversion.

Example SOQL validation queries

SELECT COUNT()
FROM Opportunity
WHERE Zendesk_Sell_ID__c != null

SELECT StageName, COUNT(Id), SUM(Amount)
FROM Opportunity
WHERE Zendesk_Sell_ID__c != null
GROUP BY StageName
ORDER BY StageName

SELECT OwnerId, COUNT(Id)
FROM Account
WHERE Zendesk_Sell_ID__c != null
GROUP BY OwnerId

Aggregate queries help compare high-level totals, but the project should also test record-level samples. Select examples containing non-ASCII text, long notes, null values, duplicate names, multiple currencies, former owners, and parent-child relationships.

Common Zendesk Sell migration errors

Best practices for replacing Zendesk Sell with Salesforce

• Design before importing. Confirm the Salesforce account, contact, lead, and opportunity model before creating production records.
• Run at least two rehearsal migrations. A first rehearsal tests mappings; a later rehearsal tests the full cutover procedure and expected duration.
• Use external IDs and upsert operations. This supports repeatable test loads and relationship resolution.
• Freeze configuration before cutover. Uncontrolled field or automation changes can invalidate tested mappings.
• Define a delta strategy. Decide how records changed after the initial extraction will be identified and loaded.
• Keep evidence. Retain approved mapping documents, job results, rejected rows, reconciliation reports, and sign-off records.
• Train users on changed processes. Salesforce terminology, stages, activity handling, reports, and permissions may differ from Zendesk Sell.

Related SalesforceTutorial resources include Salesforce Data Loader instructions, Salesforce standard and custom objects, Salesforce security configuration, and Salesforce reports and dashboards.

Zendesk Sell migration checklist

• Confirm the subscription end date and the published retirement timeline.
• Assign business, technical, security, and data owners.
• Inventory objects, custom fields, pipelines, reports, integrations, automations, files, and user roles.
• Test every available Zendesk Sell export.
• Plan separate retention for data excluded from standard exports.
• Design the Salesforce data and security model.
• Create source-ID external fields.
• Build and approve field-mapping and transformation rules.
• Run migration rehearsals in a sandbox or controlled test org.
• Complete user acceptance, security, performance, and reconciliation testing.
• Plan the final extraction, delta load, integration cutover, and rollback decision points.
• Archive source files and migration evidence according to the organization’s retention policy.

Frequently Asked Questions