Migrate from UserHorn to Intercom

UserHorn contacts migrate to Intercom Users. Every contact requires an email address or user_id to associate with a conversation — contacts without either must be resolved before migration or archived as a separate JSON export for reference. The role attribute determines whether a record is a user or lead in Intercom. We deduplicate by email during import to prevent duplicate contacts.

UserHorn companies map directly to Intercom Companies. Company is created before any related contacts so that the Company relationship is satisfied at the moment of contact import. We use company domain or name as the dedupe key. If UserHorn supports company-domain extraction from contacts, we use that for automated Company creation.

UserHorn tickets migrate to Intercom Conversations (the default) or Tickets mode depending on the customer's preference. Each ticket thread becomes a conversation with message-level history. The assignee, status, priority, and custom fields transfer. If UserHorn stores messages as a separate table, we sequence them by timestamp and insert into the conversation in order. Closed tickets migrate with a delta-date cutoff to avoid reopening resolved conversations during final sync.

UserHorn agents map to Intercom Teammates. We match by email. Agent groups map to Intercom Teams. If the destination Intercom workspace does not have the corresponding Teammates provisioned, we hold the assignee mappings in a reconciliation queue and populate them after the admin provisions the users.

UserHorn custom objects migrate to Intercom Custom Objects if UserHorn exposes them via API. Intercom Custom Objects are stored and queryable via API but are only directly visible in the Intercom UI within bot flows — they do not appear in the standard People, Company, or Conversation views. We advise customers during scoping whether custom object visibility in Intercom's UI meets their use case.

UserHorn knowledge base articles migrate to Intercom Help Center Articles. We map the existing category structure to Intercom's Collection > Section > Article hierarchy. If UserHorn uses a two-level hierarchy, we create the articles under a Section within a Collection. If it uses a single level, we create a Collection and place articles directly under it. Intercom allows article creation without a section, which simplifies two-level sources.

UserHorn custom fields migrate to Intercom Data Attributes, which attach to Users and Companies. We pre-create Data Attributes in Intercom before importing any contacts or companies. Attribute types (string, number, date, boolean, list) are matched to Intercom's attribute type system. If a UserHorn attribute is a multi-select, we create it as a list attribute in Intercom.

UserHorn ticket attachments migrate to Intercom conversation attachments. We reattach files directly in Intercom with no external references. Inline images within message bodies are preserved. Files must be downloaded from UserHorn and re-uploaded to Intercom's storage during migration.

UserHorn Workflows and Automation Rules do not migrate to Intercom as code because the two platforms use fundamentally different rule engines. We deliver a written inventory of every active UserHorn workflow with its trigger, conditions, and actions, plus a recommended Intercom Rule or Workflow equivalent. The customer's admin rebuilds these in Intercom post-migration. This is standard scope.

UserHorn outbound campaigns and sequences do not migrate. We disable active automated email campaigns in the UserHorn account before migration begins to avoid API rate-limit consumption during the import window. We deliver a written inventory of each campaign for the admin to rebuild in Intercom Outbound or via a dedicated sales engagement tool if the customer uses a separate cadence platform.