Migrate from CDESK to Zendesk

CDESK Requests map directly to Zendesk Tickets. We extract standard fields (title, description, status, priority, assignee, requester, created_at, updated_at) and carry SLA deadline timestamps as custom fields on each ticket. Request ID is preserved in a custom field cdesk_original_id__c for cross-referencing. If CDESK provides no API, extraction relies on direct database reads or CSV exports from the application's export functionality; we confirm the extraction path during discovery.

CDESK administrator-defined Custom Properties on Requests map to Zendesk ticket custom fields. We extract the property key and value for each Request, then create Zendesk custom fields of matching type (text, numeric, date, dropdown, checkbox) during the target schema setup phase. Dropdown options are preserved as Zendesk drop-down field options. Multi-value Custom Properties map to Zendesk tag fields or multi-select custom fields depending on data type.

CDESK SLA and SLO deadlines are stored as date-time fields on each Request. We carry these forward as Zendesk custom fields (sladate__c, slatype__c) on the ticket so the values are available for reporting. The SLA rule definitions themselves (escalation paths, business-hour calendars) do not migrate as structured Zendesk SLA Policy configuration; we document every unique SLA name and deadline tuple and the customer recreates SLA Policies in Zendesk Admin based on that inventory.

Request Templates define default field values and structures for new ticket creation in CDESK. These are configuration artifacts, not data records. We do not export them as tickets. Instead we inventory every Request Template during discovery (name, default fields, assignee rules, default priority) and provide a written reference document that maps each template to its recommended Zendesk equivalent (Form, Macro, or default field value). The customer's Zendesk admin rebuilds these post-migration.

Regular Requests are scheduled automated ticket generation rules in CDESK. They are scheduling rules, not instance data. We flag their existence during discovery and document the schedule, trigger conditions, and default fields for each. These map to Zendesk Triggers or scheduled automations, which are not migrated as code. We deliver a Regular Request inventory as a configuration handoff document.

CDESK's Priority View is a filtering and sorting configuration for the request list, not a data object. We preserve priority and SLA deadline values on each Request so the priority ordering can be recreated as Zendesk Views. We map CDESK priority levels (e.g., Low, Medium, High, Critical) to Zendesk ticket priority field values. Views in Zendesk filter by status, assignee, priority, and custom field values.

File attachments on CDESK Requests migrate as Zendesk ticket attachments. We extract binary blobs alongside their parent Request ID, preserving filenames and attachment ordering. Large attachments may require chunked transfer depending on Zendesk's file size limits (50 MB per attachment). We resolve the Zendesk ticket ID at import time to link each attachment to the correct parent ticket.

CDESK Deals track sales opportunities alongside service Requests. Zendesk Service Suite does not have a native Deal or Opportunity object; these map either to a Zendesk Organization with deal-related fields stored as custom fields, or to a custom Zendesk App or third-party integration. During scoping we confirm whether the customer uses CDESK Deals for customer-facing support context (mapping to Organizations) or sales pipeline context (recommending a CRM integration or custom object). Linked tasks migrate as Tasks on the parent record.

Every Zendesk ticket requires a requester (End User) and an assignee (Agent). We extract distinct requester contacts from CDESK Requests and map them to Zendesk End Users. CDESK agent accounts map to Zendesk Agent or Admin roles. Any CDESK contact without an email address cannot be imported as a Zendesk End User; we flag these as partial records and assign them to a default contact for the customer's admin to resolve post-migration.

CDESK Request status values (e.g., Open, In Progress, Resolved, Closed) map to Zendesk ticket status field values. We match by label where possible and use a status map where labels differ. Zendesk's default statuses are New, Open, Pending, Hold, Solved, Closed; custom statuses are available on higher tiers. We configure the mapping before migration so that status values land correctly without requiring post-migration data correction.

CDESK's multi-department routing capability maps to Zendesk Groups. We extract every distinct department assignment from CDESK Request records, create Zendesk Groups matching those department names, and assign tickets to the correct Group during migration. Agents are assigned to Groups via their Zendesk profile. This preserves the departmental visibility and routing that CDESK customers rely on for internal IT versus non-IT service request separation.