Migrate from Rhino Support to Intercom

Rhino Support Tickets map to Intercom Conversations with a Ticket attribute for structured case management. The ticket subject becomes the Conversation title, ticket status (open, pending, resolved, closed) maps to Intercom's Conversation state, and ticket priority maps to a Ticket attribute or a custom priority field. We preserve the original Rhino Support ticket ID in an external_id field so that reference chains are maintained during and after migration. Conversation messages from the Rhino Support conversation thread populate the Intercom message timeline in chronological order.

Individual message records from Rhino Support's threaded conversation map to Intercom Part records within the Conversation. Each Part carries author attribution (agent or customer), timestamp, and body content. We flag messages that Rhino Support marks as internal by setting the Intercom part type to 'note' so that internal team comments remain visible to agents but do not appear in the customer-facing portion of the Conversation timeline.

Rhino Support Customer records map to Intercom Contact. We use the customer email address as the unique identifier, mapping name, phone, and company association from Rhino Support into the corresponding Intercom Contact fields. Any company association from Rhino Support resolves to an Intercom Company lookup after the Company records are migrated. Unpopulated contact fields receive empty strings rather than null values to satisfy Intercom's field validation.

Rhino Support Company records (where exposed by plan tier) map to Intercom Company. Not all Rhino Support plans expose a distinct Company object, so we evaluate the source schema during discovery and merge company data into Contact records when a standalone Company object is unavailable. When Company is available, we map company name, domain, and address fields, and use the company domain as a deduplication key during import.

Rhino Support Agent profiles map to Intercom Teammates. We resolve agents by email address match. Any agent without a matching Intercom Teammate is held in a provisioning queue while the customer's admin creates the Intercom user. Team membership associations from Rhino Support are preserved as Intercom Inbox team membership. Role names from Rhino Support are stored as a custom attribute on the Intercom Teammate record so the admin can reconfigure permissions post-migration without a direct 1:1 role mapping assumption.

Rhino Support Teams map to Intercom Inbox Teams. We preserve the team name, routing assignments, and member list during migration. In Intercom, Inbox Teams control which conversations are visible to which agents and whether assignment rules are team-scoped. We configure the Inbox Team structure before the first conversation is migrated so that ticket assignment targets are valid.

Rhino Support custom ticket fields map to Intercom Ticket Attributes on the Ticket object. We enumerate all active custom fields during discovery, map their data types to Intercom attribute types (Text, Number, Boolean, Date, List), and create the corresponding attributes in Intercom before migration begins. Fields with no equivalent Intercom type are written to a catch-all text attribute and flagged for post-migration review. This mapping is validated during the sandbox migration phase before production cutover.

Tags applied to Rhino Support tickets are migrated as Intercom Tags associated with the corresponding Conversation. We map tag names exactly, preserving case and whitespace. Intercom's tag API supports multi-value tagging on conversations, so a single ticket with multiple Rhino Support tags receives all tags as separate tag records on the Intercom Conversation. Tag-length restrictions are noted during scoping if any source tags exceed 50 characters.

File attachments on Rhino Support tickets and conversations are migrated as Intercom attachments on the corresponding Part records. We migrate attachments only where the source platform exposes a downloadable URL. Before migration, Intercom attachment settings must have 'Allow more file types' enabled for file types that are restricted by default (including .exe, .sys, .scr, .shb, .wsf and others). Large attachments or formats not accessible via API require manual re-upload post-migration and are flagged in the migration report.

Rhino Support does not expose a documented Knowledge Base API, and no article data can be retrieved programmatically. We cannot migrate KB articles automatically. During scoping, we flag this gap and advise the customer to export existing articles manually through the Rhino Support admin panel, then either import them as Intercom Articles via the Help Center API post-migration or rebuild them in Intercom's Help Center editor. The Help Center Collections structure is created in Intercom during migration so the customer has a destination for articles as they rebuild them.