Migrate from Ticksy to Gorgias

Private tickets from Ticksy migrate to Gorgias Ticket as standard support tickets. The private visibility flag is not a native Gorgias field, so we store it as a custom attribute ticket_visibility__c set to 'private' or as a tag 'ticksy-private' so that teams can distinguish these from migrated public threads. Status (open/closed/pending) maps directly to Gorgias Ticket status values.

Public tickets from Ticksy migrate to Gorgias Ticket with ticket_visibility__c set to 'public' or a tag 'ticksy-public'. In Gorgias, public community threads do not have a native equivalent — they land as standard tickets rather than community forum posts. We document this distinction in the migration artifact and recommend the customer evaluates Gorgias Help Center community features as a separate initiative post-migration.

Each Ticksy ticket reply thread — including both agent and customer messages, author attribution, and chronological timestamp — migrates to Gorgias Ticket Message records in order. We preserve the sender type (agent vs customer) using the message.author_type field and set message.created_datetime to the original Ticksy timestamp so conversation context is intact in Gorgias.

Ticky KB articles with title, body (HTML), category, and publish state migrate to Gorgias Help Center articles. HTML body content transfers as-is. Publish state (draft/published) maps to Gorgias article visibility settings. We normalise category names to Gorgias Help Center category names and flag any article that exceeds Gorgias's title length limit for manual truncation during review.

Ticksy text custom fields on tickets migrate to Gorgias custom fields with type text. The field label maps to Gorgias label, and we preserve any description from Ticksy's field definition. Priority ordering migrates from Ticksy's field sequence to Gorgias priority values (0-5000 range on the custom field priority field).

Ticksy multiline text fields map to Gorgias text custom fields. Since Gorgias does not distinguish single-line from multiline text at the field definition level, we set the field as text and confirm with the customer during scoping whether the multiline behaviour should be enforced at the form level or documented as a UI expectation rather than a schema constraint.

Ticksy dropdown fields have two components: the field definition (label, type) and the option list (stored separately from ticket records). We extract both the field schema and the option values, then create a Gorgias custom field with the options defined as allowed values. We validate that the total option count does not exceed Gorgias's picklist limits and flag any option value that exceeds Gorgias's 255-character label length for manual truncation.

Ticksy agent accounts (name, email, role) map to Gorgias Users. Admin vs agent role designation from Ticksy migrates as a custom attribute or tag on the Gorgias User since Gorgias's role model is permission-set based rather than a binary admin/agent flag. We resolve by email match — if a Gorgias User with the same email already exists, we link to that record rather than creating a duplicate.

Ticky customer records (name, email, any associated metadata) migrate to Gorgias Customer. The customer.email field serves as the primary identifier and dedupe key. If the same email appears on multiple Ticksy tickets (indicating a returning customer), we consolidate into a single Gorgias Customer record with multiple associated Ticket records.

Ticksy ticket labels and tags are simple string identifiers. We normalise each label to a Gorgias tag. Tags that exceed Gorgias's 100-character tag length limit are flagged for manual review and truncation. We also flag any label that appears on fewer than five tickets as a low-frequency tag candidate for the customer to clean up during review.

Ticksy knowledge base categories (used for organising FAQ articles) map directly to Gorgias Help Center categories. We preserve the category name and any description. If a Ticksy article has no category assignment, we assign it to a default Gorgias category (e.g., 'General') that the customer specifies during scoping.

File attachments on Ticksy tickets are extracted as binary assets and re-attached to the corresponding Gorgias Ticket Message. We extract attachment filename, MIME type, and binary content. Files exceeding Gorgias's attachment size limit (typically 25 MB per file) are flagged for the customer to host externally and link manually, or to upload directly in Gorgias post-migration. Unusual file types (e.g., .exe, .bat) are flagged for security review.

Ticksy's email piping rules (inbound email addresses and routing logic) are configuration data, not records. We extract the routing configuration, inbound address list, and any auto-assignment rules as a written migration artifact. The customer recreates the email integration in Gorgias using their documented inbound email addresses and configures routing in Gorgias Rules. This is not a programmatic migration of email routing logic.

Ticksy ticket statuses (open, pending, resolved, closed) map directly to Gorgias ticket status values. We preserve the original closed_datetime where available. Any custom status values beyond the four standard Ticksy statuses are flagged as non-standard and mapped to the closest Gorgias equivalent or converted to a tag for the customer to resolve during review.