Migrate from Trouble Ticket Express to Gorgias

TTX Tickets map directly to Gorgias Tickets using the TTX ticket ID as external_id on the Gorgias record for deduplication. We preserve status (new/open/solved mapped to Gorgias open/pending/solved), owner, department, and creation date. TTX does not have a separate status for spam or trash; we assign a default open status and flag spam-candidate tickets for the customer's admin to review post-migration.

TTX Messages nested within Tickets map to Gorgias Message records in chronological order. We preserve author type (Customer vs Operator), timestamp, and body text including any inline quoted content. Message author email resolves to the Gorgias customer record if present or creates a new customer record during import.

TTX Customers (email-addressed submitters) map to Gorgias Customer records using email as the dedupe key. Plain-text TTX editions store customer data inline in ticket records; we extract and normalize customer records before ticket import so that the customer-to-ticket relationship is established at insert time rather than patched afterward.

TTX Operators map to Gorgias Agents. We match by email address. Any TTX Operator without a matching email in the Gorgias destination is held in a reconciliation queue for the customer's admin to provision the corresponding agent before record import resumes. Department assignments on TTX Operators map to Gorgias Team membership during the agent setup phase.

TTX custom fields using the x- naming convention require a two-pass extraction. For TTX editions with Layout Designer installed, structured fields are in the database and we parse them directly. For plain-text and MySQL editions without Layout Designer, x- fields appear only in message body text as inline key-value pairs; we run regex extraction to capture them and map to Gorgias Ticket Fields created during the configuration phase. We detect which edition is in use during discovery and adjust the extraction strategy accordingly. Gorgias limits active Ticket Fields to 25; we flag any overflow beyond that threshold during scoping.

TTX stores attachments on the filesystem and references them in the backup archive. We extract attachment files from the backup, upload them to Gorgias via the attachment API, and re-associate them with the correct ticket and message using the message ID and inline content reference. Large attachment batches (over 5,000 files) may require chunked upload with retry logic due to Gorgias API rate limits.

TTX Department assignments on tickets and operators map to Gorgias Teams. We create Teams in Gorgias during the configuration phase using TTX department names. Note that small TTX plain-text editions may not have a formal department table; in those cases we derive departments from operator assignments or create a single default Team. Team-to-ticket routing rules in Gorgias require manual configuration post-migration.

TTX Answer Library entries (the optional KB add-on module) map to Gorgias Help Center articles. TTX Answer Library has no folder hierarchy; we create a single top-level category in Gorgias and load all articles under it, preserving title and body content. Article authorship and versioning do not have direct TTX equivalents. If the customer has hundreds of Answer Library entries, we scope this as a separate article-import phase with customer review of the folder structure before import.

TTX Inventory Database (optional add-on) tracks inventory items associated with tickets. Gorgias does not have a native inventory or asset object, but the Inventory data can be mapped to a Gorgias Custom Object (available on Growth plan and above) with custom fields for item name, serial number, ticket association, and status. We scope this as a configuration step during discovery if the Inventory add-on is present.

The TTX backup module exports configuration variables including email settings, workflow rules, field labels, and branding. We parse these to produce a written configuration inventory that captures email routing addresses, ticket creation rules, and any custom field labels that inform the Gorgias Ticket Field naming strategy. We do not import configuration into Gorgias as it contains server-specific paths and credentials that are TTX-specific.

TTX base edition has no native tagging object. Tickets are classified only by status and department. If the customer has a custom tagging add-on in their specific TTX installation, we treat it as a custom field during scoping. For standard TTX, we derive Tags in Gorgias from department assignments or ticket status transitions as a post-migration suggestion; the customer chooses the tagging strategy during discovery.

TTX log files contain operational audit entries required for reporting within TTX but have no analogue in Gorgias or standard helpdesk destinations. We do not migrate log files as they represent internal operational metadata rather than customer data. We flag this as a pre-migration action item if the customer requires audit trail continuity.