Migrate from OTRS to Intercom

OTRS Tickets map directly to Intercom Conversations. We extract ticket title as conversation subject, ticket state (open, pending, closed) as conversation state, and queue assignment as Inbox routing. Article history migrates as conversation parts in chronological order with sender type preserved (customer, agent, or system). Closed tickets migrate with their full article history; open tickets migrate with a delta run at cutover time. OTRS ticket priority maps to a custom priority attribute on the conversation.

OTRS Articles (emails, notes, external replies) map to Intercom Conversation Parts. Each article body migrates as a part with content-type preserved (plain text or HTML, converted to Intercom's markdown-equivalent format). Sender information from OTRS maps to the part author: OTRS customers become Intercom contacts, OTRS agents become Teammate parts. Attachments on each article migrate as file parts attached to the corresponding conversation part.

OTRS Customer records (with UserID, email, phone, and user preferences) map to Intercom Contacts. The OTRS CustomerID becomes the Intercom contact's external_id for dedupe. OTRS customer type (customer or company customer) determines whether the contact record is tagged as individual or linked to an Intercom Company. Customer preferences and valid/invalid phone flags are preserved as contact attributes.

OTRS Dynamic Fields on tickets are enumerated during scoping, classified by data type (text, integer, date, dropdown, checkbox, multi-select). Text and numeric fields map to conversation metadata tags. Date fields map to conversation custom timestamps. Dropdown and multi-select fields map to conversation tags with the original OTRS field name preserved as tag namespace. We map Dynamic Fields on Customer records to Intercom custom attributes on the Contact object. Fields that have no equivalent in Intercom's schema are flagged as requires-admin-decision items during scoping.

OTRS Queues (ticket routing units with access control and assignment rules) map to Intercom Inboxes. Each OTRS queue name becomes an Intercom inbox name. OTRS queue-level SLA definitions become SLA rules attached to the corresponding Intercom inbox on the Expert plan. Queue assignment rules map to Intercom assignment rules within the inbox. We enumerate all queues during scoping and document the mapping; inboxes that have no direct equivalent are flagged for the customer's admin to configure pre-migration.

OTRS Agent records map to Intercom Teammates. We resolve by email match. OTRS roles and group memberships do not have a direct Intercom equivalent; Intercom's permission model is Inbox-based rather than role-based. We document the OTRS role-to-inbox mapping for the admin to implement post-migration. Agents without an active Intercom account at migration time go into a reconciliation queue for admin provisioning.

OTRS attachments are stored as binary blobs in the database linked to ticket articles. We extract each blob with its original filename and MIME type and import it as a file part on the corresponding Intercom conversation part. Attachments exceeding Intercom's file size limits are flagged for alternative storage and link-sharing. We preserve the original filename in the file metadata for agent reference.

OTRS SLA definitions (response time, resolution time, calendar-linked escalation thresholds) have no direct Intercom equivalent at Essential or Advanced tiers. At Expert tier, Intercom offers SLA rules that can be attached to conversations. We map OTRS SLA names and urgency levels as tags on each conversation, with the SLA threshold time preserved as a custom timestamp attribute. The customer's admin configures formal SLA rules in Intercom's SLA settings post-migration if Expert plan is selected.

OTRS Services define available offerings linked to SLAs and queues. Service definitions migrate as Intercom Help Center articles or as custom attributes on Contacts representing service subscriptions. We export service names, descriptions, and SLA associations and map them to articles grouped by category in Intercom's Help Center. Service catalog ordering and customer-facing portal routing do not have a direct Intercom equivalent and are documented for admin rebuild.

OTRS Configuration Items (CMDB entries with class-based schema) have no direct Intercom equivalent. Intercom Companies are CRM records, not IT asset records. We map CI data to custom attributes on the Intercom Company record where the CI's affected customer maps to a Company. For CIs not associated with a customer (internal infrastructure records), we deliver a written CI inventory document for the customer's admin to evaluate Intercom's custom object options or a third-party CMDB integration. CI-to-Ticket linking is not reconstructable in Intercom without a custom integration.

OTRS Process Management stores workflow definitions as XML with activity nodes, transition rules, and conditional branching. These workflows do not migrate as functional code to Intercom's Workflow Builder because the action models are structurally incompatible. We export the workflow structure (states, transitions, responsible agents, and condition logic) as a written process inventory document. The customer's admin uses this document to rebuild equivalent automations in Intercom Workflow Builder or to implement a third-party workflow integration.

OTRS reporting stores report definitions and rendered output in the database. These are proprietary to OTRS and cannot be directly imported into Intercom's reporting. We deliver a written inventory of existing OTRS report definitions and their parameters so the customer's admin can rebuild equivalent reports in Intercom's reporting dashboard or connect to a BI tool for historical OTRS reporting.