Migrate from Trouble Ticket Express to Intercom

TTX Ticket maps to Intercom Conversation. The TTX ticket ID becomes an external_id attribute on the Intercom conversation. Ticket status (new, open, solved) maps to Intercom state (open, resolved) with TTX pending tickets mapped to Intercom open. TTX ticket owner (operator) maps to an Intercom Admin assigned to the conversation via the assignments API. Department maps to an Intercom Team where departments are present; if no departments exist in the plain-text edition, tickets assign to a default team.

TTX Message maps to an Intercom Conversation Part. Each message in the TTX thread becomes a part in the Intercom conversation timeline. Author type (customer vs operator) determines whether the part is a user-initiated message or an admin note. Timestamps on messages become the created_at on the conversation part. Inline attachments referenced in message bodies are extracted from the backup archive and re-uploaded via the Intercom Files API, then linked to the correct conversation part.

TTX Customer maps to Intercom Contact. The customer's email address is the primary identifier and must exist before any conversation referencing it is created. We extract all customer fields (name, email, phone if present) from the TTX backup and create Intercom contacts via the Contacts API. On plain-text editions without structured customer records, we parse customer data from ticket submission messages in the thread history. Intercom requires at minimum an email address for each contact; contacts without an email go to a reconciliation queue.

TTX Operator maps to Intercom Admin. We extract operator records (name, email, department assignment) from the backup and map them to Intercom Admins. Department assignments become Team memberships in Intercom. The customer provisions Intercom Admin accounts before migration begins; we match operators by email to ensure assignments on migrated conversations resolve correctly.

TTX Department maps to an Intercom Team. We extract department names from ticket and operator records and create corresponding Intercom Teams before ticket migration. If the TTX installation is a plain-text edition without a formal department structure, we create a single default team and assign all migrated tickets and operators to it. Team names and membership are configured before conversations are imported.

TTX x- prefixed fields require two-pass extraction: structured database columns are parsed directly from the TTX backup if the Layout Designer module is installed; body-text regex extraction captures fields that exist only as plain text in message bodies on all editions. We create corresponding custom attributes on Intercom Contacts (for customer-specific fields) and on Conversations (for ticket-specific fields) via the Attributes API before data migration begins. Field types are inferred from TTX value patterns: date strings map to date attributes, numeric values to number attributes, and text to string attributes.

TTX attachments stored on the filesystem are extracted from the backup archive and re-associated with the correct ticket and message using the backup's file reference metadata. We upload each file via the Intercom Files API and link the returned file URL to the corresponding conversation part. Files without a recognized MIME type or exceeding 10 MB (Intercom's upload limit) are flagged for the customer's admin to store externally and reference manually.

TTX Answer Library entries map to Intercom Help Center Articles. We extract question-and-answer pairs from the Answer Library backup and create Intercom articles via the Help Center API. Articles are grouped into collections that we create during pre-migration configuration. If the Answer Library module is not installed, this step is skipped and we note the gap in the deliverable inventory. Article authorship and modification timestamps are preserved in the article metadata.

The TTX Inventory Database add-on, if present, maps to an Intercom Custom Object named Inventory. We extract inventory item records (asset tag, description, status, associated ticket ID) from the backup and create corresponding Custom Object records via the Intercom Custom Objects API. The TTX ticket ID is stored as external_id on both the conversation and the custom object record to preserve the relationship after migration.

TTX configuration variables exported by the Backup Module (email settings, field labels, workflow rules as text) are parsed and provided as a written configuration inventory. These inform the Intercom workspace setup (inbox names, field labels, SLA policy thresholds) but do not migrate as functional settings. We deliver this as a pre-migration checklist for the customer's admin to configure in Intercom before data migration begins.