Migrate from Deskero to Intercom

Deskero Tickets map to Intercom Conversations with thread content mapped to Part records. Each channel (web, email, chat, social) produces a separate Part using Intercom's part_type system: comment for customer messages, note for agent internal comments, and activity for system events (status changes, assignments). The Deskero ticket subject becomes the Conversation title, and created_at timestamps preserve the original ticket creation date across both created_at and updated_at fields in Intercom.

Deskero ticket status values (Open, Pending, Solved, Closed) map to Intercom Conversation states (open, snoozed, closed). We create a mapping table during scoping that resolves each Deskero status string to its Intercom state equivalent. Deskero's Pending status maps to Intercom's snoozed state with a snooze_until timestamp derived from any SLA deadline field if present.

Deskero Customer records map to Intercom Contacts. We map standard fields: name, email, phone, and company association. The Deskero Preferred Client boolean flag migrates as a custom Contact attribute is_preferred_client__c. If the Deskero export provides a company name without a separate Company object, we resolve it against the Deskero company field on the Customer record and create a corresponding Intercom Company record with a lookup back to the Contact.

Deskero custom fields defined on the Customer object map to Intercom Contact custom attributes using Intercom's custom_attributes key-value schema. Since Deskero allows independent custom field definitions on Ticket and Customer objects, we inventory both sets during scoping and consolidate them into Contact attributes where they overlap in meaning, flagging any field collisions for customer resolution before import.

Deskero custom fields defined on the Ticket object map to Intercom Conversation custom attributes. These do not map to Contact attributes because Intercom's model separates conversation-level metadata from contact-level data. We use Intercom's custom_attributes field on the Conversation object to store the full set of Deskero ticket custom field values as key-value pairs.

Deskero Knowledge Base articles map to Intercom Help Center articles. Article titles, body content (HTML or Markdown), and publish status transfer directly. The Deskero category hierarchy may not export in machine-readable form with parent-child relationships — we request a sample export during scoping, and where hierarchy is absent, we rebuild the category tree manually from the article content and customer guidance. Internal links between articles are rewritten to point to the new Intercom article URLs during import.

Deskero KB categories map to Intercom Help Center Collections. We create a Collection for each Deskero category and assign articles to Collections during import. If the Deskero export does not include category hierarchy metadata, we use the flat category labels exported with articles to create equivalent Collections and assign articles in bulk.

Deskero Canned Answers map to Intercom Saved Replies. Template names transfer as Saved Reply titles, and template body content transfers as the reply body. Category groupings in Deskero Canned Answers map to Saved Reply labels or folders in Intercom. Canned Answers are workspace-level templates in Deskero and workspace-level in Intercom, so the mapping is direct with no structural transformation required.

Deskero Tags applied across tickets and customers map to Intercom Tags. We extract the full set of distinct tag strings from the Deskero export and create corresponding Tag records in Intercom, then link them to the migrated Conversations and Contacts using Intercom's tagging API. Tag count and distribution statistics are preserved for post-migration reporting.

Deskero social monitoring mentions are standalone records that may or may not be linked to a support ticket. We flag all unlinked mentions during scoping and present three options: import as standalone Intercom Conversations tagged with a social_origin label, merge into existing related Conversations where a thread relationship exists, or exclude from the migration scope. The customer resolves this decision point before we begin the import pass.

Deskero workflow rules, SLA settings, escalation logic, and custom workflow conditions are platform-level configuration stored on the server side, not as record data in the export. These do not migrate. We deliver a written inventory of every active Deskero workflow with its trigger conditions, actions, and timing, plus recommended Intercom Rules or Fin AI Agent workflow equivalents. The customer's admin rebuilds these post-migration.