Migrate from Ticksy to Zoho Desk

Ticksy Private Tickets map to Zoho Desk Tickets. The Private/Public flag has no native Zoho Desk equivalent so we carry it as a custom field (ticket_visibility__c with values 'private' or 'public') set before import. Private tickets from Ticksy land as standard Zoho Desk tickets without any special status; their privacy is preserved as a searchable custom attribute that agents can filter on. Ticket status (open, closed, pending) maps directly to Zoho Desk Status values; priority maps to Priority; assignee email resolves against the Zoho Desk Agents table.

Ticksy Public Tickets map to Zoho Desk Tickets with the same custom visibility field set to 'public'. Public ticket threads that were community-visible in Ticksy are not automatically public in Zoho Desk; the custom field flags them so the customer's admin can configure a Help Center permission group that grants community access to those articles and threads after migration. This is a post-migration configuration step documented in the handoff.

Ticksy KB articles (title, body, category, publish state) map to Zoho Desk Knowledge Base articles. We extract article content as structured HTML, normalise image URLs to absolute paths, and load via Zoho Desk API. Category hierarchy from Ticksy maps to Zoho Desk Categories; if the category name exceeds Zoho Desk's 100-character limit we truncate and flag. Zoho Desk's Zwitch tool explicitly does not migrate KB attachments; we handle attachment extraction separately by downloading binary assets and re-attaching to the article record via API. Published vs draft state is preserved via the article Status field.

Ticksy text custom fields map to Zoho Desk single-line custom fields on the Ticket layout. Zoho Desk custom fields are department-scoped, meaning we must create the custom field inside each Zoho Desk Department that will receive tickets. If the customer uses one department in Zoho Desk, configuration is straightforward. If they plan to route tickets across multiple departments, we repeat the field creation per department and map to the same column in the import CSV.

Ticksy multiline text custom fields map to Zoho Desk multi-line custom fields. The same department-scoping constraint applies: we create the field per active department. Multiline content exceeding 2,000 characters requires a length check; Zoho Desk field character limits vary by field type and we flag any that require truncation before import.

Ticksy dropdown custom fields map to Zoho Desk picklist custom fields. Ticksy stores dropdown option lists separately from ticket records; we extract both the field schema and the option values, then create matching picklist values in Zoho Desk per department. If a Ticksy ticket has an option value that is no longer active in the source list, we preserve the historical value as a picklist option in Zoho Desk to avoid silent data loss.

Ticksy agent accounts (name, email, role) map to Zoho Desk Agents. Role-based permissions from Ticksy (admin vs agent) are preserved as a custom attribute since Zoho Desk separates admin privileges into a Support Administrator permission profile rather than a role flag. We match by email address during import; if an agent with the given email already exists in Zoho Desk, the system maps to the existing user. The customer's admin provisions any missing agent accounts before migration because OwnerId references are required on imported tickets.

Ticksy ticket labels and tags normalise to Zoho Desk Tags. Ticksy stores labels as simple string identifiers on ticket records; we extract the full label set, deduplicate, and create corresponding Tags in Zoho Desk before importing tickets. Tag character limits are checked; labels exceeding 50 characters are truncated and flagged in the mapping document. Tags attach to tickets via the Tag relation in Zoho Desk.

Ticksy email piping rules (inbound routing addresses and forwarding rules) are configuration data, not records. We extract the routing configuration and document it as a migration artifact, noting the original Ticksy email address, the routing rule, and the recommended equivalent in Zoho Desk (Setup > Channels > Email > Mail Accounts). Email piping itself cannot be migrated as code and requires manual reconfiguration in Zoho Desk by the customer's admin.

Ticksy knowledge base categories map to Zoho Desk Knowledge Base Categories. Category hierarchy (parent/child) is preserved; if the total category path depth exceeds Zoho Desk's limit we flatten and flag. Category names are checked for length compliance and special character restrictions.

File attachments on Ticksy tickets are extracted as standalone binary assets, stored in a temporary asset directory, and re-attached to the corresponding Zoho Desk ticket via the Attachment API. Large files (>20 MB per Zoho Desk API limit) are flagged for the customer to re-upload manually or configure an external file storage reference. Unusual file types are flagged for admin review before attachment.

Each Ticksy ticket reply thread maps to Zoho Desk Threads and Comments. We preserve the full chronological thread, author of each reply, direction (incoming customer vs outgoing agent), and timestamp. Zoho Desk Thread entries have a Direction field (incoming/outgoing) that we populate from the Ticksy message type. Created timestamps migrate as-is via the Thread creation timestamp. Thread authorship resolves by matching the author email against the Zoho Desk Agent table; customer emails that have no Zoho Desk Agent match create a Contact record first.