Migrate from Usedesk to Intercom

Usedesk Tickets map to Intercom Conversations. The original message thread, including internal notes and public replies, migrates preserving sender, recipient, timestamp, and message body. Ticket status (open, pending, resolved, closed) maps to Intercom Conversation state. Assignee from Usedesk resolves to an Intercom Team Member by email lookup. Channel metadata (email, chat, social, messenger source) is stored as a custom conversation attribute since Intercom does not expose channel type as a distinct object field.

Usedesk Client records map to Intercom People. Email, name, phone number, and contact metadata migrate directly. Custom client properties migrate to Intercom custom attributes, which must be pre-created in the Intercom workspace before migration runs because Intercom's API rejects attributes that are not defined in the workspace. Phone number formats are normalized during transformation; if Intercom phone validation is enabled and the format does not match E.164, we request the customer disable phone validation in Settings > Workspace > People Data > Phone before migration.

Usedesk Agents map to Intercom Team Members. Resolution is by email address. Any Usedesk Agent without a matching Intercom user account goes to the reconciliation queue for the customer's admin to provision before record import. Role and permission parity is not 1:1; Usedesk role definitions (admin, agent, supervisor) require manual reassignment in Intercom Admin settings post-migration, and we flag the gap in the validation report.

Usedesk supports up to 20 channel types (email, live chat, social media, Telegram, WhatsApp, and others). Intercom does not expose channel type as a distinct object; instead, channel metadata is stored as a custom conversation attribute that we create during migration setup. The original channel label from Usedesk is preserved in this attribute so that teams can filter conversations by source channel in Intercom's inbox view.

Usedesk Knowledge Base articles migrate to Intercom Articles within the Help Center. Article content, categories, and publication status transfer directly. Article-to-ticket linking (Usedesk's internal article references within tickets) is not preserved as a native link in Intercom; we document each linked article pair in the migration report for the customer to recreate manually. If the Usedesk knowledge base spans multiple languages, the customer must add the corresponding languages in Intercom Help Center settings before migration so that imported translations map correctly.

Usedesk ticket tags migrate as flat labels in Intercom. Where Usedesk uses hierarchical tag structures, we flatten to a single label string with path separators preserved so that the customer can reorganise into Intercom's topic-based taxonomy post-migration. Labels migrate as part of the Conversation record.

File attachments embedded in tickets or knowledge base articles migrate to Intercom's file storage with links preserved in the record. Oversized files (above Intercom's 10 MB per file limit) are flagged early in scoping. If the Usedesk attachment count is large or files are stored outside the primary ticket export, we run a separate attachment pass to avoid API timeout during the main migration window.

Usedesk automation rules (triggers, conditions, and chained actions) are exported as structured JSON in our discovery pass but cannot migrate as executable code to Intercom because the automation engine semantics differ. We deliver a written inventory of every Usedesk automation with its trigger, conditions, actions, and the nearest equivalent Intercom Workflow step. The customer's admin rebuilds each automation in Intercom Admin > Workflows post-migration. Fin AI Agent configuration is documented separately as it requires knowledge base content to be live in Intercom before setup.

Usedesk custom fields on Tickets are account-specific with no public schema registry. We discover each custom field during the pre-migration data audit, then create the equivalent custom conversation attribute in Intercom before migration runs. Custom field value types (text, number, date, dropdown) are mapped to Intercom attribute types. Any custom fields without a clear Intercom equivalent are flagged in the mapping document for the customer to decide whether to drop, consolidate, or store as a custom text attribute.

Usedesk custom fields on Client records are discovered during the data audit and mapped to Intercom custom People attributes. These must be pre-created in Intercom workspace settings before the migration run because Intercom's API rejects People records with undefined custom attributes. Email opt-in and opt-out preferences from Usedesk migrate to Intercom's HasOptedOutOfEmail standard attribute to maintain compliance flags.