Migrate from iTop to Intercom

iTop UserRequest tickets map to Intercom Conversations. We export the ticket log as a chronological list of messages, preserving the author (caller, agent, assignee), timestamp, and message body. Each message becomes an Intercom conversation_part. The iTop ticket title maps to the Conversation subject or first message; the final iTop ticket status (Open, Resolved, Closed) maps to Intercom's open, resolved, or snoozed state. Assignment from iTop agent_id resolves to the Intercom teammate who owns the conversation.

iTop Incident records, which extend Ticket with caller, impacted_ci, and assignment fields, map to Intercom Conversations using the same message-thread structure as UserRequest. The impacted_ci reference does not have a direct Intercom equivalent; we preserve it as a custom conversation attribute (impacted_ci_name) so that internal teams retain the context during migration. Incident priority maps to a custom priority attribute on the Conversation.

iTop Contact records with person details (name, email, phone, organization membership) map to Intercom Users. Email is the dedupe key. The iTop organization_id resolves to an Intercom Company record that we create before User import so that the company link is satisfied at insert time. Any custom contact fields in iTop (extended via XML) become Intercom custom attributes on the User.

iTop Organization records map to Intercom Companies. The organization name becomes the Company name, and the organization_code maps to company_id if present. Parent-child organization hierarchies in iTop map to Intercom Company parent-child relationships where supported. Organization contacts are linked via the Company-User relationship after both objects are created.

iTop ChangeRequest objects have no Intercom equivalent because Intercom has no structured change management or approval workflow engine. We export ChangeRequest records as Intercom Custom Objects (if the customer's Intercom plan supports them) with fields for change type (normal, urgent, emergency), approval status, and rollback plan stored as custom attributes. Alternatively, we document the full ChangeRequest inventory as a CSV handoff for the customer's admin to review in the context of their new support model.

iTop CI records (Servers, Network Devices, Applications, Databases) have no direct Intercom equivalent. Intercom is a support and engagement platform, not a CMDB. We export CI records as Intercom Custom Objects where the customer has Advanced or Expert tier, or we document CI data in a separate CSV that the customer retains for IT operations reference. We flag which CIs are linked to migrated tickets so that affected CI names appear in conversation notes if needed.

iTop Service catalog entries map to Intercom custom attributes on Conversations (service_name) or to Intercom Topics if the customer uses topic tagging to classify inbound requests. Service hierarchies in iTop (parent service with subcategories) do not carry over directly; we recommend reviewing the service taxonomy post-migration and structuring Intercom Topics to match the support scope.

iTop SLA definitions with response-time and resolution-time targets and escalation matrices do not migrate to Intercom. Intercom Advanced and Expert tiers support SLA metrics tracked against inbox views, but these require manual configuration on the destination. We export SLA configurations as a structured JSON document and deliver it alongside the migration so the customer's admin configures Intercom SLA rules against the new conversation data.

iTop Knowledge Base and FAQ articles map to Intercom Help Center articles. Article title, body content, and author preserve. iTop article categories require review and re-mapping because Intercom organizes articles into Collections. We export the full article content in structured format and deliver a category-to-collection mapping plan for the customer to implement in Intercom's Help Center settings. Articles under 100 words may increase AI hallucination risk for Fin; we flag short articles for review before AI training.

iTop attachments linked to tickets (UserRequest, Incident) export as raw files from the local file system path. We re-upload files to Intercom's hosted attachment storage during import, replacing the local file URL references that become invalid after the on-premise to SaaS transition. Attachment metadata (filename, size, linked object, linked CI) preserves in the conversation as a file attachment. File re-upload is chunked to avoid Intercom API payload limits on large binary files.

iTop custom classes defined via XML extensions (custom_itop_class) map to Intercom Custom Objects where the destination plan supports them. Each custom class schema must be reviewed individually during scoping because iTop custom objects vary widely between instances. We pre-create the Intercom Custom Object schema with matching attribute names and types before importing any data. Intercom's Custom Objects are available from Advanced and Expert plans; Essential tier does not support them.

iTop user accounts (login, profile, role assignments) export as account metadata for manual recreation in Intercom. Direct credential migration is not supported due to password hash incompatibility between iTop's PHP-based authentication and Intercom's SaaS identity model. We export a user-role matrix showing each iTop profile, its assigned roles, and the recommended Intercom teammate role and permissions for the customer's admin to provision during setup.