Migrate from Drag to Intercom

Drag conversations are Gmail threads surfaced through the Drag layer. We extract full thread history including all reply chains, timestamps, sender/recipient email addresses, subject lines, and message body content. Each thread becomes an Intercom Conversation record with individual Conversation Parts for each message in the thread. The thread subject becomes the Conversation subject, and we preserve the original thread timestamps on each Part.

Drag's Kanban columns (e.g., To-Do, In Progress, Done) export as stage names and position order. Intercom does not have an equivalent Kanban column object; instead, we map stages to saved Inbox Views with custom filters using the Conversation state and custom attributes. We create one saved view per source stage and advise the customer on Intercom's state-based filtering (Open, Closed, Snoozed) as the replacement for visual pipeline tracking.

Drag Boards represent the Kanban workspace containing pipeline columns. Since Intercom lacks a board concept, we map board names to Inbox names or team inbox groupings in Intercom. Customers with multiple boards must decide during scoping which board layout to prioritize, as conversations can belong to only one board in Drag and Inbox views in Intercom are filter-based rather than container-based.

Drag Agents map directly to Intercom Teammates. We extract email address and display name for each agent and map them to the Teammate's email in Intercom. Agent inactive/active status transfers. Performance metrics such as average response time tracked in Drag are not accessible for export and cannot be migrated to Intercom.

Drag tags are flat labels applied to conversations. We preserve all tag assignments at the individual conversation level. Intercom tags are applied at the conversation level similarly. If Drag uses a large number of tags (high cardinality), we recommend a tag consolidation mapping during scoping to avoid tag proliferation in Intercom. Multiple tags per conversation are supported in both platforms.

Drag Teams are groupings of agents. We export team membership and assignments. In Intercom, Teams are used for inbox routing and assignment. Team-based routing rules must be manually mapped post-migration as Intercom's inbox assignment rules differ from Drag's team grouping model.

Drag does not maintain a standalone contact database. Contact information is derived from Gmail thread participants at migration time. We extract unique email addresses from conversation senders and recipients and create Intercom Contacts from them. Name is derived where available; email address is the primary identifier. Multiple conversations with the same contact participant result in a single Intercom Contact with multiple linked conversations. If the customer has an external contact list or CRM, we recommend merging this with the derived contact set post-migration.

Files attached to email threads in Drag are downloaded and re-attached to the corresponding Intercom Conversation Parts. We download each attachment from the Gmail thread, store it temporarily, and attach it to the matching conversation part in Intercom. Large attachments (over 10 MB) may require separate storage handling or a cloud storage reference note.

Drag's canned responses (available on Professional and Enterprise tiers) contain template body text and shortcut triggers. We export the template body text and shortcut names. Formatting and conditional logic require manual review post-migration. In Intercom, these map to Macros, which must be manually created from the exported templates during the post-migration configuration phase.

Drag integrates with Gmail, Google Workspace, Slack, and calendar tools. Migration scope is limited to conversation data; integration configurations must be replicated at the destination. In particular, the Gmail integration is replaced by Intercom's native email handling; the Slack integration requires reconfiguration in Intercom's integration settings; calendar integrations must be reconnected.

Drag's free and lower paid tiers do not expose a custom fields API. Any per-conversation structured data outside of tags, assignee, and stage is not programmatically accessible. We flag this gap in the migration scope and advise the customer to audit any structured data captured outside of the standard fields during scoping. In Intercom, custom attributes on contacts and conversations can be created post-migration for data that was previously captured in workarounds.