Migrate from TeamSupport to Intercom

TeamSupport Tickets map to Intercom Conversations for chat and messenger-channel interactions, or to Intercom Tickets for email-channel and back-office cases. The TeamSupport ticket subject becomes the conversation title or ticket subject. TeamSupport's ticket type (Incident, Problem, Request) maps to Intercom Ticket Type, which must be pre-configured in Intercom before migration. Ticket status (Open, Pending, Resolved, Closed) maps to Intercom's open, snoozed, closed states with a custom attribute ts_original_status__c preserving the source value. Custom fields on TeamSupport Tickets migrate to Intercom Conversation Attributes or Ticket Attributes based on the channel assignment.

TeamSupport Customer records (name, email, company, custom fields) map to Intercom Contacts. Email is the required dedupe key; TeamSupport Customer.email maps to Intercom Contact.email. The customer's company association maps to Intercom Contact.company_id, which references an Intercom Company record we create from TeamSupport's Company field. Custom fields on TeamSupport Customers migrate as custom attributes on the Intercom Contact. Import order is critical: Contacts must be created before any Conversations or Tickets, per Intercom's API constraint that every conversation requires an existing contact.

TeamSupport Agents cannot be created via API, so we require manual pre-creation of Intercom Teammates with matching email addresses before migration begins. We extract TeamSupport Agent email, name, and group membership and provide a provisioning checklist. TeamSupport ticket assignments (Agent and Group) map to Intercom conversation assignments (Teammate and Team) after the Teammate and Team records exist in Intercom. This is a manual pre-step that gates the entire migration; we cannot proceed past ticket assignment mapping until Agent-to-Teammate resolution is confirmed.

TeamSupport Groups cannot be created via API and must be manually pre-created in Intercom as Teams before migration begins. Group name becomes Team name. We extract the group membership of each Agent and map to the corresponding Intercom Team during migration. Ticket assignments that reference a Team in TeamSupport resolve to the matching Intercom Team. Group-to-Agent membership lists migrate as Team membership after both records exist.

TeamSupport Products (name, version, product line, custom fields) require pre-configured Intercom Custom Objects before migration. We create a Product Custom Object in Intercom with fields matching the TeamSupport product schema: product_name (string), product_line (string), current_version (string), and any custom fields migrated as additional attributes. Product-to-ticket linkage uses a custom attribute ts_product_id__c on the Conversation that references the Product Custom Object record, which Fin can query if the knowledge base references product-specific troubleshooting content.

TeamSupport Product Versions map to a ProductVersion Custom Object in Intercom linked to the Product Custom Object via a lookup relationship. We pre-configure both custom objects during discovery so that version-to-product associations are preserved. Version names migrate as the primary identifier; the associated product reference maps to the parent Product custom object record. Ticket-level version references migrate as a custom attribute on the Conversation.

TeamSupport Product Lines (which group related Products) map to a ProductLine Custom Object in Intercom with a has_many relationship to the Product Custom Object. We configure the relationship during discovery and migrate product line assignments as foreign-key references on the Product custom object records.

TeamSupport Inventory Assets (linked to Products and Tickets with custom fields) map to an Asset Custom Object in Intercom. We pre-configure the schema with fields matching the TeamSupport asset schema, including the product lookup and any custom fields. Asset-to-ticket linkage migrates as a custom attribute on the Conversation.

TeamSupport KB articles and categories migrate to Intercom Articles under the Help Center. Article body (HTML content) migrates as Article body, with category hierarchy preserved as Intercom article collections. Article visibility settings (public, internal) map to Intercom's draft and published states. We preserve the original article ID in a custom attribute ts_kb_article_id__c for reference. Large KB migrations (over 200 articles) require an extended article restructuring step because Intercom Articles use a different content structure than TeamSupport's HTML editor.

TeamSupport custom fields on Tickets, Customers, Products, Product Versions, and Inventory Assets map to Intercom custom attributes. We audit custom field types during discovery: dropdown fields require explicit value mapping tables (TeamSupport picklist options may not exist in Intercom), date fields map to Intercom date attributes, and text fields map to string attributes. Multi-select picklists in TeamSupport map to Intercom String attributes with comma-separated values or list attributes depending on the Intercom plan. Dropdown fields without a mapped value default to null; we produce a value-mapping table for customer review before import.

TeamSupport ticket attachments migrate via sequential download from TeamSupport API and re-upload to Intercom. TeamSupport does not expose a bulk-attachment export endpoint, so we download each file individually, preserve the original filename, and associate it back to the correct Conversation in Intercom. Attachments over 50MB require direct file-transfer coordination with the customer. For large attachment volumes (over 5,000 files), we implement batch chunking with exponential backoff to stay within TeamSupport API rate limits.

TeamSupport ticket tags migrate as Intercom Tags on the Conversation. Where TeamSupport uses nested tag hierarchies (e.g., product/bug/urgent), we flatten to a flat tag model in Intercom using hyphenated names (product-bug-urgent). Tags used for internal classification migrate as internal tags if Intercom's plan supports them; otherwise they migrate as custom conversation attributes.