Migrate from Alloy Navigator to Intercom

Alloy Navigator Tickets map to Intercom Conversations. Each Alloy ticket ID becomes the external_id on the Intercom conversation for traceability. The Alloy ticket Subject becomes the conversation title (stored as a first message or as a custom conversation attribute). Status mapping requires classification-level review: Alloy allows Status values to vary by classification, so 'Open' in one ticket type may be 'New' in another — we detect all distinct status value sets during discovery and map each to the nearest Intercom conversation state (open, closed, snoozed). Closed ticket body and internal notes migrate as part of the conversation message thread.

Alloy Navigator Contacts map directly to Intercom Contacts using email as the primary key. First name, last name, phone, and custom attributes migrate. The Alloy Contact's linked Organization name and Location hierarchy (e.g., Building > Floor > Room) are flattened into contact attributes or address fields because Intercom has no organizational hierarchy or location tree. We detect duplicate email addresses across Alloy Contacts and flag them for the customer to resolve before migration begins.

Alloy Navigator Organizations map to Intercom Contact company records. The organization's name becomes the Intercom company name, and any organizational custom fields (industry, tier, account manager) become Intercom company custom attributes. Because Intercom's company model is flat (no parent-company hierarchy), any Alloy organizational hierarchy deeper than one level is flagged during scoping.

Alloy Navigator Knowledge Base articles map to Intercom Help Center articles. Article title, body (HTML or rich text), author, and publish status migrate. The Alloy KB category hierarchy maps to Intercom's Collection > Section structure — we flag any Alloy categories with more than two levels of nesting because Intercom caps the hierarchy at two levels (Collection contains Sections, Sections contain Articles). Unpublished or draft articles migrate as drafts in Intercom.

Alloy Navigator Assets (hardware, software, consumables) have no Intercom equivalent. We export the full asset inventory as a structured CSV and JSON deliverable with asset name, type, serial number, assigned contact, purchase date, and cost. The customer's admin uses this as the basis for a separate asset-tracking implementation or to integrate with a dedicated ITAM tool.

Configuration Items and their dependency relationships have no Intercom equivalent. We export CI records and the relationship graph as a structured CSV and JSON deliverable. The customer receives a CI inventory document listing every CI with its type, linked ticket history, and dependency chain.

Work Orders in Alloy Navigator manage scheduled tasks and assignments separate from reactive tickets. Intercom has no scheduled task or work-order model. We export work order records (schedule, assignee, status, completion date) as a structured deliverable and link them to the corresponding migrated tickets where applicable.

Contracts linking Assets, Contacts, and Licenses with renewal dates and terms have no Intercom equivalent. We export contract metadata (contract ID, type, start/end dates, linked asset references) as a structured deliverable. Multi-document contracts with binary file attachments are exported with file references noted for manual re-attachment.

Software license compliance, seat counts, and entitlement data have no Intercom equivalent. We export license details (product name, seat count, purchase date, expiry, compliance status) as a structured CSV. The customer uses this as input for a dedicated software asset management tool.

Alloy Navigator ITIL Workflows with approval chains, escalations, and Create Actions have no direct Intercom equivalent. Intercom's Rules engine handles routing and auto-assignment but does not model ITSM approval workflows. We export a written inventory of every active Alloy Navigator Workflow: trigger conditions, approval steps, escalation rules, and associated Create Actions. The customer's admin reviews this inventory and rebuilds routing logic as Intercom Rules post-migration.

Alloy Navigator's hierarchical Location tree (Sites containing Buildings containing Floors containing Rooms) cannot map directly to Intercom's flat contact address model. We flag location tree depth during discovery. For trees up to three levels deep, we concatenate the full path as a string attribute (e.g., 'HQ / Building A / Floor 3 / Room 312'). For deeper trees, we preserve the top three levels and document the remainder for manual entry.

Alloy Navigator Users and Technicians map to Intercom Admins or Teammates based on role. We extract user email, name, team assignment, and role from Alloy Navigator and map active technicians to Intercom seats. Inactive Alloy Navigator users are exported with their inactive status for the customer's admin to review before provisioning Intercom seats.