Migrate from Mojo Helpdesk to Intercom

Mojo Tickets map to Intercom Conversations. The Mojo ticket subject and full message history (all Comments ordered by timestamp) migrate as Conversation Parts. We preserve the original ticket status (New, Open, Pending, Resolved, Closed) by mapping to Intercom's Conversation State (open, closed). The original ticket ID is preserved in a custom conversation attribute mojo_ticket_id for audit reference. Any Mojo ticket priority (Low, Normal, High, Urgent) maps to a custom Intercom conversation attribute priority_level since Intercom's base model does not have a native priority field.

Every Mojo Comment — agent replies, customer responses, and CC'd participants — migrates as an Intercom Conversation Part with the correct author attribution. Mojo internal staff notes (marked as private within Mojo) map to Intercom's private Conversation Parts (part_type=note) so that internal commentary is preserved separately from customer-visible messages. Comment ordering is preserved by setting the created_at timestamp to the original Mojo Comment timestamp. The parent ticket's created_at timestamp maps to the Conversation's created_at.

Mojo agent users map to Intercom Admins (if Mojo role is Admin) or Operators (if Mojo role is Agent). We resolve agents by email match. Mojo agent permissions scoped to specific queues require mapping to Intercom's Team-based access model — agents assigned to a Mojo queue map to the corresponding Intercom Team, and Inbox assignment rules are reconstructed in Intercom using Teams. The Mojo agent's created date and last login migrate as custom attributes.

Mojo Contacts migrate to Intercom Contacts. The Contact's email is the dedupe key. Company affiliation (Mojo Contacts linked to a Company) maps to an Intercom Contact attribute mojo_company_name and, if a matching Intercom Company exists, we link via the standard company association. Phone, custom attributes, and contact type migrate as Contact attributes.

Mojo Company records (available when Contacts are linked to companies) map to Intercom Companies. Company name, domain, and industry migrate directly. The Mojo Company ID is preserved in a custom Intercom Company attribute mojo_company_id for cross-reference.

Mojo Queues are routing units that tickets land in based on email routing rules or form submissions. Intercom does not have a Queue object — routing happens via Inbox assignments and Team membership. We map each Mojo Queue to an Intercom Team, and Mojo queue-level routing rules are documented as an Intercom Workflow and routing rule configuration plan. If the customer uses queue-specific email addresses (e.g., [email protected] and [email protected] routing to different queues), we document the email forwarding setup to configure as Intercom Inbox email routes.

Mojo Tags applied to tickets migrate to Intercom Inbox Tags. Mojo's free-form tag text maps directly. We preserve tag application on the Conversation during migration so that tag-based reporting can be reconstructed in Intercom. Note that Mojo tags have no predefined taxonomy, which is also true of Intercom tags — both are flat string lists, so the mapping is straightforward.

Mojo ticket custom fields migrate as Intercom custom conversation attributes. Before migration, we validate that each custom field in Mojo has been pre-created (the Mojo prerequisite documented in the source page) and then map the field type: Mojo text fields become Intercom string attributes; picklist fields become Intercom string or enum attributes with the same allowed values. The mapping is documented in the pre-migration schema inventory. Intercom Starter limits custom attributes per conversation; we flag attribute count against the destination plan during scoping.

Mojo user custom fields migrate as Intercom Contact custom attributes. The same pre-creation validation applies. Mojo text, date, and picklist user fields map to equivalent Intercom Contact attribute types. These attributes do not count against Intercom's conversation attribute limits.

Mojo Knowledge Base Articles export as content with publish status, categories, and article body (HTML). We migrate articles as Intercom Help Center articles within the appropriate collections and sections, preserving the original category hierarchy from Mojo. Publish status carries over — draft articles in Mojo become draft articles in Intercom's Help Center. Article-to-ticket recommendation links (Mojo's knowledge base suggester) are documented but do not have a migration path in Intercom since that feature is handled by Fin AI Agent's answer-base configuration, which is a separate setup step.

Mojo SLA definitions (timeframes per priority level, pause-on-reply logic, breach alerts) are migrated as configuration documentation. Intercom's SLA policies are a Pro plan feature and must be rebuilt manually in Intercom's SLA policy editor. We deliver a written SLA mapping document specifying each Mojo SLA rule, its priority conditions, time thresholds, and the equivalent Intercom SLA policy configuration. SLA breach historical data does not migrate — Intercom SLA policies are forward-looking.

Mojo canned responses associated with queues or categories migrate as Intercom Saved Replies. Template body content and trigger conditions (Mojo's shortcut triggers) are preserved in the migration inventory. Saved Replies in Intercom are workspace-wide, not queue-scoped, so any queue-specific language or branding in canned responses should be reviewed post-migration for cross-queue applicability.

Mojo's optional Asset Management module tracks physical assets (laptops, software licenses, warranties, contracts) linked to ticket history. Intercom has no asset management module. Asset records are exported as a CSV inventory with ticket linkage, and the customer is notified to evaluate an asset management tool (ServiceNow Asset Management, Salesforce Field Service, or a dedicated CMDB) as a separate implementation. We preserve the asset-to-ticket linkage as a documented reference in the migration handoff.

Mojo bots trigger on ticket events (created, updated, deleted) and perform assign, escalate, or email actions. Intercom Workflows are event-triggered automation with a different action model. We document every Mojo bot trigger, conditions, and actions in a written automation inventory. The customer's Intercom admin rebuilds these as Intercom Workflows post-migration. We do not migrate bots as code because the trigger-action logic is platform-specific and requires reimplementation.