Migrate from Novo Help Desk Software to Intercom

Novo Accounts are the top-level tenant representing a customer organization. They map directly to Intercom Companies. We preserve the Account name as the Company name, the primary contact email as a Company admin, and the Account Type designation as a custom Company attribute. Intercom Companies carry a created_at timestamp and a monthly_spend value that we leave blank unless the customer provides revenue data. Companies are created before any Contact migration so that the company_id reference is satisfied at Contact insert.

Novo Contacts are individual end users within an Account who submit and receive tickets. They map 1:1 to Intercom Contacts with email as the dedupe key. We map first_name, last_name, and email directly; phone migrates to Intercom's phone field. Custom fields on Contact records are inventoried during scoping and mapped to Intercom custom contact attributes. If the same email appears across multiple Novo Accounts, we flag this for the customer to resolve before migration since Intercom Contacts are workspace-global rather than account-scoped.

Novo Tickets map to Intercom Conversations. The ticket subject becomes the Conversation title; the ticket description becomes the opening message part. Ticket status (Open, Pending, Resolved, Closed) maps to Intercom's open/closed state and a custom status__c attribute for full fidelity. Priority migrates to a custom priority__c field on the Conversation. The assigned Novo user maps to an Intercom Admin and is resolved by email match against the Intercom workspace User list.

The ticket's initial description becomes the first Conversation Part in Intercom. The author is set to the submitting Contact (via Contact email resolution). Internal-only notes from the original ticket description require flagging during scoping; we preserve these as internal Conversation Parts with the part_type set to 'note' and author set to the assigned agent.

Each reply within a Novo ticket threads into the corresponding Intercom Conversation as a separate Conversation Part. We preserve the part author (agent or contact), the timestamp, and the body. Internal agent notes thread as 'note' type parts while customer replies and agent public responses thread as 'comment' type parts. Ordering is preserved by the created_at timestamp on each part.

Novo file attachments stored against tickets migrate as Conversation Part attachments in Intercom. Files are batched and uploaded via the Intercom attachments endpoint with a max chunk size of 5 MB per file; we track failed uploads and retry within the Intercom file size limits. Attachment filenames and original paths are preserved as metadata on the Intercom side for traceability.

Novo's Activity log entries attached to a ticket represent audit events such as status changes, assignment updates, and SLA clock events. We map these as timestamped Conversation Parts in Intercom with a custom activity_type__c field identifying the event type (assignment_change, status_change, sla_pause, etc.). The activity body migrates as the part body. Activities are ordered chronologically within the Conversation by created_at timestamp.

Novo custom fields on Tickets or Accounts require explicit field-to-field mapping during scoping. We inventory every custom field, capture its data type and sample values, and map each to an Intercom custom contact attribute (for Contact-scoped fields) or a custom conversation attribute (for ticket-scoped fields). Required fields in Intercom are noted; we flag any fields where the data type has no direct Intercom equivalent and propose a transformation strategy.

Novo Account Type is an optional designation indicating service support level (e.g., Gold, Silver, Standard). We preserve this as a custom Company attribute named account_type__c in Intercom, populated from the Account record. The customer defines the allowed values during scoping; we validate that migrated values match the defined list and flag any orphaned values for review.

Active Directory sync is a separate purchase module from Novo Solutions and has no data-layer equivalent in Intercom's standard schema. We do not migrate the AD integration itself. Standard contact fields from AD-sourced records migrate normally as Contact fields. The customer must reconfigure identity provisioning post-migration using Intercom's SCIM 2.0 provisioning, SAML SSO, or manual user management depending on their IdP.