Migrate from CDESK to Intercom

CDESK Requests map to Intercom Conversations. The Request title becomes the Conversation title, description becomes the initial message body, and status (Open, In Progress, Closed) maps to Intercom's open, closed, and snoozed states. We resolve the assignee by matching the CDESK assignee email to an Intercom Admin or Team. Created_at and Updated_at timestamps preserve the original request dates on the conversation timeline.

CDESK stores SLA and SLO deadline timestamps as fields on individual Requests. These carry forward as custom attributes on the Intercom Conversation (e.g., sla_response_deadline, slo_resolution_deadline). The actual SLA rule definitions (escalation paths, business-hour calendars) are not exportable from CDESK and do not become native Intercom SLA rules; we document them for your admin to rebuild in Intercom's SLA settings post-migration.

CDESK administrators extend the Request schema with arbitrary Custom Properties. We extract these as key-value pairs and create matching custom attributes on the Intercom Conversation at migration time. We match field types where possible (text, number, date, dropdown) and flag any unsupported data types for manual review. The customer configures these attributes in Intercom's workspace settings before migration begins.

The customer or user associated with a CDESK Request maps to an Intercom Contact. We extract the requester's name, email, and any contact-level custom fields from CDESK. If a Contact with the same email already exists in Intercom, we attach the Conversation to the existing Contact; otherwise we create a new Contact record first so the Conversation is not orphaned.

CDESK Requests may be linked to a Company record. We migrate Company records to Intercom Companies and link them to the corresponding Contact via the Contact's company_id attribute. Intercom's Company object stores company-level data (domain, size, industry) that may come from CDESK's Company or Custom Properties.

CDESK Deals track sales opportunities with linked tasks, cost estimates, and documents. Intercom does not have a native Deal or Opportunity object. We map Deals to Intercom Conversations with a deal_reference custom attribute, and if the customer also uses a CRM integration (Salesforce, HubSpot), we can link the Conversation to the external Deal record via a custom attribute. Deal documents migrate as file attachments on the Conversation.

File attachments on CDESK Requests and Deals migrate as file attachments on the corresponding Intercom Conversation. We preserve filenames and upload order. Large attachments may require chunked transfer depending on Intercom's file size limits per conversation. Attachments without a parent Request conversation are held pending Contact or Company resolution.

Request Templates define default structures for creating new Requests. These are configuration artifacts, not instance data. We do not export them as records. During discovery we inventory all Request Templates, document their field defaults and assignment rules, and provide written guidance so your admin can recreate them as Intercom Inbox rules or SLA policies. Budget time for this manual step post-migration.

Regular Requests are automated ticket generation rules scheduled within CDESK. These are scheduling rules, not data records, and cannot be migrated as data. We flag their existence and advise custom webhook or Intercom Workflow alternatives in the target platform. The customer's technical team implements the automation rebuild as a post-migration configuration task.

CDESK's Priority View is a filtering and sorting configuration for the request list. It is not a data object. We preserve the priority value and deadline on each Request so that Intercom can apply equivalent filtering. Post-migration, your admin can configure Inbox filters and SLA policies in Intercom's workspace settings to replicate the Priority View workflow.