Migrate from Deepser to Intercom

Deepser Service Requests map to Intercom Conversations if the request is a simple single-thread exchange, or to Intercom Tickets if the request requires assignment, priority tracking, or SLA management. We use the Deepser category, priority, and status fields to determine the target object type during scoping. The Deepser request description and all threaded comments migrate as Intercom conversation parts or ticket notes. Deepser attachment references (images attached to tickets) migrate as Intercom file attachments on the conversation or ticket.

Deepser Change Requests map directly to Intercom Tickets because both require structured classification, assignment, and status tracking. The Deepser change-type classification (Standard, Minor, Major, Emergency) migrates as a custom attribute on the Intercom Ticket. The change-request approval history migrates as a threaded note on the Intercom Ticket with a timestamp and approver attribution for audit trail continuity.

Deepser Customer records (the requester entities linked to tickets) map directly to Intercom Contacts. The full contact card including name, email, phone, company association, and any custom fields defined on the Customer module migrate as Intercom Contact attributes. We use the email address as the dedupe key. If a Deepser Customer record has no email, we flag it for manual review before migration because Intercom requires an identifier for contact matching.

Deepser Company records function as organizational parent records for Customers and map to Intercom Organizations. The Company name, domain, and any custom fields defined on the Company module migrate as Intercom Organization attributes. We link each migrated Contact to its parent Organization via the Intercom Organization-Contact relationship. The hierarchy is preserved so that Intercom's company-level reporting and segmentation work without manual reassembly.

Deepser IT Assets (hardware and software inventory with serial number, type, location, assigned user, and lifecycle status) map to an Intercom Custom Object we create during migration named Asset. We pre-create the Custom Object schema with custom attributes matching the Deepser asset field names, including a lookup relationship to the Intercom Contact who is the assigned user. Asset lifecycle status values (Active, In Repair, Retired, Disposed) migrate as a custom attribute on the Asset Custom Object.

Deepser Agents (internal users who receive and resolve tickets) map to Intercom Admins (full access) or Teammates (limited access) based on the Deepser agent role. We migrate agent name, email, role, team assignment, and active/inactive status. Deepser's minimum 3-agent requirement on the source side does not apply to Intercom; we map each Deepser agent individually. Inactive Deepser agents migrate as inactive Intercom users who can be activated post-migration if needed.

Deepser Custom Fields module defines additional properties on Tickets, Customers, Assets, and other entities with schemas that vary per installation. We discover the full custom field schema during scoping, map each custom field to an Intercom Contact attribute (for customer fields), Ticket custom attribute (for ticket fields), or Custom Object attribute (for asset fields), and preserve field type fidelity (text, number, date, dropdown, checkbox) during the mapping. Dropdown fields in Deepser migrate as selection options in Intercom custom attributes.

Deepser knowledge base articles (internal or customer-facing content linked to tickets) migrate to Intercom Articles in the Help Center. Article content, categories, and attachment references from the Deepser grid export map to Intercom Article title, body (rich text), and file attachments. We preserve the article category structure as Intercom Collections and Sections. Deepser articles published in multiple languages require the Intercom Help Center multilingual feature which is available on Advanced and Expert plans.

Deepser ITIL-aligned workflows with approval gates, automated tasks, and conditional routing do not migrate as executable code. We document every Deepser workflow step type, trigger condition, and action sequence and deliver a written inventory recommending equivalent Intercom Workflows or Rules for each. The customer or an Intercom partner rebuilds the workflows post-migration. This inventory is part of the standard migration scope delivery.

Deepser SLA records define response and resolution time commitments per ticket priority or category. Intercom's SLA rules (available on Expert plan) define first response and next reply time targets per conversation or ticket. We document each Deepser SLA configuration and map it to an equivalent Intercom SLA Rule specification in the written handoff document. Teams on Intercom Essential or Advanced plans do not have native SLA management and must upgrade or rebuild SLA tracking manually.

Deepser's billing modules track time-based billing entries linked to tickets and assets. Intercom does not have a native billing or time-tracking module. We flag Deepser billing records during scoping and advise whether to migrate them as Notes on the associated Intercom Conversation or Ticket for historical reference, or to exclude them from the migration scope entirely. This decision is made with the customer before migration begins.