Migrate from Ticksy to Freshdesk

Ticksy Private Tickets map to Freshdesk Conversation records with the display_id preserved, status mapped (open/pending/resolved/closed to Freshdesk status equivalents), priority mapped, and assignee resolved by email against Freshdesk Agents. The private-agent-customer thread is preserved as a chronological conversation notes chain. Ticksy does not have a status hierarchy, so we map each Ticksy status value individually during scoping.

Ticksy Public Tickets carry a visibility flag indicating community-visible threads. Freshdesk has no native public-community concept, so we create a custom ticket field (ticksy_visibility__c) set to 'public' and tag the ticket with a 'community-thread' label so teams can distinguish community support from standard private tickets. Failing to carry this flag silently converts public threads to private in the new system.

Ticksy KB articles (title, body, category, publish state) map to Freshdesk Solutions with the article title as name, HTML body mapped to the description field, section resolved by matching Ticksy category to a Freshdesk Solution section (created during schema setup), and publish state preserved. Articles with draft status in Ticksy land as draft in Freshdesk Solutions and are flagged for the customer's admin to review before publishing.

Ticksy stores dropdown option lists separately from ticket records. We extract both the field definition (name, type, required flag) and the options list, create the corresponding Freshdesk custom field via the API, then map the values on each ticket during import. Text and multiline fields map to Freshdesk text or paragraph custom fields without an options list. Dropdown options that exceed Freshdesk's 150-character limit are truncated with a warning to the customer.

Custom field values are extracted from Ticksy ticket records and written to the corresponding Freshdesk custom field on the Conversation. We resolve the custom field ID in Freshdesk first before writing values so that no orphan field references are created. Tickets with empty custom field values are written without the field present (Freshdesk does not require custom fields to be set on every record).

Ticksy support agent accounts (name, email, role) map to Freshdesk Agent records. Role (admin vs agent) is preserved as a custom attribute (ticksy_original_role__c) where the destination does not have a direct equivalent. Agents are provisioned in Freshdesk before ticket migration so that assignee lookups resolve at import time rather than landing as null.

Ticksy customers who submitted tickets are extracted as Contact records in Freshdesk. Email address is the dedupe key. We deduplicate by email so that a customer who submitted multiple tickets appears as one Freshdesk Contact. Name, company (if present), and the ticksy_visibility__c flag from their most recent ticket are written to the Contact record.

Ticksy KB categories and ticket labels are simple string identifiers. We normalise these to Freshdesk Tags by lowercasing, stripping special characters, and truncating to Freshdesk's 50-character tag limit. Tags that exceed the limit are truncated with a flag. Tags used across both KB and tickets are shared in Freshdesk's tag namespace.

File attachments stored with Ticksy ticket records are extracted as standalone binary assets. We re-attach them to the destination Freshdesk Conversation record via the Freshdesk Attachments API endpoint. Attachments larger than 20 MB are flagged for the customer to evaluate whether to migrate via cloud storage link rather than direct upload. Unusual file types (executable, script) are flagged for security review before attachment.

Each Ticksy ticket reply thread (agent and customer messages in chronological order) is mapped to Freshdesk Conversation notes on the corresponding ticket. Author email resolves to the Freshdesk Agent or Contact by email match. Timestamps are preserved as the note creation date. HTML formatting from Ticksy is normalised to plain text or preserved depending on the note content type the customer specifies during scoping.