Migrate from Trouble Ticket Express to Zoho Desk

TTX Tickets map directly to Zoho Desk Tickets. We extract TicketID, Subject, Status (new/open/solved), Priority, Owner (operator email), Department, and CreatedDate from the backup archive. Status values map to Zoho Desk status options (Open, Pending, On Hold, Solved, Closed) based on TTX status enumeration. CreatedDate is preserved as a custom field if the destination Zoho Desk plan does not support custom ticket creation dates, since some migration methods default creation timestamps to migration day. TTX ticket descriptions become the Ticket Description field; TTX message threads populate the Conversations tab in chronological order.

TTX Messages within each Ticket map to Zoho Desk Conversation entries. We extract Author (customer email or operator email), Body text, Timestamp, and IsIncoming flag (computed by matching author to the ticket's Customer vs Operator tables). Thread direction (Incoming for customer messages, Outgoing for operator replies) is set accordingly. Inline attachments referenced in message bodies are resolved against the extracted attachment directory and re-uploaded to the corresponding Zoho Desk Conversation entry via the desk.zoho.com API.

TTX Customers (email-addressed ticket submitters) map to Zoho Desk Contacts. We extract Name, Email, and any structured address or phone fields present in the backup. Email address is used as the dedupe key during Zoho Desk import. On plain-text TTX editions, customer records may be embedded in message sender addresses; we parse these to construct Contact records before ticket import so that the Contact lookup is satisfied at import time.

TTX Operators map to Zoho Desk Agents. We extract Name, Email, Department assignment, and Role (admin/regular) from the backup. Agents are provisioned in Zoho Desk by email match. We create the corresponding Zoho Desk departments before agent import so that each Agent can be associated with their TTX department. Any Operator without a matching Zoho Desk user at migration time is held in a reconciliation queue for the customer's admin to provision.

TTX Departments map to Zoho Desk Departments. We extract all department names and map them one-to-one. If TTX uses a flat structure (no formal departments on plain-text editions), we create a default 'Support' department and associate all agents and tickets to it. Department provisioning must complete before Agent import and before Ticket import so that the department lookup is satisfied at each stage.

TTX custom fields declared with the x- prefix require a two-pass extraction strategy. On editions with the Layout Designer module, structured x- fields are stored as database columns and migrate directly to Zoho Desk custom fields of equivalent type. On plain-text editions without Layout Designer, x- fields appear only in message body text; we apply regex extraction keyed on the field prefix pattern and populate Zoho Desk custom fields with the parsed values. The field type in Zoho Desk (Text, Dropdown, Number, Checkbox) is inferred from the extracted value format. This step extends scoping by one to three days depending on the number and complexity of x- fields in use.

TTX file attachments are stored on the filesystem and referenced in the backup archive. We extract the attachment directory, preserve filenames and MIME types, and upload each attachment to the corresponding Zoho Desk Ticket (via the /tickets/{id}/attachments endpoint) or Conversation entry. Attachment references embedded in TTX message bodies are resolved against the extracted file list and re-linked to the correct Zoho Desk record. TTX attachments exceeding the Zoho Desk 25 MB per-file limit are flagged during discovery and chunked or replaced with a download link stored in the ticket description.

TTX Answer Library entries map to Zoho Desk Help Center articles. We extract article title, body text, category (if structured), and publish status from the backup. The mapping is a lookup because Answer Library is an optional add-on and may not be present in all TTX installations. Articles are created in Zoho Desk's Help Center under a default 'Migrated Content' category, and the customer's admin assigns them to proper categories post-migration. Note that Zoho Desk's Standard tier and above is required for full Help Center functionality.

The TTX Inventory Database add-on tracks items associated with tickets. We extract inventory records (ItemID, Name, Status, Ticket association) and map them to a Zoho Desk Custom Object if the destination is on Standard tier or above, or to a Zoho Desk asset-like custom module if on Express. This object is optional and only present in TTX installations that purchased the Inventory add-on. We scope it during discovery and include it in the migration only if it carries active or historically relevant data.

TTX backup exports configuration variables including email submission settings, ticket field labels, and workflow-like rules (auto-assignment, status transitions). We parse these into a written configuration inventory document that the customer's admin uses to rebuild equivalent Zoho Desk Workflow Rules and Macros. No workflow logic migrates as executable code because TTX's configuration model is not compatible with Zoho Desk's Blueprint and workflow rule format.

TTX tickets use a fixed status enumeration (New, Open, Solved) that maps to Zoho Desk status options (Open, Pending, On Hold, Solved, Closed). We create a status mapping table during scoping and configure the corresponding Zoho Desk status values before ticket import. Any TTX status not directly representable in Zoho Desk (e.g., a custom status added via Layout Designer) is mapped to the closest Zoho Desk equivalent and noted in the migration report.

Zoho Desk's multichannel features (email, live chat, messaging) route incoming communications to Tickets based on the Contact's email address. We ensure that every TTX Customer email is imported into Zoho Desk Contacts before ticket migration so that the email routing and contact association functions correctly. This is a prerequisite step in the migration sequence.