Migrate from Thulium to Intercom

Thulium Cases are the primary ticket object, storing conversation threads, status, priority, assignee, and created-at timestamps. We map Case records 1:1 to Intercom Conversations, with Thulium's Case ID preserved in a custom conversation attribute for audit traceability. Thulium Case status values (Open, Pending, Resolved, Closed) map to Intercom Conversation state (open, closed). Priority from Thulium maps to an Intercom SLA priority attribute. We flag any Case without an assigned Contact during scoping because Intercom requires a contact reference on every conversation.

Thulium CRM Contacts hold name, email, phone, and custom field data. We export all Contact records and map them to Intercom People. Thulium's custom field values map to Intercom custom attributes on the People record. We apply field-level type mapping during the transform phase: Thulium list-type fields map to Intercom dropdown or string attributes, date fields to Intercom date attributes, and yes/no booleans to Intercom boolean attributes. Email address serves as the dedupe key. Intercom requires contacts to exist before conversations referencing them are created, so contacts load before cases in every migration phase.

Thulium Companies store organizational data including name, address, domain, and linked Contact records. We export Company records and map them to Intercom Organizations. The Company's domain field becomes the Organization's domain field and is used as a deduplication key during import. Intercom resolves Organizations to a contact's company attribute at import time; we map the Contact-to-Company linkage to the contact's organization relationship. Address data maps to Intercom Organization address fields. If Thulium Companies contain custom fields, these map to Intercom custom attributes on the Organization object.

Thulium stores individual email, chat, and voice interactions as sub-objects within a Case, ordered chronologically. We flatten each interaction into a linear conversation timeline within the Case, with each message or note mapped to an Intercom Conversation Part. The original message timestamp becomes the conversation_part.created_at value. Part type (message, note, assignment, status change) maps to Intercom's part_type enum. Internal notes from Thulium (visibility set to internal) map to Intercom Conversation Parts with part_type of 'note'. This flattening step is required because Intercom represents each interaction as a discrete Part rather than a nested sub-object.

Thulium supports CRM custom fields with nine distinct types including text, large text, email, numeric, link, list, yes/no, and date. We apply field-level type mapping when the destination uses different type names or constraints. For list-type fields, we also map each individual list value to an Intercom text custom attribute with a dropdown option. Date fields map to Intercom date custom attributes. Yes/no boolean fields map to Intercom boolean custom attributes. We create Intercom custom attributes via the API before contact and conversation import begins so that attribute values can be mapped during the load phase. This pre-creation step is a scoping requirement that adds time to the migration timeline.

Thulium Agents are the user accounts assigned to Cases and Companies. We map Agent records to Intercom Teammate records, resolving by email address as the unique identifier. Agent role assignments in Thulium map to Intercom's admin and agent role model where supported. If Thulium agents have been deactivated, we import them as inactive Intercom teammates to preserve historical assignment references. Any Agent without a matching email in the destination is held in a reconciliation queue for the customer's admin to provision before record import resumes.

Files attached to Cases or Contacts in Thulium are exported and re-uploaded to Intercom as conversation attachments. We preserve original filenames, file types, and the attachment-to-record linkage. Attachments are uploaded to Intercom's file API and linked to the relevant Conversation Part via the conversation_attachment resource. Attachment URL references in Thulium are resolved to file binary data during export and re-hosted or re-linked as appropriate for the destination.

Thulium Tags applied to Cases for categorization map to Intercom Conversation Tags. We create a value-mapping table during scoping for any naming differences between Thulium tag names and Intercom tag names. Tags migrate as part of the conversation import, applied via the conversation.tags field after the conversation record is created in Intercom. If Thulium tags are used for contact-level segmentation rather than case-level categorization, we map them to Intercom contact tags instead.

Thulium Case status values (Open, Pending, Resolved, Closed) and priority values (Low, Normal, High, Urgent) are mapped to Intercom Conversation state and SLA priority attribute. We design a status-mapping table during scoping. Thulium's Open and Pending map to Intercom open state; Resolved and Closed map to Intercom closed state. Priority mapping preserves the original Thulium priority value in an Intercom custom attribute for reporting continuity.

Thulium assigns Agents to Cases via a reference ID rather than a flattened assignee field. During migration we resolve each Agent reference by email against the Teammate mapping table and assign the Intercom conversation to the corresponding Teammate. If Thulium Cases are assigned to a team rather than an individual Agent, we map to an Intercom Team Inbox assignment. We flag Cases with no assignee during scoping and document the resolution rule (unassigned goes to a default team or remains unassigned) before migration begins.