Migrate from Matrix42 Service Management to Intercom

Matrix42 Incidents migrate to Intercom Conversations with status mapped to Intercom's open, resolved, and closed states. The Matrix42 incident priority (P1-P4) maps to Intercom conversation priority (urgent, high, medium, low). Original incident timestamps (created_at, updated_at) preserve on the Intercom conversation. The Matrix42 incident description and resolution notes migrate as Intercom conversation parts. CI bindings are dropped; the customer admin can tag conversation topics or create custom attributes for asset context post-migration.

Matrix42 Service Requests migrate to Intercom Conversations with the same status and priority mapping as Incidents. Request type categories from Matrix42 (hardware provisioning, access requests, etc.) migrate as Intercom conversation tags for reporting parity. Approval chains on Matrix42 requests are documented as a written handoff; Intercom does not have a native approval workflow feature and requires a manual process or third-party integration for approval-gated requests.

Multiple Matrix42 Incidents linked to a single Problem record merge into one Intercom Conversation per Incident, with a custom attribute problem_link__c carrying the original Matrix42 Problem ID for traceability. If the customer requires Problem tracking as a separate entity, we recommend Intercom's topics or a custom object via Intercom's Ruby on Rails extension layer; this is documented during scoping.

Matrix42 Change records migrate to Intercom Conversations tagged with 'change-request' for identification. Risk classification (standard, normal, emergency) from Matrix42 becomes a custom conversation attribute change_risk_level__c. CAB approval status is documented in the conversation body; Intercom does not have a native Change Advisory Board workflow. Emergency changes require a separate written runbook for the admin to recreate as an Intercom workflow or Rules action.

Matrix42 Configuration Items (services, software, devices, and their consumers) do not have a direct Intercom equivalent. We extract CI data relevant to active tickets (the CI currently linked to open Incidents or Service Requests) and migrate it as Intercom conversation custom attributes (ci_type__c, ci_name__c, ci_id__c). The full CMDB graph is not migrated; we deliver a written CI inventory for the customer's admin to assess which asset context is worth preserving as Intercom contact attributes or segments.

Matrix42 KB articles migrate to Intercom Articles within Collections. Article title, body content (preserved as HTML), publication status, and category assignments map directly. Matrix42 article attachments migrate as Intercom article attachment files uploaded to the article. Intercom Collections serve as the equivalent of Matrix42's Knowledge Base categories. If Matrix42 KB articles reference CI-specific troubleshooting steps, we tag the Intercom article with the relevant topic or product for routing.

Matrix42 SLA definitions (reaction time, resolution time, escalation rules, calendar bindings) migrate to Intercom SLA Policies. Priority-to-SLA tier mapping is configured during scoping: Matrix42 P1 maps to Intercom's fastest SLA clock, P2 to medium, P3 and P4 to longest or best-effort. We configure SLA Policies in Intercom Admin before ticket import so that SLA clocks begin running on migrated conversations. Calendar bindings require Intercom Business Hours configuration to match the Matrix42 service calendar.

Matrix42 Service Catalog entries (offerings with approval chains and fulfillment processes) do not have a native Intercom equivalent. We deliver a written inventory of every active Service Catalog item with its workflow binding, approval chain, fulfillment type, and associated SLA. The customer's admin rebuilds these as Intercom Outbound Messages, Product Tours, or Workflows (bot-triggered sequences) post-migration. Service Catalog item usage frequency is included in the inventory to prioritize rebuild order.

Matrix42 user accounts (agents, approvers, and requesters) migrate to Intercom Users and Teams. Agent roles (1st-level support, 2nd-level support, escalation manager) map to Intercom Team assignments. Matrix42 role-based access does not translate directly to Intercom's agent permission model (admin, agent, viewer); we document the role mapping during scoping so the customer's Intercom admin configures permissions after migration. Requester (end-user) contacts migrate as Intercom contacts if they appear in ticket history.

Matrix42 workflows built on the Worker Engine (version 10.0.0 and above) are not migrated as executable code. We audit all active workflows, document their trigger conditions, activity sequences, approval gates, and SLA bindings, and deliver a written workflow inventory. The customer's admin rebuilds critical workflows as Intercom Rules (inbox routing, assignment, tag actions) or Workflows (multi-step bot sequences). Workflows built on the legacy Service Store 5.x format are flagged separately because they require the Matrix42 Workflow Migration tool before any export is possible.

Ticket attachments (images, documents) and KB article attachments migrate to Intercom conversation part attachments and article file attachments respectively. We extract binary blobs from Matrix42's document repository, preserve original filenames and sizes, and upload to Intercom's file storage during migration. Files exceeding Intercom's 10 MB per-file limit are flagged for the customer to host externally and link.