Migrate from Drag to Zoho Desk

Drag Conversations (Gmail threads surfaced through the Drag layer) map directly to Zoho Desk Tickets. We preserve subject, original sender, recipient list, thread timestamp, and full reply history by reconstructing the thread structure in Zoho Desk using Ticket Threads and Comments. Each email in the original thread becomes a separate Comment record on the Zoho Ticket in chronological order. The original thread message IDs are stored in a custom Zoho field for reconciliation reference.

Drag boards map to Zoho Desk Departments. Each board name becomes a Department name in Zoho Desk, preserving the workspace-level separation that Drag uses. If the customer has multiple boards representing different lines of business or clients, we create corresponding departments in Zoho Desk. Board names are preserved as Department descriptions for admin reference. Note: boards with overlapping agent membership require the customer to confirm department-agent assignments during scoping.

Drag Kanban columns (Pipeline Stages within a board) map to Zoho Desk Status values scoped to the corresponding Department. Each board's column order is preserved as the Status display order. Customers with multiple boards must designate a primary board during scoping, as Zoho Desk scopes Status values per Department rather than globally. We document which non-primary board stages become tags or custom fields for visibility.

Drag Agents map to Zoho Desk Agents by email match. We extract email address and display name from Drag. Agent permissions (admin, supervisor, agent) map to Zoho Desk roles. Any Drag Agent without a matching Zoho Desk user at migration time goes to a reconciliation queue for the customer's admin to provision before the conversation import phase begins, because OwnerId references on Tickets are required.

Drag Tags map to a Zoho Desk multi-select picklist field on the Ticket layout. Multiple tags per conversation are preserved as multiple picklist values. The customer must decide tag strategy during scoping: if the existing tag vocabulary is stable and under 150 unique values, we create a picklist; if tags are fluid or exceed the picklist limit, we use a text field and document the limitation. Tag names are preserved verbatim with a tag vocabulary reference delivered post-migration.

Drag does not maintain a native contact database; contact information is derived from email thread participants at export time. We extract sender name and email address from every unique thread participant as a derived Contact record in Zoho Desk. This yields a flat contact list without the historical properties, deal associations, or lifecycle stage data that a dedicated CRM produces. The customer receives a contact quality report noting which contacts have only one associated ticket versus which are repeat customers.

Files attached to email threads migrate as Zoho Desk Files linked to the parent Ticket. We download all attachments from the Drag UI during export coordination, then re-attach them to the corresponding Zoho Ticket. Large attachments (over 25 MB) may require the customer's Zoho Desk storage provisioning before import; we flag this during scoping. Inline images embedded in email bodies (not as file attachments) may not transfer via CSV export and may require manual re-attachment post-migration.

Drag Canned Responses (available on Professional tier and above) migrate to Zoho Desk Macros. We export template body text and shortcut triggers from Drag. Formatting and conditional logic in Drag templates require manual review post-migration because the conditional syntax differs between platforms. Macro folders in Zoho Desk are created to match the original template grouping.

Drag's free and lower paid tiers do not expose a custom fields API, and any per-conversation structured data outside of tags, assignee, and stage is not programmatically accessible. We cannot migrate custom fields that exist only in the UI. Customers with active custom field usage on Drag must document the fields and their values during scoping so we can recreate the field schema in Zoho Desk and manually map values post-migration. This is a manual scope item, not an automated migration item.

Drag automations (auto-assignment rules, auto-tagging, SLA routing) are configured exclusively through the UI and are not accessible via any documented API or export. We do not migrate automations as code. We deliver a written inventory of every active Drag automation with its trigger, conditions, actions, and a recommended Zoho Desk Blueprint or Workflow equivalent. The customer's admin rebuilds automations post-migration using Zoho Desk's native automation tools. SLA policies, round-robin assignment rules, and conditional tag triggers all require manual reconstruction.

Drag Teams (groupings of agents) map to Zoho Desk Teams. We export team membership and the agents assigned to each team. Team-based routing rules in Drag require manual review in Zoho Desk because Zoho routes tickets by Department and Assignment rules rather than team-based queues. The team mapping document we deliver includes the recommended Zoho Desk equivalent routing configuration for each original Drag team.

Drag integrates with Gmail, Google Workspace, Slack, and calendar tools. Integration configuration does not migrate; the customer replicates integrations in Zoho Desk post-migration. Gmail integration is replaced by Zoho Desk's native email ticketing channel configuration. Slack integration migrates to Zoho Desk's Slack integration, which requires re-authentication and channel mapping.