Migrate from OpenText Service Request Center (SRC) to Intercom

SRC Service Requests map to Intercom Conversations. The mapping preserves the request category as a custom conversation attribute (src_category), the requester name and email as the conversation contact, and the request status mapped to Intercom's open, closed, or snoozed state. Priority and urgency fields from SRC become custom attributes (src_priority, src_urgency). All SRC Service Request text, including description and resolution notes, migrates as conversation parts. The conversation is created via the Intercom API with the customer as the originating message so it appears in the correct inbox.

SRC Incidents map to Intercom Conversations separately from Service Requests. We preserve the incident-impact and incident-urgency fields as custom attributes (src_impact, src_urgency), and the incident-number as a read-only attribute for traceability. Incidents that are linked to other Service Requests in SRC via a parent-child relationship are represented in Intercom as separate conversations with a custom attribute (src_parent_incident) linking them. If the destination workspace uses Intercom Tickets for structured tracking, Incidents map to Tickets with status mapped to Ticket state.

SRC external requesters (Customers) map to Intercom Contacts. We extract customer name, email, phone, department, and any contact custom fields and create matching Intercom Contact records. Email is used as the dedupe key. If a Contact already exists in Intercom, we merge the SRC customer attributes into the existing record rather than creating a duplicate.

SRC internal agents (Users) map to Intercom Team Members. We extract display name, email, department, and group memberships. Group memberships in SRC inform the mapping to Intercom Teams (Inboxes). We resolve each SRC User by email against the Intercom workspace's team member list. If a matching Team Member does not exist in Intercom, we add the user to a reconciliation queue for the customer's admin to provision before record import.

SRC KB Articles map to Intercom Knowledge Hub articles. Articles are associated with Collections that we create to mirror the SRC knowledge base category hierarchy. A sanitization step converts HTML content to markdown-compatible format, stripping embedded images (which migrate as separate ContentDocument records), tables, and non-standard markup. Articles that cannot be cleanly converted are flagged for manual review. The original article-author and article-created-date migrate as article metadata.

SRC SLA definitions (calendar-based response and resolution targets tied to priority and service category) cannot be migrated as code to Intercom. Intercom SLA policies are simpler: they define response time and resolution time targets per SLA tier without calendar-specific business hours. We audit every SRC SLA definition during discovery, document the calendar hours, holiday schedule, priority mapping, and target values, and deliver a written SLA specification that your Intercom admin uses to create equivalent policies. SLA target achievement is not automatically enforced post-migration.

Attachments on SRC Service Requests and Incidents migrate as Intercom conversation attachments linked to the migrated conversation. We resolve inline file attachments (stored within SRC's document management) by retrieving the binary file and attaching it to the corresponding Intercom conversation part. External file references pointing to OpenText Content Suite or other repositories require separate resolution: we either retrieve the file via the external system's API or document the broken reference for manual handling. Files that cannot be retrieved are flagged as missing post-migration.

SRC support groups and team assignments map to Intercom Teams. We export group names, email routing aliases, and membership lists and recreate them as Intercom Teams. Group-to-team mapping informs conversation routing during migration. If SRC routing rules assign requests to groups based on offering or category, we document those rules for recreation as Intercom Rules.

SRC custom fields on Service Requests and Incidents map to Intercom custom conversation attributes. We audit the SRC custom field schema during discovery: field name, data type, picklist values, and validation rules. Text fields map to Intercom text attributes; numeric fields to number attributes; date fields to date attributes; picklists to list attributes. Intercom does not support all SRC data types (for example, multi-reference fields and complex validation rules). We flag unsupported field types and recreate them as closely as possible with a documented gap list for manual cleanup.

SRC workflow definitions are tightly coupled to the platform's internal process engine and are not exportable in a portable format. We document the logic of each active SRC workflow: trigger conditions, stages, assignments, notifications, and escalation actions. This documentation is delivered as a written workflow inventory with recommended Intercom Rule equivalents. Your admin rebuilds the rules in Intercom's Rules engine post-migration. Service catalog items and request offerings similarly are not migrated as structured records; we extract catalog item metadata for manual recreation in Intercom.