Migrate from CRM and Deals for Zendesk to Pipedrive

Zendesk Contact records map 1:1 to Pipedrive Person. Email, phone, custom fields, and org association migrate directly. We use the contact's email address as the dedupe key during import. Zendesk custom fields (cf_* key format) are remapped to Pipedrive's hash-style custom field keys (cf_*) that are assigned during the Pipedrive custom field creation step of migration.

Zendesk Organization records (called Companies/Accounts in Sell) map 1:1 to Pipedrive Organization. Org-level custom fields, domain, address, and owner assignment migrate. Organizations are imported before Persons so that the Organization ID is available as a lookup reference at Person import time.

Zendesk Deal records map 1:1 to Pipedrive Deal. However, the mapping requires a critical pre-processing step: Zendesk stores pipeline stage changes as Activity records rather than on the Deal object itself, so the current stage in the Deals API does not reflect historical stage transitions. We run a de-normalization query joining Activities to Deals to construct a synthetic stage-history array before writing to Pipedrive, then create the Pipedrive pipeline and stages with the same names and ordering.

Zendesk Pipeline and Stage objects are defined per-user-or-account and may use non-standard stage names that differ from Pipedrive's default stages. We extract the pipeline definition including stage ordering, stage names, and probability percentages during discovery, then create corresponding Pipedrive pipelines and stages before the Deal migration begins. Stage probability values are rounded to Pipedrive's allowed range.

Zendesk Activities (call logs, emails, meeting notes, tasks) map to Pipedrive Activities. The Zendesk activity schema is flat and does not support threaded conversation views. Activity type, timestamp, body, and owner migrate. We link Activities to the correct Pipedrive Person and Organization by resolving the Zendesk contact_id and org_id references to Pipedrive Person and Organization IDs at migration time.

Zendesk Tickets do not have a direct Pipedrive equivalent because Pipedrive is a sales CRM without a native help desk object. We migrate ticket summary data as Activity records or as notes on the linked Person or Deal, depending on the customer's scoping preference. Full ticket body, status, and priority are preserved in the Activity notes field. The customer configures a Zendesk Support-Pipedrive integration post-migration for ongoing ticket visibility.

Zendesk Agent records (role, group assignments, profile data) map to Pipedrive Users. We resolve agents by email match. Zendesk internal group memberships do not have a Pipedrive equivalent; we do not migrate group memberships. Agents without a matching Pipedrive User go to a reconciliation queue for the customer's admin to provision before record import resumes.

Zendesk Custom Objects v2 migrate to Pipedrive custom fields or, for complex object types with multiple relationships, to Pipedrive's custom object equivalents if the destination plan supports them. We pre-create the Pipedrive custom field schema during discovery. Plan-tier limits apply: Pipedrive's per-field limits are configured during the scoping call based on the customer's target Pipedrive plan. If the customer has more custom object types than the destination plan supports, we flag this before migration begins.

Zendesk Legacy Custom Objects use a deprecated API that cannot write to the current v2 API. We run a five-step mandatory migration before any records are imported: object type definition export, v2 schema creation, relationship type creation, legacy record import, then relationship record linkage. This step alone can add 3-5 days to the timeline. Any legacy object type exceeding the destination plan's custom object quota is flagged during scoping.

Inline images and file attachments on Zendesk tickets and articles are fetched separately from the attachments API endpoint. We download and re-upload to Pipedrive, preserving inline positioning where the target system supports it. Attachments are the final import phase because they reference parent records that must already exist.

Zendesk tags on tickets and contacts are flat string arrays. We preserve tag values as Pipedrive Person or Organization labels. Tag-based automations do not migrate; they must be rebuilt as Pipedrive Automation rules post-migration. We document every tag and its associated automation trigger in the handoff inventory.