Migrate from The Service Manager to HubSpot

TSM incidents map directly to HubSpot tickets. The ticket's subject becomes the incident summary; the description body maps to the ticket's content field. Requester (contact) resolved by email lookup against HubSpot contacts. Original incident number preserved as a custom field for traceability.

TSM problems have no standalone HubSpot equivalent, so they migrate as HubSpot tickets with ticket_type set to 'Problem' and a custom Problem_ID field linking back to the source record. The problem’s status, priority, and assignee are preserved using the same value‑mapping logic as incidents, and the root cause text is stored in the ticket’s resolution notes field for future reference.

TSM Changes (Standard, Normal, Emergency) map to HubSpot tickets with a custom Change_Type pick-list. Approval fields, risk assessment ratings, and CAB dates migrate as custom properties. The approval workflow itself cannot transfer and must be rebuilt using HubSpot Forms and Workflows.

TSM configuration items (CIs) and assets map to HubSpot’s Asset object, preserving asset name, serial number, purchase date, status, and location. Custom fields such as asset type, warranty end date, and assigned location are migrated as HubSpot custom properties. For incidents that reference multiple assets, FlitStack creates the custom Incident_Asset__c junction object to maintain the N:N relationship, and each asset link is logged with the incident ID for traceability.

TSM technicians are matched to HubSpot users by email using case‑insensitive comparison, and the original TSM user ID is stored in a custom property (Source_User_ID__c) for audit traceability. Technicians without a matching HubSpot user are listed in a pre‑migration report, allowing your admin to create accounts before the bulk load. The TSM role (e.g., Assigned Technician) is preserved as a custom pick‑list property on the HubSpot user record.

TSM requesters (end users who logged incidents) map to HubSpot contacts by email. The contact’s first name, last name, phone, and company association are preserved, and any other properties are migrated as HubSpot contact properties. Unmatched requesters are created as HubSpot contacts, with the original TSM requester ID stored in a custom field (Source_Requester_ID__c) for audit continuity. The HubSpot contact record inherits the ticket history through the ticket‑contact association chain.

TSM companies map to HubSpot companies, preserving the company name, domain, industry, phone, and address fields. The parent‑company hierarchy is maintained using HubSpot’s parent company field, and the company domain is used for deduplication to avoid creating duplicate records. Any custom properties on the TSM company (such as tier, segment, or status) are migrated as HubSpot custom company properties. After migration, the HubSpot company record aggregates contact and ticket data.

TSM knowledge articles export to HubSpot Knowledge Base with title, HTML body, category hierarchy, tags, and publish status preserved. The original TSM article ID is stored in a custom field (Linked_Knowledge_Article_ID__c) on each article for traceability. Category hierarchy in TSM maps to HubSpot article categories, and articles linked to specific incidents retain that association via the custom field on the ticket.

TSM service catalog entries have no native HubSpot equivalent, so FlitStack migrates them as a custom HubSpot object (Service_Catalog_Item__c) that includes name, description, category, flag, and item ID. Additional fields such as SLA targets, pricing, and steps are stored as custom properties on the object. Because the portal‑facing catalog UI is not available in HubSpot, the display must be rebuilt using HubSpot CMS or a portal solution after migration.

TSM SLA policies with First Response and Resolution hour targets are migrated as custom number fields (SLA_First_Response_Hours__c, SLA_Resolution_Hours__c) on each ticket. HubSpot does not enforce these timers automatically; a third‑party SLA add‑on or manual tracking process is required after migration. FlitStack also exports the escalation rule definitions as a JSON file so your team can rebuild automation in HubSpot Workflows.

TSM attachments on incidents, problems, and changes are re‑uploaded to HubSpot Files, preserving file name, MIME type, and creation timestamp. Each file is linked to the corresponding ticket via HubSpot’s native file association, and the original TSM attachment ID is stored in a custom field (Source_Attachment_ID__c) on the ticket for audit traceability. File size limits of 25 MB per file apply; oversized files are flagged before migration for compression or splitting.