Migrate from iSupport Software to HubSpot Service Hub

iSupport Incidents map to HubSpot Tickets with the source 10-digit alphanumeric ID preserved in a custom property hs_source_id__c for cross-reference. Ticket status (Open, Pending, Resolved, Closed) maps to HubSpot Ticket pipeline stages. Priority, category, assignee, and requester migrate as standard Ticket properties. Conversations and comments migrate as HubSpot Ticket conversations linked by hs_ticket_id.

iSupport Customer records map to HubSpot Contacts. The customer's contact details (name, email, phone, address) migrate as standard Contact properties. Custom fields on the Customer record map to HubSpot Contact Properties with type matching (string, number, date, picklist). Any picklist values require field-level audit to separate schema from record data before transformation.

iSupport Companies map directly to HubSpot Companies. The company-to-customer linkage (company_id on Customer records) is preserved by resolving the Company HubSpot ID at Contact insert time. Domain from iSupport becomes the Company Website field and serves as the dedupe key.

iSupport Knowledge Entries (FAQs and articles) map to HubSpot Knowledge Base articles. Both title and body content migrate with rich text preserved. Category structure from iSupport maps to HubSpot Knowledge Base folders or sections. Attachment links are preserved as URL references in the article body. We use the HubSpot Knowledge Base API for article import rather than CSV to preserve article ordering and language settings.

iSupport Assets (hardware, software, and configuration items) have no native HubSpot equivalent, so we design a HubSpot Custom Object named Asset with properties for serial number, purchase date, status, and vendor. Asset-to-incident linkage requires extraction of the incident_asset_link junction table from iSupport; if that table is unavailable, we fall back to the text-based asset_id field on the Incident record. The Asset-to-Ticket relationship is then built as a custom association in HubSpot.

iSupport custom fields on Incidents and Customers map to HubSpot Contact and Ticket Properties. Both platforms support string, number, date, boolean, and picklist field types, but picklist values require explicit mapping because iSupport picklist definitions are not always separated from record data in standard exports. We audit each custom field during discovery to separate picklist definitions from actual values before transformation.

iSupport post-resolution surveys attach to Incidents and capture satisfaction data with question and answer schemas. HubSpot Service Hub has no native survey object, so we design a HubSpot Custom Object named Survey Response with properties for the survey name, question, answer, score, and a lookup to the migrated Ticket. Survey results that require post-migration segmentation stay in the custom object rather than a handoff document.

Change Records are only available in iSupport Service Desk Edition. Fields for change type, risk assessment, approval workflow, and change owner map to a HubSpot Custom Object named Change Record with a lookup to the related Ticket. We run an edition-entitlements check during discovery to confirm whether Change Records exist in the source data before designing the destination schema. If the customer upgraded from Incident Management to Service Desk Edition recently, we also check whether historical Change records were ever created.

The CMDB holds CI relationships and dependency maps, gated behind the Service Desk Edition. We design a HubSpot Custom Object named Configuration Item with properties for CI name, type, status, serial number, and a self-referential lookup (ci_depends_on__c) to model item-to-item dependencies. CI-to-incident relationships migrate as Ticket lookups to the CI custom object.

iSupport email routing rules use a positional ordering system evaluated by the Email Processing agent. On-premise deployments store email configuration differently from hosted deployments. We document the source email rule order, conditions, and actions during discovery and deliver a written configuration map for the customer to rebuild in HubSpot's Shared Inbox routing rules. Email rules do not migrate as code.

iSupport assignees and support staff map to HubSpot Users. We resolve owners by email match. Any iSupport user without a matching HubSpot User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Active versus inactive status is preserved.

Inline images and file attachments on iSupport Incident records migrate as HubSpot File records linked to the corresponding Ticket conversation. Attachment URLs from iSupport are preserved in the conversation body or migrated as File attachments with ContentDocumentLink associations. We verify attachment encoding during discovery because iSupport exports sometimes encode binary attachments in base64 within export files.