Migrate from DeskDay to Intercom

DeskDay ticket records map to Intercom Conversation records via the Conversations API. We preserve the ticket subject as the Conversation title, ticket status (open, pending, resolved, closed) as Intercom conversation state, and the original ticket body and all reply threads as message records within the Conversation. Custom ticket fields migrate as key-value attributes attached to the Conversation. Assignee resolution maps the DeskDay agent email to the corresponding Intercom admin or team member. DeskDay's priority field (low, medium, high, urgent) migrates as a conversation attribute for routing and SLA assignment in Intercom.

DeskDay end-user contact records migrate to Intercom Contacts with full name, email, phone, and any custom contact fields preserved. We resolve the end user's associated Client Organization in DeskDay and link the corresponding Intercom Contact to its Intercom Company record. Phone number validation in Intercom can cause import failures for invalid formats; we recommend disabling phone validation in Intercom workspace settings before migration begins. Custom contact attributes from DeskDay migrate as Intercom custom attributes on the Contact object.

DeskDay Client Organization records representing each MSP customer map directly to Intercom Company records. We preserve the organization name, domain, SLA tier association, and any custom organization fields as Intercom Company attributes. This mapping is critical because it maintains the MSP service-tier context (which DeskDay encodes at the organization level) within Intercom's company record. All DeskDay end users associated with a given Client Organization link to the corresponding Intercom Company after migration.

DeskDay agent records migrate to Intercom admins and team members. We map agent name, email, and role (admin, technician) to the equivalent Intercom admin or team member. DeskDay team assignments migrate to Intercom team membership. Any DeskDay agent without a corresponding Intercom user account enters a reconciliation queue for the customer's admin to provision before the agent-based ticket assignment phase runs. Inboxes in Intercom are tied to team assignment, so team mapping must be validated before conversation import to ensure correct routing.

DeskDay team structures map to Intercom Teams for inbox routing. Each DeskDay team becomes an Intercom team, and ticket assignments that reference a DeskDay team are resolved to the corresponding Intercom team during migration. Intercom's team-based inbox model allows conversations to be assigned to both a team and an individual agent; we preserve the DeskDay team assignment as the primary routing target with individual agent assignment as a secondary attribute if the source ticket had a specific assignee.

DeskDay custom ticket fields require field-level schema mapping to Intercom custom attributes. Since DeskDay's custom field schema is still evolving and Intercom's attribute system supports string, number, boolean, date, and list types, we extract the DeskDay field definitions, map each to the equivalent Intercom attribute type, and flag any fields with data types that do not map cleanly (such as DeskDay custom objects or multi-select lists exceeding Intercom's attribute limits). The customer receives a written field-mapping matrix before migration execution. Intercom's Fin AI cannot query custom attributes directly, so any custom fields intended for Fin routing or automation require an Intercom workflow configuration post-migration.

DeskDay SLA configurations referencing business-hours definitions and escalation rules migrate as Intercom SLA configuration records. However, DeskDay SLA targets tied to custom date fields or service-tier associations at the Client Organization level may require field remapping in Intercom because Intercom's SLA targets are conversation-attribute-driven rather than tied to organization-level billing tiers. We document the original SLA escalation rules in a written configuration guide for the customer's admin to implement as Intercom SLA rules and team routing rules post-migration.

DeskDay KB articles migrate to Intercom Help Center articles within Collections and Sections. We preserve article title, body content, internal links, and inline images. DeskDay article categories map to Intercom Collections or Sections depending on hierarchy depth. Note that DeskDay supports a two-level KB hierarchy (Category > Article) while Intercom uses a three-level structure (Collection > Section > Article); articles without a parent section in Intercom's structure may appear as top-level Collection articles, which can shift the expected hierarchy. Article view counts, feedback ratings, and publication status from DeskDay migrate as metadata attributes rather than native Intercom article fields and require post-migration verification.

Tags applied to DeskDay tickets migrate as flat label arrays to Intercom conversation tags. We preserve all tag names exactly and apply them to the corresponding Intercom Conversation records. Tags in Intercom are used for conversation filtering, reporting, and workflow triggers. There is no tag hierarchy in either platform, so flat tag migration preserves full fidelity without transformation.

DeskDay stores file attachments on tickets using internal cloud URLs that are not portable between platforms. During migration, we download all ticket attachments, re-upload them to Intercom's conversation attachment storage, and update conversation message records with new attachment references. This process adds processing time proportional to total attachment volume and must be planned into the migration timeline. Customers with large attachment volumes (over 5 GB total) should budget additional time for the download-reupload cycle.