Migrate from Track-It! to HubSpot Service Hub

Track-It! HDTickets records map directly to HubSpot Ticket objects. Ticket priority (Critical, High, Medium, Low), status (Open, In Progress, Resolved, Closed), description, and resolution text migrate as standard HubSpot Ticket properties. Ticket owner resolves to a HubSpot User by email match from HDUsers. Custom fields appended to HDTickets are enumerated during schema discovery and created as custom ticket properties in HubSpot before import. Historical timestamps (created date, last modified, resolved date) preserve from the source HDTickets record.

HDTicketHistory audit records — each status change, assignment change, or comment — migrate as HubSpot Ticket Engagements (internal notes or ticket activity records) preserving the original timestamp and the technician who made the change. We flatten the HDTicketHistory table into a chronological activity stream so the ticket's full timeline is visible inside HubSpot without querying a separate history table.

HDUsers technician profiles migrate to HubSpot Contacts, with a custom property trackit_role__c set to Technician or End User based on the HDUsers profile type. Group assignments from HDGroups migrate as HubSpot Team associations or a custom property trackit_group__c for reference. The customer's HubSpot admin provisions the actual User accounts separately; we match technicians by email and flag any unresolved owners for manual provisioning before record import.

Track-It! Assets table contains hostname, serial number, purchase date, warranty status, and location fields with no direct HubSpot equivalent. We map Assets to a HubSpot custom object (Asset__c) pre-created during schema setup, with fields for name, serial_number__c, purchase_date__c, warranty_expiry__c, and owner_contact__c as a Lookup to the related Contact. For organizations not licensing HubSpot custom objects, asset data maps to custom properties on the Contact (end-user assets) or Ticket (incident-linked assets).

ConfigItems store CI classifications, naming conventions, and component hierarchies that vary by Track-It! installation. The schema discovery phase captures the full ConfigItems column set before mapping. CIs linked to Change Requests or Tickets carry their relationship as a custom property ci_id__c on the parent record in HubSpot. Where Track-It! uses a BCM-linked CI classification system, those classification labels migrate as text or picklist values in a custom field without recreating the BCM relationship graph.

BCM (Business Configuration Management) linkage records that define complex CI-to-asset and CI-to-change-request graphs are specific to Track-It!'s BCM module and do not survive migration to any non-BMC destination. We run a pre-migration query enumerating every BCM-linked record and surface the full list to the customer. The customer decides whether to recreate those relationships manually in HubSpot using a custom object model or accept them as a documented gap at migration sign-off. This is not a migration limitation — it is a structural difference between BMC's BCM module and HubSpot's data model.

Track-It! ChangeRequests carry a full lifecycle: initiation, approval routing, risk assessment, CAB review, implementation, and closure — stored across multiple fields in the ChangeRequests table. HubSpot has no native change request object. We map ChangeRequests to HubSpot Tickets with a custom property cr_type__c (Standard, Normal, Emergency) and a custom field for risk_level__c, approval_status__c, and cab_approval_date__c. The approval chain is preserved as a structured text block in a custom property for the customer's admin to rebuild as a HubSpot workflow post-migration.

Track-It! stores SLA-to-priority timer mappings in system-configuration tables, not in the ticket record itself. We extract the SLA definitions for each priority level (First Response Target, Resolution Target, Business Hours) and map them to HubSpot Ticket SLA properties if the customer is on Professional tier or above. If Starter tier, SLA definitions are documented in a written handoff so the customer's admin can recreate them as ticket property fields or timer-based automation rules.

Track-It! attachments are stored as BLOBs in the database or as file references to the Track-It! file store. We extract attachments to a structured file package during migration, then associate each file with the parent Ticket or Asset record in HubSpot using HubSpot's file upload API. The original filename and MIME type are preserved. Attachments exceeding HubSpot's file size limits are flagged and delivered as a separate file package with a mapping reference to the parent record.

Track-It! KB articles are stored in a dedicated module table with article body, category assignments, tag relations, and publication status. We extract the full article content, metadata, and category hierarchy and map them to HubSpot Knowledge Base articles, grouping by the Track-It! category structure. Articles that reference BCM relations or internal-only CI data are flagged and mapped without the internal reference.

Purchase Order headers and line items in Track-It!'s PO module migrate as custom fields on the associated Asset or Contact record, or as a structured note attached to the parent record. Where the PO references a specific asset, the PO number and vendor fields become custom properties on the corresponding Asset custom object in HubSpot. Line items are stored as a JSON-formatted custom property for admin reference.

Ticket audit history (HDTicketHistory), asset change logs, and CR lifecycle events stored across per-module history tables extract as a structured dataset and attach to the migrated records in HubSpot. For tickets, history records appear as internal note engagements preserving the timestamp, technician name, and action taken. Asset change logs attach as file-based records or custom field entries on the custom Asset object. The audit trail is delivered as a structured CSV export for compliance purposes alongside the live migration.