Migrate from Ticksy to Zendesk

Ticksy Private tickets map to Zendesk Tickets. The Private visibility flag is not a native Zendesk field, so we preserve it as a custom tag (ticksy_visibility:private) that the customer can use in views or triggers. Ticket status (open/closed), priority, assignee, and requester email transfer directly. Timestamps migrate as created_at and updated_at values preserved in Zendesk's Activity log.

Ticksy Public tickets map to Zendesk Tickets with a ticksy_visibility:public tag. If the customer activates Zendesk Community (a separate channel), we document the flag as a trigger condition to post public threads to the community forum rather than routing them as standard tickets. Without Community, public threads land as standard tickets with the tag preserved for internal visibility.

Ticksy KB articles map to Zendesk Guide Articles. The Ticksy article body (rich text or HTML) is inserted as the Zendesk article HTML body. Publish state migrates as draft or published in Zendesk. We flag any inline images as separate attachment references and re-attach them post-article creation.

Ticksy KB categories map to Zendesk Guide Sections. Ticksy's flat category structure maps directly to Zendesk Section under the destination Guide's root or a designated Category. We flag any category names that exceed Zendesk's 150-character section title limit and truncate at migration time.

Ticksy custom fields (text, multiline text, dropdown) map to Zendesk Ticket Fields or User Fields depending on whether the field applies to tickets or user records. Dropdown option lists migrate from Ticksy's separate option definitions into Zendesk's dropdown field values, with the default option flagged using the default: true attribute. We validate option list length against Zendesk's 3,500-row CSV import limit for dropdown values.

Ticksy agent accounts (name, email, role) map to Zendesk Users with the agent role assigned. Admin versus agent role in Ticksy is preserved as a custom user field (ticksy_role__c) for reference after migration, since Zendesk's role model is richer and the mapping may not be 1:1. We resolve agents by email match against the destination Zendesk org and flag any without a matching user for the admin to provision.

Ticksy customers (ticket submitters) map to Zendesk End Users. Email, name, and created timestamp transfer directly. We deduplicate by email address and flag any duplicate Zendesk end-user records that already exist in the destination. Users who also appear as agents are reconciled to the agent account.

Each Ticksy ticket reply thread maps to Zendesk Ticket Comments. Author identity (agent vs customer) is preserved as the Comment author. Internal-only comments in Ticksy map to Zendesk private comments (via is_public: false). Public comments map to public comments. Timestamps preserve chronological ordering in the ticket conversation view.

File attachments on Ticksy tickets are extracted as binary assets and re-attached to the corresponding Zendesk Ticket via the Zendesk Attachments API. We flag any attachment over 50 MB for separate handling since Zendesk's direct upload limit is 50 MB per file. Unusual file types (executable, .bat, .sh) are flagged and excluded by default unless the customer explicitly requests them.

Ticksy ticket labels and tags map directly to Zendesk Tags. Tags appear in Zendesk's tag field on tickets and are usable in triggers, views, and reports. We normalise tag strings to lowercase and strip any whitespace. Tags exceeding Zendesk's 100-character per-tag limit are truncated at migration time.

Ticksy's email piping rules and inbound email addresses are configuration data we extract and document as a written migration artifact. Zendesk's email routing is configured in Admin Center under Channels > Email. We provide a mapping table of each Ticksy inbound address to the recommended Zendesk email address or route so the customer's admin can reconfigure routing post-migration.

Ticksy's multiple-product support (Professional and Business tiers) allows tickets to be tagged with a product name. We map this to a Zendesk Ticket Field (dropdown: Product) with product names as options, or to Zendesk Organizations if the customer wants per-product account segmentation. The customer chooses the model during scoping.