Migrate from iSupport Software to Intercom

iSupport Incidents map to Intercom Conversations. The 10-digit alphanumeric ticket ID from iSupport is stored in a custom conversation attribute isupport_ticket_id__attr for cross-reference. Incident status (open, pending, resolved, closed) maps to Intercom's open, closed, and snoozed state. Priority from iSupport becomes a custom attribute priority__attr mapped to Intercom's priority field. Notes and internal comments from iSupport migrate as internal notes on the Intercom Conversation.

iSupport Customer records map directly to Intercom Contacts. Standard fields (name, email, phone, address) migrate cleanly. Custom fields attached to Customer records require field-level audit before transformation, with picklist values explicitly mapped to Intercom's allowed attribute values or created as new options. The customer's company linkage (if present) is resolved via the Customer-to-Company junction before import.

iSupport Company records map to Intercom Companies. Company name becomes the Intercom Company name, and domain becomes the website field used for Intercom's company unification by domain. The iSupport customer-to-company linkage is preserved via Intercom's contact-to-company relationship.

iSupport Knowledge Entries (KB articles and FAQs) map to Intercom Articles. The article title, body content (including any rich text or HTML), and internal/external status migrate. iSupport's category hierarchy (top-level categories and sub-categories) maps to Intercom's Collection and Section structure, though deep ITIL-style categorization may flatten into a shallower collection hierarchy.

iSupport Assets have no direct Intercom equivalent. We recommend creating an Intercom Custom Object named ConfigurationItem with fields for serial number, purchase date, status, and type. The asset-to-incident linkage table (incident_asset_link or equivalent) migrates to a Custom Object relationship rather than a native linked record type. If the incident_asset_link junction table is unavailable in the export, we fall back to text-based asset IDs stored on the Conversation via a custom attribute.

Custom fields on iSupport Incidents map to Intercom Conversation Attributes. Picklist values from iSupport are audited separately from the field schema before transformation and mapped to Intercom's attribute allowed values or created as new options. Multi-select picklists map to multi-value attributes in Intercom. Required-field constraints in iSupport become Intercom attribute required flags, though these are enforced at workflow time rather than at import.

Custom fields on iSupport Customer records map to Intercom Contact Attributes. The same picklist value extraction and mapping process applies as for Incident custom fields. Any custom field default values are preserved as attribute defaults in Intercom for new Contacts created after migration.

iSupport Surveys attach to Incidents and capture post-resolution satisfaction data. Intercom has no native survey object, though CSAT ratings are available on Conversations for recent interactions. We recommend creating a Custom Object named SurveyResponse with fields for the related Conversation ID (via a custom relationship), survey question text, and answer value. Survey schemas require mapping work since the answer schema differs between platforms.

Change Records are only available in the iSupport Service Desk Edition and have no direct equivalent in Intercom. We do not migrate Change Records. Instead, we extract a full list of Change Record IDs, types, risk assessments, and related Incident linkages and deliver them as a structured CSV inventory for the customer's admin to manually recreate as Intercom Custom Objects, internal notes, or a separate tracking system if Change Management tracking is still required.

CMDB entries and CI relationships are gated behind the iSupport Service Desk Edition and have no Intercom equivalent. Intercom is not an ITSM tool and does not support configuration item tracking or dependency mapping. We extract CI records and relationship data (item-to-item dependencies) and deliver them as a structured CSV inventory for the customer to assess against external ITSM tooling if CI tracking remains a compliance or operational requirement.

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 extract the email_rules and email_accounts tables and deliver them as a structured inventory. Intercom's email inbox and routing rules are configured natively in the Inbox settings; the customer's admin rebuilds these based on our documented rule inventory.