Migrate from Trouble Ticket Express to HubSpot Service Hub

TTX Tickets map directly to HubSpot Tickets. We extract the ticket ID, status (new/open/on hold/solved/closed), owner, department, priority, creation date, and last modification date from the backup archive. The HubSpot ticket pipeline must be pre-configured with stage values that map from TTX status: TTX new maps to HubSpot new, TTX open maps to HubSpot open, TTX on hold maps to HubSpot pending, and TTX solved/closed maps to HubSpot closed. Ticket priority from TTX maps to HubSpot priority (low/high). Original TTX ticket IDs are preserved in a custom HubSpot property hs_ttx_original_id__c for audit and cross-reference.

TTX Messages are threaded chronologically within each ticket. We extract author type (customer/operator), author name, author email, timestamp, body text, and any inline attachment references. Each message becomes a HubSpot Ticket Engagement of type email or note, with the author email resolved to a HubSpot Contact. Operator messages of type internal_note in TTX map to HubSpot internal ticket comments. Plain-text body content migrates as-is; HTML-formatted bodies are sanitized to plain text to avoid rendering issues in HubSpot's conversation view.

TTX Customers are email-addressed submitters captured on ticket submission forms. We extract the customer database from the backup archive and map each to a HubSpot Contact. The HubSpot Contact email address is the dedupe key; if a Contact already exists in HubSpot, we update rather than create. Customer name splits into HubSpot firstname and lastname where parseable. On plain-text TTX editions without a formal customer database, we extract unique submitter emails from message headers and create Contacts from those. TTX has no native contact lifecycle; we set lifecycle stage to customer on migration for contacts with at least one associated ticket.

TTX Operators are service desk staff with ticket ownership and assignment. We extract operator records (username, display name, email, department, role) and map them to HubSpot Users. Owner resolution happens by email match: each TTX operator email is matched against HubSpot Users, and tickets are assigned to the matched User. If no HubSpot User exists for an operator, the ticket is assigned to a default migration user and flagged in the reconciliation report for the admin to provision the User before production migration. TTX role (admin/operator) maps to HubSpot Super Admin or regular User role.

TTX Departments are assigned to tickets and operators. We extract all department names from the backup archive and create HubSpot Teams with matching names. Tickets are associated with the corresponding HubSpot Team on migration. On plain-text TTX editions without a formal department structure, we scan operator assignments and derive departments from operator groups if present. If no department structure exists, we create a single default team and flag this as a configuration item for the customer's admin to refine post-migration.

TTX custom fields use the x- naming convention. Without the Layout Designer module, custom field values appear only in message body text; we run a regex extraction pass on message bodies to capture x-fieldname:value pairs and store them in HubSpot custom ticket properties named hs_ttx_x_<fieldname>. With the Layout Designer module, custom fields are structured database columns that we extract directly. We detect which edition is in use during discovery and apply the appropriate extraction strategy. HubSpot custom properties are created as single-line text or multi-line text depending on detected content type.

TTX File Attachments are stored on the filesystem and referenced in the backup archive. We extract attachments from the archive, re-associate them with the correct TTX ticket and message using the path references, and upload them to HubSpot as ContentDocument records linked to the ticket via ContentDocumentLink. Files are uploaded individually via the HubSpot Files API before linking. We handle common file types (PDF, PNG, JPG, DOCX, XLSX) and skip any file type HubSpot does not support as a content block. Attachment file names are preserved in the ContentDocument title.

The TTX Answer Library is an add-on module containing pre-written responses. We extract Answer Library entries (title, body text, category) and map them to HubSpot Knowledge Base articles. Each article is created in the default HubSpot knowledge base with the TTX category name mapped to a HubSpot article category. Answer Library entries without a category are assigned to an Uncategorized bucket. We flag this as a post-migration review item because TTX Answer Library does not support article versioning or availability rules; HubSpot supports draft/published states and team-based access controls that the customer's admin should configure.

The TTX Inventory Database add-on tracks inventory items associated with tickets. We extract inventory records (item name, serial number, associated ticket, status) and map them to a HubSpot custom object named TTX_Inventory_Item. We create the custom object schema in HubSpot during the pre-migration phase, including fields for item_name, serial_number, ttx_ticket_id__c (lookup to Ticket), and status. This object is only present in TTX installations with the Inventory Database module purchased. If absent, this mapping step is skipped.

The TTX backup exports system configuration variables including email routing settings, field labels, workflow rules, and ticket form definitions. We parse these for context during scoping to understand TTX behavior (e.g., whether email-to-ticket submission is enabled, what custom fields are declared). Configuration variables do not map to HubSpot equivalents because HubSpot configures these features differently (via workflow builder, ticket property settings, and form editor). We deliver a written configuration inventory summarizing TTX settings that the customer's admin should review when setting up equivalent HubSpot features.

TTX uses a fixed set of ticket statuses: new, open, on hold, solved, closed. HubSpot Service Hub uses configurable pipeline stages. We configure a default HubSpot pipeline with stages that map directly: new maps to New, open maps to Open, on hold maps to Pending, solved maps to Solved, and closed maps to Closed. The customer can rename these stages to match their existing terminology during pre-migration configuration. We do not create multiple TTX-style pipelines unless the customer has purchased the HubSpot Professional or Enterprise tier that supports multiple pipelines.

TTX log files contain operational audit entries (login events, ticket update events, system events) rather than customer data. They have no analogue in HubSpot Service Hub and are not migrated. If the customer requires audit history for compliance, we recommend enabling HubSpot's native audit log feature at the Professional or Enterprise tier rather than migrating the TTX operational log.