Migrate from Deskpro to Zoho Desk

Deskpro Peoples (individual customers) map to Zoho Desk Contact. First Name, Last Name, Email, Phone, Mobile, Street, City, State, Country, and Zip all map to their Zoho Desk Contact field equivalents. The Contact's AccountId is resolved by matching the Deskpro Organization linked to each People record, creating the lookup relationship at import time rather than after. Social profile links (Facebook, Twitter) from Deskpro map to Zoho Desk Contact social fields if the destination layout includes them.

Deskpro Organizations map to Zoho Desk Account. Account Name, Phone, Email, Website, Industry, Street, City, Description, and Annual Revenue migrate directly. The Deskpro Organization ID becomes the AccountExtId used as the dedupe key during Contact import so that each People record correctly associates with its parent Account.

Deskpro Departments map directly to Zoho Desk Departments. We create Zoho Desk departments in dependency order (parent departments first, then child departments) using the Zoho Desk Departments API. Agent affiliations migrate by reassigning the agent's Department field to match the Zoho Desk department created from the same Deskpro Department record.

Deskpro Agents map to Zoho Desk Agents by email address. Agent name, email, department assignment, and language preference migrate. If a Deskpro agent email already exists as a user in the destination Zoho Desk portal, the system maps them to the existing profile. Agents without a matching email require manual provisioning in Zoho Desk before the migration runs.

Deskpro Tickets map to Zoho Desk Tickets. Subject, Description, Status, Priority, Channel, and Due Date migrate to their Zoho Desk field equivalents (ticket_subject, ticket_status, ticket_priority, ticket_channel, ticket_dueDate). Resolution migrates to ticket_resolution. The Deskpro ticket ID is preserved as ticket_externalId for reconciliation. Assignee maps by resolving the Deskpro agent email to the Zoho Desk agent created in the Agent phase.

Deskpro Ticket Comments (agent and customer replies) migrate to Zoho Desk Ticket Threads. Thread type (public reply, private note) maps from Deskpro's comment visibility flag. The agent or contact who authored the comment is resolved by email match against the migrated Agent and Contact records. Thread creation timestamps migrate as the thread date. Note that Deskpro's thread direction markers (incoming vs outgoing) may not have a 1:1 Zoho Desk equivalent and are flagged as a minor data-integrity item post-migration.

Deskpro Tickets linked to Organizations carry the Organization as the primary account association in Zoho Desk. When importing tickets, we resolve the Deskpro Organization ID to the AccountExtId on the Zoho Desk Account and set ticket_accountId at ticket insert time. This ensures that ticket-to-account linking is established during import rather than patched afterward.

Deskpro custom fields on Tickets are discovered via the reports API using the custom field prefix (cf_ or custom field label prefix), capturing field IDs, types, and label names. Custom fields map to Zoho Desk custom fields (cf_ prefixed) on the Ticket module, but Zoho Desk custom fields are scoped per department. We create the custom field in each Zoho Desk department that receives migrated tickets, then map the Deskpro field values by department at migration time. Without this schema discovery step, custom field data migrates as plain text into the first standard Zoho Desk field, causing permanent data loss.

Deskpro's three-tier KB hierarchy (Category > Folder > Article) must collapse into Zoho Desk's two-tier structure (Section > Article). We map each Deskpro Category to a Zoho Desk Section, and each Deskpro Folder becomes a child Section within that Section, preserving a visual grouping that mirrors the original hierarchy. If the destination Zoho Desk portal uses only Sections, the two-tier structure handles this without additional merging.

Deskpro Folders map to Zoho Desk Sections, with parent Section assigned from the mapped Category. Folder permissions (if configured) are noted in the KB inventory document and flagged for the customer to reapply in Zoho Desk's Section permissions UI post-migration.

Deskpro Articles migrate to Zoho Desk Articles with body content, publish status, author attribution, and multilingual variants preserved. Article parent Section is resolved via the Folder-to-Section mapping. Internal hyperlinks between articles are preserved as raw text URLs; they will not auto-update to new Zoho Desk article IDs after migration, which is flagged in the KB inventory document for manual URL audit post-migration. Note: Zoho's native Zwitch tool explicitly drops KB article attachments; we use the Zoho Desk REST API directly to avoid this loss.

Deskpro Tags are a flat labeling system applied to tickets. We preserve tag assignments on every migrated ticket. The destination tag vocabulary is created in Zoho Desk during import to match Deskpro's naming exactly. Note: Zoho's own Zwitch tool drops tags during migration; we avoid this by using the Zoho Desk API directly, which supports tag creation and assignment.

File attachments on Deskpro tickets are downloaded to a staging bucket, then uploaded to Zoho Desk via the Zoho Desk Attachments API linked to the corresponding ticket. Very large attachments (over 25 MB) may require chunked upload handling. KB article attachments are handled separately as noted in the Article mapping; Zoho Desk does not natively preserve KB attachments via API in all configurations, so this is flagged explicitly before migration begins.

Deskpro automations (triggers, workflows, SLA rules) are not directly transferable between platforms because Deskpro's automation engine and Zoho Desk Blueprint have different trigger models, action types, and condition syntax. We do not migrate automations as code. We deliver a written CSV inventory of every active Deskpro automation with its trigger event, conditions, and actions, plus a recommended Zoho Desk Blueprint equivalent for the customer's admin to rebuild. SLA rules migrate as documented configuration rather than as enforced rules.