Migrate from Incident IQ to Intercom

Incident IQ Tickets map to Intercom Conversations. We extract ticket fields (status, priority, assignee, category, description, created_at, updated_at) and convert them to conversation attributes. The original ticket ID is preserved as a custom attribute ticket_original_id for cross-reference. Intercom's conversation has no direct equivalent to Incident IQ's category, campus, or custom ticket field taxonomy—these require remapping to Intercom custom attributes or tags during migration. Active and closed ticket status maps to open and closed conversation state in Intercom.

Incident IQ staff users map to Intercom Users. We match by email address and preserve name, role, and campus assignment. Role mapping is partial: Incident IQ agent and admin roles map to Intercom's agent and admin roles, but Incident IQ's K-12-specific role categories (technician, librarian, facilities staff) do not have direct equivalents and may require custom Intercom team designations or user segments post-migration.

Incident IQ users who are students or parents map to Intercom Contacts. We extract name, email, and associated campus (stored as a custom attribute campus_assignment). Phone numbers migrate as contact attributes, but Intercom validates phone number formats during import—if number validation is enabled in the workspace, we recommend disabling it before migration to avoid rejections on records with non-standard formats.

Incident IQ Campus records map to Intercom Teams, but the mapping is conceptual rather than 1:1. Intercom Teams are routing units for inbox assignment, not geographic hierarchies. We create Teams that correspond to Incident IQ campuses and use them to assign Conversations to the correct team during migration. If Incident IQ has nested location hierarchies (building, floor, room), the nested structure does not transfer; we flatten to the top-level campus team.

Incident IQ Knowledge Base articles migrate to Intercom Articles. We preserve title, body content, categories, and any associated metadata. Articles attached to specific tickets include a reference note that the ticket-to-conversation mapping is preserved. Articles with embedded links to Incident IQ tickets will need redirect updates after migration—we flag each reference in the data map.

Incident IQ Assets (Chromebooks, laptops, projectors, and every tracked device) have no equivalent object in Intercom. We do not migrate Assets as a standalone record type. We extract asset-to-user assignments and asset tag data and store them as custom contact attributes on the corresponding Incident IQ User record (now an Intercom Contact or User), so device assignment context is preserved as reference data even though the full asset record does not transfer.

Incident IQ model categories (Chromebooks, Laptops, Projectors) are an organizational taxonomy that does not exist in Intercom. We extract model category assignments and store them as a multi-select attribute on the related Contact or User record. The customer may also choose to create Intercom tags for device type tracking post-migration.

Incident IQ Support Flows (automation chains that route tickets, assign agents, and trigger actions) do not migrate as code. We extract the Support Flow logic—triggers, conditions, routing rules, and actions—and document it in a written inventory with recommended Intercom Rule equivalents. The customer's admin rebuilds these in Intercom's Rules engine post-migration. Active flows that need rebuild are flagged by name and complexity tier in the data map.

Incident IQ custom fields on tickets (dropdown, text, number, date) migrate to Intercom custom conversation attributes. We apply type conversions: dropdown becomes a text attribute (Intercom does not have a native dropdown type for conversation attributes), multi-select becomes a comma-separated text attribute, and date fields become ISO timestamp attributes. The original custom field label is preserved in the attribute description.

Incident IQ Facilities Work Orders are a K-12-specific object with no equivalent in Intercom. We extract Work Order records as a structured JSON export and include them in the data map as a separate export file. Intercom does not have a work order, maintenance ticket, or facilities request object, so these records cannot be migrated into the platform. The customer should evaluate whether these records require long-term audit retention and whether a separate facilities management tool is needed post-migration.