Migrate from OpenText Service Manager to Intercom

OpenText Incidents map to Intercom Conversations in the open state with channel set to the inbound channel (email, chat, or API). The Incident title becomes the Conversation subject, the description becomes the first customer message, and the Incident ID is stored in a custom attribute sm_incident_id__c for traceability. Status (Open, In Progress, Resolved, Closed) maps to Intercom Conversation state. Assignee group maps to an Intercom Team, and individual assignee maps to a Teammate. Priority mapping is stored in a custom attribute sm_priority__c because Intercom does not have a native priority field at the Conversation level on Starter plans.

Service Requests submitted through the OpenText portal map to Intercom Conversations in the same manner as Incidents. The Request ID is preserved in a custom attribute sm_request_id__c. Request fulfillment tasks within Service Manager — such as task assignments and completion steps — do not have an Intercom equivalent and are not migrated; the customer's admin documents the request fulfillment steps during discovery for manual reference or process redesign in Intercom.

Problem records in OpenText have no native Intercom equivalent. Problems are linked incidents that track root cause and known error. We migrate Problem records as Intercom Conversations with a custom attribute sm_problem_flag__c set to true and the linked Incident IDs stored in sm_linked_incidents__c (a comma-separated list). The Problem title, description, and status migrate to the Conversation subject, first message, and state. The customer's admin rebuilds the Problem-to-Incident linkage logic as a tag or custom workflow in Intercom.

Change records with approval stages, risk ratings, and CAB signoff have no Intercom object equivalent. We migrate Change records as Conversations with a custom attribute sm_change_flag__c set to true, carrying the Change ID, status, risk rating, and scheduled implementation date in Intercom custom attributes. The CAB approval logic must be re-implemented manually in Intercom or documented as a process change, as Intercom does not support approval workflows on tickets.

OpenText Knowledge Articles export with title, body (HTML or RTF), author, publish date, status, and category. We strip RTF formatting to clean HTML, preserve article body content, and import into Intercom Articles via the Articles API. Articles are assigned to Intercom Sections and Collections that mirror the OpenText category hierarchy. Draft and published status maps to Intercom's draft/published state. Articles without a category are assigned to a default collection for admin review.

OpenText users with portal access map to Intercom Contacts. We map display name to name, email to email, and department to a custom attribute sm_department__c. Role and group membership are not native Intercom Contact attributes — we store the primary group as sm_primary_group__c and flag admin vs end-user status in sm_user_type__c. OpenText users without email addresses (system accounts, integration accounts) are not migrated to Intercom contacts.

Service Manager stores Contact records for requesters, affected users, and approvers separately from User records. These map to Intercom Contacts using the same name and email mapping logic as User records. Phone number migrates to the Intercom Contact phone field. Company name from Service Manager maps to the Intercom Contact company name and creates a corresponding Intercom Company record.

Service Manager Companies (representing organizations associated with tickets and contacts) map to Intercom Companies. Company name maps to name, domain to website, and industry to a custom attribute sm_industry__c. Company-record associations with Contacts are preserved as Intercom Contact-to-Company relationships via the companies endpoint.

Attachments on Incidents, Requests, Problems, and Changes are exported as binary files with their parent record reference. We re-upload files to Intercom via the attachments API and link them to the migrated Conversation. Attachments on Knowledge Articles are linked to the corresponding Article on import. File size limits on Intercom (25 MB per attachment) are enforced during migration — files exceeding this limit are flagged in the reconciliation report for manual handling.

OpenText administrators can add custom fields to Incident, Request, Problem, and Change records via Studio. We extract the full custom field schema — field name, data type (text, number, date, picklist, boolean), and picklist values — and pre-create matching custom attributes in Intercom before ticket migration begins. Picklist values migrate as custom attribute options. Conditional display rules on OpenText custom fields are not portable and are documented for the admin to re-implement in Intercom Rules or as part of the Fin AI Agent configuration.

SLA definitions in Service Manager define response and resolution targets by priority and category. Intercom SLA targets (Advanced plan) are time-based rules with first_response_time and next_customer_action_time metrics. We document the source SLA targets in a written specification during discovery, and the customer's Intercom admin configures SLA rules in Intercom Admin settings matching the priority levels migrated as custom attributes. SLA breach escalation actions (email notifications, assignee changes) do not migrate and must be rebuilt as Intercom Rules.

Service Manager CI records represent infrastructure assets linked to Incidents and Changes. Intercom has no CMDB equivalent. We map CIs associated with Contacts to Intercom Company records where the CI represents an organization system. CIs representing technical assets (servers, software, network devices) have no Intercom home and are documented in the CI report for the customer's admin to integrate with a dedicated CMDB tool or to store as a tagged attribute on the relevant Contact or Company in Intercom.