Migrate from Drag to Zendesk

Every ticket in Drag is a Gmail thread surfaced through their layer. We extract full thread history including all reply chains, sender/recipient addresses, subject line, and timestamps. In Zendesk, the thread becomes a Ticket with comments stored as Ticket Comments (public reply to requester) or Ticket Events (status changes, assignments). The original Gmail thread ID is stored as an external_id field in Zendesk for audit and cross-reference.

Drag Kanban column names (e.g., To-Do, In Progress, Awaiting Response, Done) map to Zendesk ticket status values (New, Open, Pending, On-Hold, Solved, Closed). We create a custom ticket status (or use an existing one) for each Kanban stage column and configure the mapping during scoping. Stage order position in Drag becomes the initial ticket priority or a custom field pipeline_position__c. Customers with multiple boards must confirm which board maps to the primary Zendesk view during scoping.

Drag team members are extracted by email address and display name. We map each agent email to a corresponding Zendesk User with the agent role. If a Zendesk user does not yet exist for a given agent, the customer provisions the account before the migration phase. Agent performance metrics (response time, resolution rate) are not available in Drag's export and do not migrate.

Drag tags are flat labels applied to individual conversations. Multiple tags per conversation are supported and fully preserved. In Zendesk, tags are applied to tickets directly. We map each unique Drag tag name to a Zendesk tag of the same name. Tag taxonomy and any tag-grouping logic in Drag (e.g., category prefixes like PRIORITY-high) must be reviewed post-migration as Zendesk tags are flat with no native grouping structure.

Drag boards represent the Kanban workspace containing pipeline columns. Board names are exportable, but the board layout itself is not a machine-readable export object. We extract which conversations belong to which board and map each board to a Zendesk View (filtering by status and assignee) that replicates the original queue visibility. Multiple-board customers must confirm board priority during scoping as a Zendesk ticket can only appear in one View at a time by default.

Drag does not maintain a standalone contact database. Contact information is derived from Gmail thread senders and recipients at migration time. We extract each unique email address as a Zendesk End User record with the name from thread headers. If the same email appears across multiple conversations, we deduplicate and create a single End User with multiple associated tickets. Any contact properties beyond email and display name are not available in Drag and cannot be imported.

Drag shared reply templates on Professional and Enterprise tiers migrate to Zendesk Macros. Template body text and shortcut triggers are exportable from Drag's UI. Formatting, conditional logic (if/then placeholders), and variable tokens may require manual review post-import as Drag and Zendesk use different placeholder syntax for dynamic content insertion.

Files attached to email threads are downloaded during the Drag export and re-attached to the corresponding Zendesk ticket. Large attachments over 50 MB per file may require separate handling or Zendesk storage provisioning. Inline images embedded in email body migrate as separate attachment records linked to the ticket comment.

Drag teams are groupings of agents assigned to handle specific queues. We export team membership and map each team to a Zendesk Group. Group-based routing in Zendesk (assigning tickets to groups rather than individual agents) must be configured manually post-migration as Drag's team-to-agent assignment structure differs from Zendesk's Groups model.

Drag integrates with Gmail, Google Workspace, Slack, and calendar tools. These configurations are UI-only and not exportable. We document the active integrations during scoping so the customer's admin can reconnect them in Zendesk. Gmail-to-Zendesk email routing in particular requires DNS-level changes (MX record updates) that are outside migration scope but must be planned to avoid email loss during cutover.