Migrate from Novo Customer Support to Intercom

Novo Tickets map directly to Intercom Conversations. Each Conversation inherits the source ticket's subject, status (open, pending, resolved, closed), priority, assignee (mapped to the destination teammate), and custom ticket fields. We preserve the original ticket creation timestamp as a custom attribute for audit ordering. Tags from the source ticket migrate as Conversation tags in Intercom.

Novo's threaded Conversation history on each Ticket maps to Intercom Conversation Parts in chronological order. Each Part carries the author (agent or contact), message body, timestamp, and privacy flag. We validate threading fidelity by checking that the Part sequence preserves the original message order before marking the batch complete.

Novo Customers map to Intercom Contacts by email as the primary dedupe key. The customer's name, email, phone, and custom properties migrate to Intercom Contact attributes. Novo's role-based permission fields (AD field mapping in enterprise) do not transfer; we flag these as Intercom Admin role assignments to be handled post-migration.

Novo Companies map to Intercom Companies 1:1. The company name and domain become the Intercom Company name and website fields. We use the domain as the dedupe key during import. Company-linked contact counts migrate with the relationship preserved via the Contact-to-Company association in Intercom.

Novo Agents map to Intercom Admins (full workspace access) or Teammates (inbox-only access) based on the source agent's permission level. Role-based permission names and OU structures from Novo's enterprise configurations translate to Intercom Team membership and Inbox assignment rules. Agents without a clear permission mapping are assigned as Teammates by default; the customer reviews and upgrades access post-migration.

Novo Teams map to Intercom Teams for routing and reporting. We preserve team membership by assigning migrated agents to the corresponding Intercom Team. Intercom Teams control which conversations appear in each inbox, enabling the same routing logic from the source.

File attachments on tickets and conversations migrate as binary blobs with file metadata (name, size, content type) preserved. Intercom restricts certain file types (.exe, .sys, .scr, .shb, .wsf) for security reasons; we check the source attachment inventory pre-migration and flag any prohibited types for the customer's admin to handle outside the migration scope.

Novo KB Articles map to Intercom Articles within a Collection. We preserve article title, body content, author attribution, and internal/external visibility flags. Internal articles in Novo map to Draft status in Intercom so the customer can review before publishing. Articles are imported in category order for structural fidelity.

Novo KB Categories map to Intercom Collections. Each Collection holds the migrated articles and preserves the category hierarchy as a top-level organizational structure. Intercom does not support multi-level nested categories natively; we flatten to single-level Collections and note the original hierarchy in the migration inventory for manual restructuring if needed.

Tags applied across tickets, customers, and articles migrate as flat taxonomy to Intercom's Tag model. Tag assignments are preserved per record (ticket, contact, company, article). Intercom tags are workspace-global rather than object-scoped, which is the same behavior as Novo's tag taxonomy.

Custom fields on Novo tickets require schema discovery before migration because Novo has no published API documentation. We request sample ticket records during scoping to extract the custom field schema, generate a field map, and pre-create each attribute in Intercom via the API before data import. Type conversions (dropdown to text, date format normalization) are handled in the transform layer. Intercom requires custom attributes to exist before data import; we treat attribute creation as a pre-migration step.