Migrate from Ivinex to Intercom

Ivinex Contacts Tab maps to Intercom Contact. Standard name, email, and phone fields migrate directly. Ivinex custom fields on the Contacts Tab become Intercom custom attributes, which we pre-register via the Intercom Custom Objects API before import. Phone number validation in Intercom may reject malformed numbers — we disable validation in Settings > Your Workspace > People Data > Phone before migration begins.

Ivinex Organizations Tab maps to Intercom Company. The Organization name becomes the Company name field. We resolve any Ivinex Contact-to-Organization LinkRecords during import and create the Intercom Company-Contact relationship via the contacts[company_ids] attribute on the Contact import payload.

Ivinex Ticket records map to Intercom Conversations of type ticket. The Ticket title becomes the Conversation subject, Ticket status maps to a Conversation state (open, closed, snoozed), Ticket priority maps to Intercom Ticket Priority attribute, and Ticket assignee maps to the Intercom Conversation assignee. Custom fields on the Ivinex Ticket Tab become Ticket custom attributes in Intercom.

Ivinex Task records with due dates and assignees migrate to Intercom as Tasks linked to the parent Contact or Company. We resolve the Ivinex task assignee to the corresponding Intercom teammate by email match. Tasks without a parent Contact or Company are linked to the associated Ticket-Conversation or held in a reconciliation queue.

Ivinex call logs attached to a Contact via GetAllRelatedItems migrate to Intercom as Conversation Parts on the associated Contact conversation. Call duration and disposition from Ivinex custom fields become custom attributes on the migrated Part. We preserve the original call timestamp as the Part created_at date.

Ivinex email engagements migrate to Intercom Conversation Parts with author type set based on the email direction (inbound = user, outbound = admin). Email body content migrates as Part body with any attachments uploaded separately to Intercom and linked via the Part attachment reference.

Ivinex Notes attached to Contacts or Organizations migrate to Intercom as Conversation Parts on the most recent Contact conversation, or as standalone Contact Notes if no conversation exists. We preserve the Note body, author, and created date.

Ivinex User records map to Intercom Teammates. We match by email address. The Ivinex user role (active/inactive) maps to the Intercom teammate active status. Inactive Ivinex users are imported as inactive Intercom teammates so that historical owner assignments on Tickets and Tasks resolve correctly.

Ivinex custom field types (text, number, date, dropdown, checkbox, user-link) map to equivalent Intercom attribute types. Dropdown fields in Ivinex with predefined options map to Intercom select custom attributes with matching option values. We call GetFields on every Tab before data extraction to capture the live field list — skipping this step means bulk exports may omit columns or misalign data with field positions. Intercom custom object attributes are registered via Settings > Data > Custom Objects before migration.

Ivinex GetRecords returns attachment metadata including download URLs but not inlined binary content. We extract all attachment URLs in a first pass, then execute parallel downloads in a second pass and re-upload files to Intercom via the Conversations attachments endpoint. Attachment URL validity may expire; we log any failed downloads for manual retrieval and note that files over 20 MB should migrate via a dedicated post-ETL file transfer to Intercom's file storage.

Ivinex automation rules in the process automation module are exported as structured JSON describing trigger, conditions, and actions. Intercom Workflows use a conversation-level trigger model that is architecturally different from Ivinex's process automation. We deliver a written inventory of every Ivinex workflow with its trigger, conditions, and actions, plus a recommended Intercom Workflow equivalent for the customer's admin to rebuild. This is not a code migration — visual builders do not transfer between platforms.

Ivinex Saved Views define which fields and filters are shown per Tab. These are user preferences, not data. We preserve view names and filter criteria so the customer's admin can rebuild them as Intercom Inbox filters and assignment rules. Ivinex Views that reference custom fields require the corresponding Intercom custom attributes to exist first, so we coordinate the rebuild handoff to post-migration.