Migrate from Desk365 to Intercom

Desk365 Tickets map to Intercom Conversations. We preserve the ticket subject as the conversation title, Status (Open, Pending, Resolved, Closed) as Intercom's open, closed, and snoozed states, and Priority (Low, Medium, High, Urgent) as a custom attribute in Intercom's ticket_type metadata. Open and closed tickets export cleanly; we apply a date filter if the customer scopes historical imports to a specific window. Conversation parts (public replies and internal notes) migrate as conversation parts ordered by timestamp.

Each Desk365 Ticket contains one or more Conversation records capturing public replies, internal notes, and system-generated status changes. We export all conversation entries in chronological order and reassign them to the corresponding Intercom Conversation as parts. Desk365's Agent-only notes map to Intercom's internal note type; customer replies map to Intercom's public comment type. The author attribution (Agent or Contact) resolves via email lookup in Intercom's Contact table.

Desk365 Customer records (name, email, company association, and portal access status) map 1:1 to Intercom Contacts. Email address serves as the dedupe key. We preserve any custom attributes on the Desk365 customer record as Intercom custom attributes, and we flag any Desk365 customer records that lack an email address so the customer can add them before migration or accept them as contacts with an 'unknown email' designation in Intercom.

Desk365 Agents (display name, email, department membership, role: Admin/Agent, active/inactive status) map to Intercom Admins and Teammates based on the role assignment. Active agents resolve by email match to Intercom user records. Inactive Desk365 agents migrate as deactivated Intercom teammates so that historical ticket attribution is preserved. Department membership maps to Intercom Teams membership after review of the customer's department hierarchy.

Desk365 Departments with configurable access levels (global, department-only, agent-only) map to Intercom Teams for routing purposes. However, Desk365's department-level access control (restricting which agents see which tickets) does not have a direct Intercom equivalent. We replicate the department-to-team association as an Intercom Team, and the customer configures Intercom's Inbox permissions post-migration to approximate the original access model. This is a manual configuration step outside migration scope.

Desk365 Knowledge Base Articles carry publish status (Draft/Published) and visibility flags (public on Support Portal vs. Agent-only). We migrate all articles with their publish status. Desk365's Agent-only visibility has no native Intercom equivalent (Intercom Help Center only supports Published and Draft). We export the visibility flag as a custom attribute on the Intercom article and notify the customer that Agent-only articles will land as Draft and require a manual review before publishing. Article body, categories, and sections transfer as structured content.

Desk365 Tags (flat string labels applied to Tickets for categorization) map 1:1 to Intercom Tags. No hierarchical or color metadata is carried over as most destination platforms use a flat tag model. We extract all unique tag values from Desk365 Tickets and reapply them to the corresponding Intercom Conversations during migration.

File attachments on Desk365 Tickets (and inline in conversations) are stored as URLs pointing to Desk365's blob storage. We download attachments and re-upload them to Intercom as conversation attachments linked to the appropriate conversation part. Intercom restricts certain file types (.exe, .sys, .scr, .shb, .wsf and others) for security reasons. We check the file type list before import and flag any restricted attachments for the customer to handle manually or exclude.

Desk365 supports custom text, number, dropdown, date, and boolean fields on Tickets. We extract field definitions and values, then map them to Intercom custom attributes (string, number, date, boolean, or list type). Dropdown values option-by-option migrate as list values in Intercom. If the destination Intercom workspace already has custom attributes defined, we reconcile schema conflicts before import. We flag any records that reference custom fields not present in the destination so the customer can add them post-migration.

Desk365's 'Type' ticket field carries default values (Question, Incident, Problem, Request) plus any custom types the customer has added. Intercom supports customizable ticket types via the ticket_type attribute but does not enforce a fixed default set. We export the full Type value set from Desk365 and map them to Intercom ticket_type values. If a Desk365 ticket has a custom type not yet defined in Intercom, we flag it for the customer to create before the import phase. This is a pre-migration configuration step that requires the customer's admin to define the type values in Intercom.

Desk365 SLA Policies define First Response and Resolution time targets tied to Priority level and Business Hours schedules. Intercom does not have a native SLA management module in its core product; SLA tracking is available through third-party apps on the Intercom App Store or via manual configuration of SLAs using Intercom's workflow rules. We map SLA Policy names and their time thresholds to a written SLA configuration document that the customer uses to set up SLAs in Intercom manually or through a third-party SLA tool.

Desk365 Premium tier ($32/agent/month) includes IT Asset Management linking hardware/software assets to Tickets. We extract asset records and their linked Ticket associations as a structured CSV export and a written reference document. Intercom does not have a native IT Asset Management module. The customer chooses whether to import assets as custom Intercom contacts (for device records), integrate with a dedicated ITSM tool (ServiceNow, Freshservice), or maintain the asset register in a separate system. This is outside migration scope.