Migrate from Support.com Cloud to Intercom

Support.com Cloud Tickets map to Intercom Conversations. The ticket subject becomes the Conversation title or first message body. Ticket status (open, pending, resolved, closed) maps to Intercom Conversation state (open, snoozed, closed). Priority from Support.com becomes a custom Conversation attribute or tag. We preserve ticket creation timestamp as Conversation created_at and last updated timestamp as Conversation updated_at. Support.com's unique ticket ID is stored in a custom attribute for audit trail.

Support.com Cloud ticket comments map to Intercom conversation_parts ordered by timestamp. Agent replies become admin-type conversation_parts with author_type = admin; customer replies become user-type conversation_parts. The original comment body and any HTML formatting are preserved as part_body. Part timestamps are set to the original comment timestamp to preserve the full conversation timeline ordering.

Support.com Cloud Customer records map to Intercom Contacts. The customer's primary email becomes the Contact email (used as the primary identifier). Name, phone, and any custom contact fields migrate to Intercom's standard Contact attributes plus any custom attributes we pre-create. Support.com's device-linked customer records require resolution: device identifiers become custom Contact attributes if they exist in Intercom, or we store them as a JSON attribute for reference.

Support.com Cloud Agent profiles map to Intercom Users. Agent name and email transfer directly. Role and team assignment from Support.com become Intercom team membership and the user's inbox assignment permissions. We resolve agents by email match to Intercom users. If a Support.com agent has no matching Intercom user, they go to a reconciliation queue for the customer's admin to provision before record import continues.

Support.com Cloud Company records (where enabled for B2B accounts) map to Intercom Companies. The company name, domain, and any associated custom fields migrate to Intercom's Company object. We use domain as the dedupe key during import. Company-contact links from Support.com become Contact-Company relationships in Intercom. If the Support.com Cloud instance does not have the Company object enabled, we skip this mapping.

Support.com Cloud Macros (canned response templates and workflow actions) are exported and recreated as Intercom Saved Replies. Macro trigger logic (the conditions under which a macro activates) does not have a direct Intercom equivalent and is documented in the migration handoff for the customer to rebuild as Intercom Workflow rules or Inbox rules. Saved Replies are stored under the Admin Settings for the team that will use them.

Ticket attachments from Support.com Cloud (screenshots, logs, device exports) are batch-transferred and re-associated to the destination Conversation via Intercom's attachment upload API. Support.com's legacy file naming conventions (special characters, non-standard encoding) are normalized to UTF-8 before upload. Attachments exceeding Intercom's file size limit (25 MB per file) are flagged separately for the customer to handle manually or via alternative file hosting.

Support.com Cloud ticket custom fields have no public schema, so we enumerate the live field inventory during the discovery phase by logging into the customer instance and recording each field name, type, and options. Each discovered custom field is then pre-created as a custom conversation attribute in Intercom before migration begins. This discovery step adds one to two days to the project timeline and must be completed before field mapping is finalized.

Support.com Cloud customer custom fields are enumerated during discovery and then pre-created as custom Contact attributes in Intercom. Any picklist or multi-select options from Support.com become Intercom dropdown or multi-select custom attributes with matching option values. Boolean and date custom fields map to equivalent Intercom attribute types.

Tags applied to tickets in Support.com Cloud are exported and applied as Tags in Intercom on the relevant Conversation. Tag naming conventions may conflict with existing Intercom tags; we prefix source-system tags with the Support.com instance name or the customer's internal tag namespace to avoid collisions. Tags without a matching Intercom tag are created during import.

Support.com Cloud ticket categories (used for ticket routing or classification) map to Intercom Tags for flexible filtering or to Team Inbox assignment rules depending on the customer's preferred workflow. We document the routing logic during scoping so that category-based ticket routing is replaced with either Intercom's team assignment rules or tag-based filtering in the customer's inbox setup.

Support.com Cloud ticket status change history (opened, pending, resolved, closed transitions) is preserved as part of the conversation timeline in Intercom. Each status change from Support.com becomes a system-generated conversation_part with the old and new status recorded in the part body. This preserves the audit trail that support managers rely on for SLA tracking and service reviews.