Migrate from CDESK to Freshdesk

CDESK Requests map directly to Freshdesk Tickets. Standard fields (title, description, status, priority, assignee, created_at, updated_at) migrate to Freshdesk ticket attributes. Since CDESK has no documented API, extraction relies on application-level export or direct database access confirmed during discovery. We use Freshdesk's ticket creation API endpoint with batched POST requests and handle rate-limit responses with exponential backoff. The Freshdesk ticket ID is captured for attachment and SLA association after ticket creation.

CDESK Custom Properties (key-value pairs added to Requests by administrators) map to Freshdesk custom fields. During pre-migration, we create the equivalent custom fields in Freshdesk Admin > Support Operations > Customer Fields with appropriate data types (text, number, date, dropdown, checkbox) matched to the source property format. The mapping between CDESK property names and Freshdesk field API names is documented in the field inventory delivered before migration begins.

CDESK SLA and SLO deadline values attached to Requests migrate as two Freshdesk custom fields: one text field carrying the SLA policy name and one date field carrying the resolution deadline timestamp. The SLA rule definitions themselves (escalation paths, business-hour calendars, warning thresholds) are not migrated as Freshdesk SLA Policy objects because they may not be exportable from CDESK as structured data. The customer receives documentation of the SLA policy names and deadlines carried forward so they can recreate Freshdesk SLA policies with matching definitions post-migration.

CDESK Deals migrate to Freshdesk Deals if the destination account is on Garden tier ($49/agent/month) or higher, which includes the Deals module. On lower tiers, Deals migrate as a Freshdesk Custom Object with fields for Deal name, value, stage, cost estimate, linked documents, and task completion status. We map CDESK deal stages to Freshdesk Deal stages or to custom picklist values in the Custom Object schema. The mapping type is confirmed during scoping based on the customer's Freshdesk edition.

File attachments on CDESK Requests and Deals migrate as binary blobs alongside their parent record. We extract attachment metadata (filename, MIME type, file size, upload timestamp) from CDESK and POST to Freshdesk's attachment endpoint linked to the migrated ticket ID. Large attachments exceeding Freshdesk's size limits are flagged during pre-migration audit, and the customer decides whether to compress, exclude, or store externally.

CDESK Request Templates define default structures for new tickets but are configuration artifacts rather than instance data. We do not export them as records. During discovery, we inventory every Request Template (name, default fields, SLA assignment, category assignment) and deliver a written mapping document that the customer's admin uses to recreate equivalent Freshdesk automation rules or template defaults manually. This is a manual step the customer must budget for.

CDESK Regular Requests are automated ticket generation rules that trigger new Requests on a schedule. These are scheduling rules, not data records, and cannot be directly migrated. We flag their existence and advise the customer on Freshdesk equivalents: Freshdesk's Recurring Tickets feature (Estate tier and above) or the Workflow Automator with scheduled triggers. We deliver a rule-by-rule inventory document so the customer's admin can rebuild the logic in Freshdesk after migration.

CDESK's Priority View is a filtering and sorting configuration, not a data object. It does not migrate directly. We preserve the priority and SLA deadline values on each Request as custom fields in Freshdesk so that the customer can recreate their priority-based filtering views using Freshdesk's saved views and filters feature after migration. The original CDESK priority levels map to Freshdesk priority values (Urgent, High, Normal, Low) during import.